Claude Code performs best when given four things upfront: a scoped task, the files to read first, what “good” looks like, and what NOT to touch. Drop any of the four and you get over-eager refactors, surprise schema changes, and PRs that need to be unwound. These prompts hit those structures and add planning gates where the cost of being wrong is high. Pair with code review prompts before merging.
Best for
- Feature implementation against an existing codebase
- Surgical bug fixes with minimum diff
- Multi-step migrations with rollback
- 3-phase refactors that stay deployable
- TDD-style implementation and perf work
- Spike code to validate an approach before committing
1. Scoped feature implementation
Implement {feature} in {repo}.
Files to read first: {list}
Files you may change: {list}
Files you MUST NOT change: {list}
What good looks like:
- tests pass
- no schema migration
- new code follows the existing patterns in {file}
- diff is reviewable in <300 lines
First show a plan as bullet steps. Wait for my approval before editing.2. Surgical bug fix
Fix bug: {description}.
Repro steps: {steps}.
Expected vs actual: {what should happen vs what happens}.
Constraints:
- minimum-diff fix only, no refactoring
- add 1 regression test that fails before the fix
- files likely involved: {list}
Show the diff before applying it.3. Migration with rollback path
Migrate {from} → {to} in {area}.
Constraints:
- each commit must be deployable on its own
- must support both old and new during the transition window
- rollback = reverting commit by commit, no manual cleanup
Show me the commit plan first: title + diff scope of each commit. Wait for approval before executing.4. Refactor in 3 phases
Refactor {component}. Three phases, each mergeable independently:
Phase 1: introduce new abstraction alongside old (no caller changes)
Phase 2: migrate callers one at a time, with the old still available
Phase 3: delete old code, no compat shim
Show me the Phase 1 diff only first. Do not touch callers yet.5. New module from spec
Build module {name} per this spec: {paste}.
Codebase conventions to respect: {1 paragraph — folder layout, naming, error handling, test style}.
Existing similar module to mirror: {file}.
Show me the file structure + public interfaces (no implementation) before writing the bodies. I'll approve, then you implement.6. Test-driven implementation
Implement {feature} test-first.
1. Write failing tests for these behaviors: {list}
2. Show me the tests. Wait for approval.
3. Implement the minimum code to make tests pass.
4. Refactor only after all tests are green.
Do not add tests for behaviors I didn't list.7. Spike to validate an approach
I want to validate the approach for {feature}. Build a 50-LOC spike that demonstrates the core idea.
- Don't worry about edge cases or error paths
- Hard-code config where you'd normally read it
- Annotate with `// TODO: real impl needs to handle X` at every shortcut
Goal: I want to read the spike and decide if the approach is right before we commit.8. Performance fix with measurement
Performance issue: {description}. Suspected cause: {hypothesis or "unknown"}.
Steps:
1. Add a benchmark that reproduces the slow path
2. Run baseline; report the number
3. Iterate on the fix; after each iteration, report benchmark delta vs baseline
4. Stop when delta is <5% improvement or we hit a target of {X}
Show me the benchmark first before any code changes.9. Read-only investigation
Investigate {question or symptom} in {repo}. Do not edit any files in this pass.
Steps:
1. Read these entry points: {list}
2. Trace the relevant call graph
3. Output: a short writeup with (a) what is happening, (b) why, (c) 2-3 candidate fixes ranked by risk
I'll pick the fix; then we'll do a separate edit pass.10. Diff review before merge
Below is the full diff of {branch}. Review for:
- correctness vs the original ticket: {paste ticket}
- regressions in {sibling area that often breaks}
- missing tests for new behavior
- naming and structural drift from the conventions in {file}
Output: a structured comment list — line + concern + suggested change.
{paste diff}11. Failing-CI debug
CI is red on {branch}. The failing job: {job name}. Log excerpt: {paste relevant section, not the whole log}.
Diagnose:
1. What is the test asserting?
2. Why is it failing now? Recent change in {area}?
3. Smallest fix: change the test, change the code, or revert {commit}?
Show your reasoning before suggesting a fix.12. Dependency upgrade with risk map
Upgrade {dep} from {old} → {new} in {repo}.
Output a risk map first:
- Breaking changes in the changelog that touch our usage
- Files in our code that hit the changed surface
- Tests that should be added or expanded
- Rollback plan
Then propose the smallest first PR. Do not bundle this with unrelated changes.Common mistakes
- “Improve this code” with no scope — Claude Code rewrites half the file
- Skipping the read-first list — Claude infers patterns from training rather than from your repo
- No “do not touch” constraint — adjacent files get drive-by edits
- Asking for code before asking for a plan — you lose the cheapest checkpoint
- Bundling refactor + feature in one PR — neither is reviewable in isolation
Related
Tags: #Prompt #AI coding #Claude Code