Awesome Claude Prompts Unofficial

Plan a code change before editing

Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.

Task: Plan a code change before editing · Other tasks

Fill in the details

Describe the outcome, not the steps. Mention the feature or module by the name the project uses.

Optional. Rules the plan must respect, such as compatibility, deadlines or parts of the code that must not change.

Optional. The commands or checks that should pass when the change is done.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • The change touches several files or modules and you want to see the whole shape of it before any code is written.
  • You are unsure about the approach, or you are working in code you do not know well, and a wrong first step would be expensive to undo.
  • You want a written plan you can share with a teammate or check the finished work against.

When not to use it

  • The change is small and clear, such as renaming a variable or adding a log line. If you could describe the diff in one sentence, ask Claude to make it directly.
  • You do not yet know what you want to build. Start with the spec interview template to pin down the requirements, then plan.
  • You are in a plain chat without access to the code. A plan written without reading the files is a guess.

Why this structure

  • The no-edit instruction separates research and planning from implementation. Claude Code also has plan mode for this step (Shift+Tab, or claude --permission-mode plan): Claude researches and proposes without editing your source, and in most sessions edits stay blocked until you approve the plan.
  • Reading the code first is stated explicitly, because a plan built on assumptions about file names and call paths is a common way for a plan to go wrong.
  • The file list in step 2 is the part you review most closely: it shows the blast radius of the change before anything is touched.
  • Step 3 asks for checkpoints where the code still builds and tests pass, so a long change can be carried out and checked in safe pieces.
  • Step 5 asks how the result will be verified, using your checks when you give them. A change with a check Claude can run can be finished and confirmed without you watching every step.
  • The last paragraph lets Claude say the plan is overkill, because planning adds overhead that small changes do not need.

Example input (fictional)

The change you want
Refactor the payment module so it supports more than one currency. Prices are stored as integer cents in USD today.
Constraints
Keep the public checkout API unchanged. No new dependencies.
How to check that it works
npm test and the checkout end-to-end suite

Follow-ups to send Claude

  • Go with the plan, but do step 2 before step 1, and keep the old function as a thin wrapper until the callers are migrated.
  • Implement the plan. Run the tests after each step and stop if a step breaks something the plan did not expect.
  • Write the approved plan to PLAN.md so I can review it and start a fresh session for the implementation.

Common mistakes

  • Describing the steps instead of the outcome. If you dictate the steps, you lose the main benefit of the plan, which is Claude reading the code and finding the right ones.
  • Approving the plan without reading the file list. Most surprises in the finished change were visible there.
  • Planning a change that is too large to review. If the plan has dozens of files, ask Claude to split it into separate changes and plan the first one.
  • Write a spec by interview: Let Claude Code interview you about a feature, covering implementation, UX, edge cases and tradeoffs, then write a self-contained spec to a file.
  • Get oriented in a new codebase: Ask Claude Code to map an unfamiliar repository: its architecture, key directories, how the parts connect, and where to start for your task.
  • Code review prompt: Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.

See all templates

Sources