writing-planslisted

# Writing Plans Write implementation plans that a fresh agent can execute task by task without guessing. ## Overview Use this after `workbench:writing-spec` or after the user provides approved requirements. The output is a concrete plan with exact file paths, bite-sized checkbox steps, test commands, expected results, and commit points. 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. DRY, YAGNI, TDD, and frequent commits are the default. ## Path Resolution Resolve the plan path in this order: 1. `.workbench/autopilot.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>-autopilot/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 produce working, testable software on its own. ## File Structure Before defining tasks, map which files will be created or modified and what each file is responsible for. - Use exact paths. - Follow existing project patterns. - Keep files focused on one responsibility. - Keep related changes together. - Include a split only when it is directly needed for t