plan-crafting
Plan Crafting
Overview
Write comprehensive implementation plans assuming the engineer has zero context for the codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, and docs they might need to check. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits. Per-task commits are the working granularity for review gates; the final shape of the history (squash, amend, branch flow) follows the user's git preferences.
Assume they are a skilled developer, but know almost nothing about the toolset or problem domain. Assume they don't know good test design very well.
Announce at start: "I'm using plan-crafting to create the implementation plan."
Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md
- An explicit user instruction overrides this default; a differing repository convention does not. If the repository has an established plan location, name both and the one you chose in the same message where you save the plan.
Scope Check
If the spec covers independent subsystems, split the plan by independently testable release units. Each plan should produce working, testable software on its own.