Coding

Multi-file workflows

Work across a whole repository, not one snippet.

Knowledge cards
Knowledge card
Batch Edits by Concern to Keep Diffs Reviewable
A pattern where you have Claude group a large change into separate batches by concern — pure refactor, behaviour change, formatting, dependency bump — and produce them as distinct commits or steps rather than one entangled diff.
L3 · Workflows
Knowledge card
Change the Contract First, Then the Callers
A multi-file editing pattern where, to change something used in many places, you have Claude change the definition — the type, signature, or interface — first, then work through the call sites the change surfaces, rather than editing scattered usages by hand.
L3 · Workflows
Knowledge card
Give Claude the Map Before a Multi-File Edit
Before asking Claude to change something that spans files, giving it a short map — which files are involved, how they relate, and where the edit should and shouldn't reach.
L3 · Workflows
Knowledge card
Agree the Edit Manifest Before the First Change
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.
L3 · Workflows
Claude multi-file workflows

Give Claude the map before the edit

Working across a repository is where context discipline matters most. Before asking for changes, give Claude the map: which files are involved, how they relate, and where the change needs to land. A short orientation — 'the handler is here, it calls this service, which uses this model' — lets Claude make edits that fit the whole rather than a single file in isolation. Skip that and it edits blind, changing one file in a way that breaks its neighbours. The map is what turns scattered edits into a coherent change.

Let it explore, then plan

For non-trivial multi-file work, have Claude explore and propose a plan before it touches anything. A plan — the files it will change and why — is cheap to review and catches a wrong approach before it becomes a wrong diff. Then apply the changes in reviewable chunks rather than all at once. This is exactly the loop Claude Code formalises in the terminal: explore, plan, approve, edit. The same discipline works in any multi-file task.

Frequently asked
How does Claude work across multiple files?

Give it a map of the relevant files and how they connect before asking for edits, so changes fit the whole system rather than one file in isolation. Orientation prevents edits that break neighbours.

How do I keep multi-file changes coherent?

Have Claude propose a plan of which files it will change and why before editing, then apply changes in reviewable chunks. A plan catches a wrong approach before it becomes a wrong diff.

Is Claude Code better for multi-file work?

It formalises the explore-plan-approve-edit loop in your terminal, which suits multi-file changes well. The same discipline of mapping and planning applies whether or not you use it.