writing-plans

核心用法

writing-plans 是一个专门用于生成软件开发实施计划的文档型技能。当用户拥有产品规格或需求文档、准备开始多步骤开发任务时，该技能会创建一份详尽的 Markdown 格式实施计划。计划采用极致细粒度的任务拆分，每个任务控制在 2-5 分钟内完成，严格遵循 TDD（测试驱动开发）、DRY（不要重复自己）、YAGNI（你不会需要它）等工程原则。

使用流程上，该技能需在独立的工作目录（worktree）中运行，最终输出保存至 docs/plans/YYYY-MM-DD-<feature-name>.md。生成的计划文档包含强制性的标准头部（目标、架构、技术栈）、精确的文件路径、完整的代码示例、可执行的测试命令及预期输出，并明确标注需要配合使用的子技能（如 superpowers:executing-plans 或 superpowers:subagent-driven-development）。

显著优点

该技能的最大优势在于其零上下文假设的设计理念。它假设执行工程师对代码库一无所知、对技术栈不熟悉、甚至测试设计能力有限，因此计划文档会详尽到文件的具体行号、完整的代码实现、精确的命令和预期输出。这种"保姆级"的细致程度极大降低了沟通成本和执行偏差。

其次，细粒度任务拆分配合 TDD 流程（写失败测试→运行确认失败→最小实现→运行确认通过→提交），将复杂的开发工作拆解为可管理、可验证的微步骤，有助于保持开发节奏、快速获得反馈、降低认知负荷。此外，计划明确区分了"子代理驱动"和"并行会话"两种执行模式，为不同场景提供了灵活的选择。

潜在缺点与局限性

作为纯文档生成工具，writing-plans 本身不执行任何代码或命令，其有效性高度依赖于生成计划的质量和后续的人工或自动化执行。若计划中的文件路径、代码示例或命令存在错误，可能导致执行阶段失败。

此外，该技能对简单任务可能过度设计。对于单文件修改或 bug 修复，严格的 TDD 五步法可能显得繁琐。其预设的工程原则（TDD、频繁提交）也可能与某些团队的工作流不完全兼容。最后，计划文档的维护成本不容忽视——需求变更时，静态的 Markdown 计划可能迅速过时。

适合的目标群体

该技能最适合以下场景和人群：

• 大型功能开发：需要跨多个文件、模块协作的复杂需求
• 新成员 onboarding：帮助不熟悉代码库的开发者快速上手
• 远程/异步协作：为不同时区的团队成员提供可独立执行的标准化计划
• 代码审查准备：在动手编码前通过计划文档对齐实现思路
• 技术债务重构：将大规模重构拆解为安全、可回滚的小步骤

使用风险

• 计划与实现脱节风险：生成的计划基于静态分析，实际编码中可能发现未预见的依赖或阻塞，需动态调整
• 路径假设风险：计划中的文件路径基于约定或推测，可能因项目结构差异而失效
• 子技能依赖风险：完整执行需要配合 executing-plans 或 subagent-driven-development 技能，单独使用价值有限
• 过度规划风险：对于探索性、实验性开发，严格的预设计可能抑制迭代灵活性