Copy the Neighbours
Makes new code look like the code already around it, instead of like whatever the agent prefers.
When to reach for it
Any time you add to a file or folder you did not write, in a codebase whose conventions are obvious to anyone reading it and written down nowhere.
What changes
- Before editing, the agent reads two or three nearby files and states the conventions it found — imports, exports, error handling, file layout, test style.
- New code follows the local pattern even where the agent would have written it differently on its own.
- The diff stops carrying unrelated style churn, so review is about the change and not about quote marks.
- Where the file and the project's tooling disagree, the agent says which it followed instead of silently picking one.
- A genuinely harmful local pattern gets named as a separate proposal rather than fixed by stealth inside your feature.
Pairs with
- Borrow the ShapeStarts new code from the closest existing file in your repo instead of from a blank page.
- Keep the Diff SmallBounds a change to what you can actually read before approving it.
- Name Things OnceSettles what everything is called before the code is written, so one idea does not arrive under four names.
Copy the Neighbours
The code around your change already made every decision you are about to make. Read it first.
1. Read the nearest examples
Before editing, open the file you are changing plus the two most similar files beside it. Adding a route, read two routes. Adding a test, read two tests. Adding a component, read the two it will sit next to.
2. Write down the conventions you find
Look for the decisions that stay invisible until you get one wrong:
- Imports: relative or aliased, grouped or not, ordered how.
- Exports: named or default, one per file or several.
- Errors: thrown, returned as values, wrapped, logged where.
- Async: promises or await, and how a failure travels upward.
- Naming: casing for files, types, constants, handlers, booleans.
- Structure: where types live, where constants live, what order things are declared in.
- Tests: where they live, what they are named, how fixtures get built.
3. Write your code in that style
Even where you disagree with it. One file with a single consistent style is easier to work in than one file with two good styles.
4. Handle the conflicts out loud
- The file disagrees with the formatter or linter: follow the tool, and say the file is now mixed.
- Two nearby files disagree with each other: follow the newer one, and say which one you copied.
- The local pattern is genuinely dangerous — a swallowed error, an unescaped input: do not copy it. Match the style, fix the danger, and say what you declined to copy and why.
5. Read your diff for style noise
Anything in the diff that is not part of the change — reordered imports, changed quotes, reflowed lines, a stray semicolon — comes back out before you are done.
Rules
- Do not import your own stack. No new formatter, no new assertion library, no new folder layout inside someone else's project.
- Do not modernize the surrounding code while you are in there. That is a separate change, with its own review and its own blame.
- Do not invent a convention because you could not find one. Look wider first; the pattern is usually in a sibling folder.
- Do not stay quiet about a bad pattern you copied. Mention it once and let the user decide whether it is worth following up.