Make it look like the code already there

ConformanceModel-agnosticupdated 2026-08-28sha 3f2706bc64a4

Agent code is usually correct and almost never native. It invents a helper that exists two folders away, adds a dependency for something the repo already does by hand, names a file in a style used nowhere else, and picks the one error-handling shape the codebase abandoned a year ago. None of it fails review on its own. All of it together is why the file feels like a guest wrote it. A design system will not fix this, because the tells are structural rather than visual.

You are about to write code in an existing codebase. Before you write anything new, you must find what this repo already does and cite it. Novelty is the thing you have to justify here, not consistency.

TASK: {{task}}
REPO: {{repo_path}}

STEP 1 - Find the exemplars. Do this before writing a line.
For every new thing the task needs - a module, a component, a route, an endpoint, a test, a migration, a config entry, a script - find the nearest EXISTING example of that same thing in this repo.
- Cite it as file:line. Not "the repo generally does X" - the actual file.
- Where three or more exist, cite three and say which you are following and why. If those three disagree with each other, say so plainly: you have found an inconsistency, not an idiom, and copying one of them is a choice you are making rather than a convention you are obeying.
- Where none exists, say so explicitly and show what you searched. "No existing example" is a legitimate finding and it changes what comes next; assuming it without looking is the failure.

STEP 2 - Extract the conventions you are about to be judged against.
From the exemplars, write down the specific rules this repo actually follows. Not general good practice - what THIS code does:
- File and directory naming, and where this kind of file lives.
- How modules import and export, and whether barrels or deep paths are used.
- Error handling shape: thrown, returned, wrapped, logged, swallowed.
- How state, config, and secrets are reached.
- Test placement, naming, and how fixtures are built.
- Comment density and register. A repo of terse code does not want your explanatory paragraphs, and a repo that documents every function does not want your silence.

STEP 3 - Write it, then audit against the list.
Go through your new code line by line against STEP 2. For every place you departed, one line: what you did, what the repo does, and why yours is better. A departure with a real reason is fine and should be stated. A departure you cannot justify is a defect - fix it to match.

STEP 4 - Hunt the four tells that survive a passing review.
- A PARALLEL ABSTRACTION: did you write a helper, type, constant, or utility that already exists somewhere in this repo under another name? Search before you answer, and show what you searched. This is the most common and the most expensive one.
- A NEW DEPENDENCY: did you add one for something the repo already does itself? Name the existing approach you passed over.
- AN ORPHAN PATTERN: is your file the only one in the repo shaped this way?
- A DROPPED CONVENTION: did you skip something the exemplars all do - a guard, a log line, a type export, a registration step - because your code works without it?

RULES.
- Conformance is not the goal, being native is. If the local pattern is genuinely bad, say so in one line, follow it anyway for this change, and flag it separately. Do not fix the codebase's habits inside an unrelated task.
- A citation must be a real path you read. Never cite a file you inferred the existence of.
- If STEP 1 found no exemplar for the main thing you are building, say that at the top of your final answer. You are setting a precedent rather than following one, and the reviewer needs to know that is what they are approving.

END WITH: the exemplars you followed, every departure and its reason, and one line on whether a reviewer who did not know an agent wrote this would notice.

Fill in: task repo_path

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.