Knowledge card L3 · Workflows informational

Agree the Edit Manifest Before the First Change

What it is

A pattern where, before Claude touches anything, it produces a manifest — the list of files it will change and, in one line each, what changes in them — and you approve or trim that list before a single edit happens.

plan the diffClaude lists files + what changes in each3You approve or trim the list2Execute file by fileafter approval1
A file-by-file plan you approve before any code moves.

Why it works

The expensive failure in multi-file work is scope: Claude edits eight files when the change needed three, or misses the two it should have touched. A manifest makes the intended blast radius visible while it's still cheap to correct. Approving the plan first turns a sprawling, hard-to-review change into a sequence of expected, bounded edits.

When to use it

Any change that spans several files — a feature, a cross-cutting rename, wiring a new dependency through layers. The moment you can't hold the whole change in your head, get the manifest.

When not to use it

Single-file or obviously local changes, where writing a plan is slower than making the edit. Don't manifest a typo fix.

Prompt

I want to <goal>. Before editing anything, produce an edit manifest: list every file you'll change, and for each, one line on what changes and why. Include files you'll create or delete. Don't write code yet. I'll review the manifest and tell you what to add, drop, or split — then you execute it file by file.

Example

For 'add rate limiting to the API', Claude's manifest lists a new rateLimiter.ts, a change to middleware.ts, a config addition, and a test file. You notice it planned to edit an unrelated auth file, tell it to drop that, and only then does it start — the change lands exactly as scoped.

Advanced version

Ask Claude to order the manifest so the codebase compiles and tests pass after each file, not just at the end. A manifest with safe intermediate checkpoints lets you stop, review, or ship partway through a large change without leaving the tree broken.

Common mistakes

  • Approving a manifest without reading it, which defeats the purpose — the review is the whole point.
  • Letting the manifest stay vague ("update related files"); every entry should name a real file and a real change.
  • Not revisiting the manifest when execution reveals a needed file it missed — update the plan, don't silently sprawl.

Related