writing-plans

Topics in the source

• Writing Plans

Write the smallest plan that makes the authorized work executable and verifiable. Prefer outcomes and contracts over a script for every keystroke. Do not write the implementation twice in a plan and then ask another model to transcribe it. For a small change, a short task list is sufficient. For substantial work, save a plan at docs/superpowers/plans/YYYY-MM-DD-topic.md, or the project's preferred location. Include: Goal, scope, and accepted design or requirements. Files or components affected and dependencies between tasks. Required behavior, interface contracts, edge cases, and acceptance criteria. Meaningful verification and its independent oracle; commands when known. Ownership only where work is actually delegated. Optionally a "## 実装時の差異" section where deviations from the design are recorded during implementation (when there is no spec file). Provide exact code only when an API contract or non-obvious constraint requires it. Avoid mandatory 2-5 minute steps, full implementation listings, and a separate commit or review for each task. Tasks should produce coherent, independently testable results. Start only after the brainstorming Design Gate has passed: the design was reviewe

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