code-planning

Planning code: from a ticket of intent to an execution plan

This skill applies whenever a request ("redo the evaluation screen", "add a bootstrap") becomes an execution plan that a developer, even a junior, even an AI agent with no context, can follow without inventing. The bar: the plan is precise enough that two different implementers would produce nearly the same code, and motivated enough that a demanding reviewer recognises a doctrine in it, not a task list. It complements ../code-craft/SKILL.md, which covers the act of coding.

A plan lives in .plans/YYYY-MM-DD_subject.md of the repo it concerns. It is disposable after merge: the code, the tests and the CHANGELOG must stand on their own, which is what rule 1 below enforces.

1. The eight sections of a complete plan, in this order

1. Origin: 3 to 5 lines on which concrete feedback or problems triggered this work (cite the observed symptoms, not generalities). This is what lets you arbitrate later: "does this slice serve one of the origin problems?"
2. Non-negotiable rules: the repo's invariants (zero dependency, the write gate, tests by role, max component size, no old/new code cohabitation…) AND the exact verification commands to run at the end of each slice.
3. Engineering doctrine: see §3. This is what tells a plan apart from a to-do list.
4. The slice table: number, content, estimated size, dependencies between slices.
5. The detailed slices: see §4.
6. Known traps: each mistake already made on this repo or foreseeable on this ticket, phrased as an instruction ("apply bottom-up, or the line numbers shift"), to read BEFORE coding the relevant slice.
7. The self-review grid: 10 to 12 binary questions the implementer asks of THEIR own diff before showing it (function over 40 lines? derivable state stored? one rule known in two places? a silent cap?). One "yes" = fix it first.
8. The definition of done: checkboxes, mechanically verifiable where possible.