writing-planslisted

# Writing Plans Write implementation plans that a fresh agent can execute slice by slice without guessing. ## Overview Use this after `workbench:writing-spec` (large lane) or after the user provides approved requirements. For the medium lane, this skill also carries the design work itself instead of a separate spec; see `## Design preamble (medium lane)` below. The output is a concrete plan with exact file paths, slice-ordered checkbox steps, test commands, and acceptance criteria. Assume the implementer is a capable engineer with little project context. Give them enough detail to work correctly, but keep the plan focused on the requested change. Plans work at program-design altitude: exact signatures, call-stack sketches, and acceptance criteria, not full test or implementation code (the `tricky-kernel` flag is the one exception; see `## Slice Structure`). DRY, YAGNI, TDD, and frequent commits are the default. ## Path Resolution Resolve the plan path in this order: 1. `.workbench/pilot.md` `Plans:` heading. 2. Project `CLAUDE.md` or `AGENTS.md` plan-path convention. 3. `.workbench/plans/YYYY-MM-DD-<feature-name>.md`. If the resolved value is `don't commit`, write the plan to `/tmp/<project-name>-pilot/YYYY-MM-DD-<feature-name>.md` and skip committing it. ## Scope Check Before writing tasks, check whether the spec covers multiple independent subsystems. If it does, stop and split it into separate plans, one per independently testable change. Each plan should produc