shipping-a-changelisted

# Shipping a change The unit of work is one small change that a reviewer can hold in their head. If you cannot describe what you are about to do in a sentence, the task is too big — split it and say so. ## Before you touch a file - Re-read the task. What does done look like? If that is not written down, ask the person who assigned it with `ask_agent` before you start, not after you have built the wrong thing. - Look at how the repo already solves this shape of problem, and follow it. A change that reads like the code around it is half-reviewed already. - Check the workspace is clean and you are on a fresh branch off the current default branch. Never work on `main` directly. ## While you build - Change as little as possible. Refactors you were not asked for belong in their own task; if you spot one, note it and move on. - Write or update the test with the change, not after it. A change with no test is a change you are asking someone else to verify by hand. - Run the suite as you go, not once at the end. A failure found three edits ago is a failure you can still explain. ## Before you call it done Run every check the CI runs, in the repo's own commands: 1. the test suite, 2. the typecheck or compile step, 3. the linter or formatter, if the repo has one. All green, or it is not done. If one of them fails for a reason unrelated to your change, say so explicitly in your summary — do not let a reviewer discover it. Then read your own diff, top to bottom. Delet