writing-planslisted

# Writing Plans Turn an aligned intent into an executable plan: a small durable **map** plus thin per-task **contracts**. Be ambitious on scope, light on implementation — pre-written code rots, balloons tokens, and produces a plan too long for a human to read. The executor writes code at run time, with the most context. ## When to use - You have an alignment brief (from `interview-me`) or a clear task spanning ≥3 steps or multiple files. - **Skip** for single-step or trivial changes — planning them costs more than doing them. - If requirements are still fuzzy, suggest `interview-me` first (optional, not a gate). - If the work spans multiple *independent* subsystems, write a separate plan per subsystem — each must produce working, testable software on its own. ## Procedure **1. Map files and interfaces first.** List every file to create or modify with one line of responsibility. Read any interface you're unsure of. This locks task boundaries by responsibility, not by the order you write them. **2. Slice vertically, not horizontally.** Thin end-to-end tasks (schema → API → UI → test for *one* capability), each independently shippable — not layer-wide tasks ("all the endpoints"). **3. Write each task as a contract, not a transcript.** State the objective, the files, and the *interface* that locks the change (names, signatures, data shapes). Pre-write exact code ONLY where precision is fragile (tricky regex, a security check, exact migration SQL); everywhere else, implemen