writing-plans

Topics in the source

• Writing Implementation Plans
• Overview
• When to Use
• Bite-Sized Task Granularity
• Plan Document Structure
• Header (Required)
• Task Structure
• Principles

Write comprehensive implementation plans assuming the implementer has zero context for the codebase and questionable taste. Document everything they need: which files to touch, complete code, testing commands, docs to check, how to verify. Give them bite-sized tasks. DRY. YAGNI. TDD. Frequent commits. Assume the implementer is a skilled developer but knows almost nothing about the toolset or problem domain. Assume they don't know good test design very well. Core principle: A good plan makes implementation obvious. If someone has to guess, the plan is incomplete. Method adapted from the public superpowers planning flow (MIT); the plan-shape sections and hand-off are this port's. Always use before: Implementing multi-step features Breaking down complex requirements Delegating to subagents via subagent-driven-development Don't skip when: Feature seems simple (assumptions cause bugs) You plan to implement it yourself (future you needs guidance) Working alone (documentation matters) Each task = 2–5 minutes of focused work by default (PLANTASKMINUTESMIN, PLANTASKMINUTESMAX). Every step is one action: "Write the failing test" — step "Run it to make sure it fails" — step "Implement the min

This is an excerpt. Refer to the complete source and its current requirements.