writing-plans
Writing Plans
Overview
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Address the user directly; never name this skill, its steps, internal scripts/tools, or named rules ("Scope Check", "no-placeholders rule"). Give the reasoning in plain terms ("this bundles several independent subsystems, so I'll split it") rather than citing the rule.
Context: Optionally runs in a dedicated worktree (user chooses during brainstorming).
Save plans to: .planning/plan.md
Scope Check
If the spec covers multiple independent subsystems, stop and suggest splitting it into separate plans — one per subsystem. Each plan should produce working, testable software on its own.