Borrow the Shape
Starts new code from the closest existing file in your repo instead of from a blank page.
When to reach for it
Adding a new file of a kind that already exists here — another route, another component, another migration — and you want it to look like it belongs.
What changes
- The summary names the exact file used as the template, so you can diff the new one against it directly.
- Every deviation from that template is listed with a stated reason, and unreasoned deviations get reverted.
- New files match the repo's existing export style, naming, error handling, and test location instead of introducing a second convention.
- Catches the case where the agent reaches for a library or pattern the project already decided against.
Pairs with
- Copy the NeighboursMakes new code look like the code already around it, instead of like whatever the agent prefers.
- Name Things OnceSettles what everything is called before the code is written, so one idea does not arrive under four names.
- No New VocabularyStops the agent coining terms that compete with the words your codebase already uses.
Borrow the Shape
A codebase already voted on how things are done here. Find the nearest existing example and start from it.
1. Find the nearest neighbour
Search by role, not by name: the file that does the most similar job. Another route handler, another form, another migration, another test of this kind. List two or three candidates.
2. Choose the current one
Between candidates, prefer the one most recently modified that is still in use. Old files show the convention as it was; recent ones show it as it is. Skip anything marked deprecated, generated, or mid-migration.
3. Extract the shape
Read it and write down the reusable decisions:
- File layout — what comes first, where types live, export style
- Naming — file, function, variable, and prop conventions
- Data flow — how it fetches, where state lives, how it passes down
- Error handling — thrown, returned, or a result type
- Boundaries — what it imports from, and what it deliberately does not
- Tests — where they live, what they assert, how they set up
- Comments — how much, and about what
4. Follow it
Write the new file in that shape: same section order, same naming, same error style. Where the neighbour would have done something one way, do it that way — including where it is not your preference.
5. Justify every deviation
Compare the new file against the neighbour and list each place they differ. For each, state the reason in one clause. Any difference without a reason gets changed back.
6. Name the neighbour in the summary
State which file was used as the template, so the reviewer can read them side by side and check the claim.
Rules
- Do not borrow the neighbour's bugs, dead code, or stale comments along with its shape. Copying structure is not copying content.
- Do not import from the neighbour to avoid duplication — this is about matching form, not sharing implementation. Extract shared code only when there is a real second caller.
- Do not introduce a different state library, fetching approach, assertion style, or folder layout because it is better in general. Propose that separately.
- Do not pick a neighbour from a different layer — a client component is not a template for a server route.
- If no neighbour exists, say so explicitly. That is a real signal: the new file is setting a precedent, and the conventions in it should be chosen deliberately rather than by default.