Code Ownership

When to Use

Use on every coding task where an AI agent writes code the human will own: before commits, after batches, whenever velocity tempts skipping review.

Before any commit of AI-written code, defend ONE decision: what it does, what was rejected and why. No defense, no commit.
Put the defense in the commit message itself, not just said out loud — a one-line "why this, not X" in the commit body. If the commit message can't state it, the decision wasn't actually made.
Read git diff before every commit, never just the agent's summary.
Keep batches small enough to actually review — a diff too large to read in one sitting doesn't get rubber-stamped, it gets split. Ownership scales with diff size in the wrong direction: bigger batches get skimmed, not read.
End every design answer with the rejected alternative and why it lost. No named rejection means no design happened. If the decision is architectural (not just a local code choice), it also belongs in plan.md's Decisions section (see architecture-planning skill) — don't let it live only in chat history.
Touch code weekly: change a number, rename something, break a test on purpose and watch it fail.
When the urge to ask 'explain again' appears, explain it back first (wrong is fine) and let the agent correct.
Check any agent-written test before trusting it: does it assert the intended behavior, or does it just assert whatever the code currently does? A test that would still pass after reintroducing the bug it's meant to catch is worthless — read the assertion, not just the pass/fail color.