writing-plans

原文涵盖的主题

• Writing Plans
• Overview
• Scope Check
• File Structure
• Task Right-Sizing
• Step Granularity
• Plan Document Header
• Task Structure

Write implementation plans for an engineer who has not seen this codebase or this spec. Assume they write idiomatic code in the project's language once they know the exact interface and the exact test, and that they will make a reasonable choice wherever the plan leaves one open. What they cannot know is what you decided: which files, which names and signatures, which values from the spec, which tests prove each task. Document those. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits. Announce at start: "I'm using the writing-plans skill to create the implementation plan." Context: If working in an isolated worktree, it should have been created via the superpowers:using-git-worktrees skill at execution time. Save plans to: docs/superpowers/plans/YYYY-MM-DD- .md (User preferences for plan location override this default) If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own. Before defining tasks, map out which files will be created or modified and

这里只展示节选，请以完整原文和当前要求为准。