DeepReason: Skill for Claude Code

Plan the steps

Input: SPEC.md (re-read REQUEST.md and SPEC.md in full first). Output: CHECKLIST.md — the complete ordered path from the current tree to the accepted change. Execution will do NOTHING that is not a step here, so missing steps here means missed work later. Plan against that.

Ordering rules

1. Dependencies first, verification interleaved: a step that writes a test precedes the step whose change it guards; a step that runs a check follows immediately after the change it checks — not batched at the end where failures lose their cause.
2. One step = one action with ONE done-criterion (a command and its expected output, or "file exists containing "). If a step needs the word "and", split it.
3. Include the boring steps that get forgotten — they are the point of this skill: creating directories, chmod +x, updating the ladder or docs SPEC says to update, retiring an occupied run root (rename commit FIRST), the subsystem test ring, the FULL gate (pytest tests/ -q -n 4, expect 0 failed), the tranche commit with its message, the push with retry, and the final git status --porcelain cleanliness check.
4. Every step cites its spec item (S-number). A step with no S-number is scope creep — delete it or send it to PARKED.md.
5. Scope from the map before planning steps. Open docs/map/INDEX.md, resolve the change to DR-SUB-/DR-CON-/ DR-SEAM- ids, and read the seam document before the subsystem ones — the file is docs/map/SEAM-<a>-x-<b>.md, sides in alphabetical order, and the worked recipe for a seam change is docs/map/REC-change-a-seam.md. Name those ids in CHECKLIST.md's header so execution starts from the same map the plan was built on. A change whose ids you cannot name is a change you have not scoped.
6. Plan the map update as part of the step that changes behaviour, never as a trailing "update docs" step. A trailing documentation step is the one that gets dropped when a tranche runs long. If a seam document must be CREATED, that is its own step, and it comes BEFORE the code steps — writing down the agreement is how you find out whether you understand it.
7. Mark checkpoint steps [COMMIT] at natural boundaries (at minimum: after tests-written, after each spec item lands, after the gate) — rationale canonical in dr-drive-harness §1.