（6436期）Writing Plans – 把模糊需求切成可执行的原子任务

把模糊需求切成可执行的原子任务 为复杂多步任务生成可执行实现计划，强制小粒度任务、TDD、DRY/YAGNI原则，适合零上下文开发者执行 使用说明 核心功能与定位 Superpowers Writing Plans 是一款面向软件开发团队的结构化实现规划工具，专为降低复杂功能交付的认知负荷而设计。其核心使命是在编码开始前，将模糊的产品规格转化为开发者可逐步执行的、原子化的任务序列。 显著优点 极致的可执行性：与其他"高屋建瓴"的架构文档不同，该技能强制要求每个任务步骤控制在2-5分钟内完成，且必须包含可直接复制的代码、命令和文件路径。这种"零歧义"标准极大降低了执行者的认知负担。 TDD 原生嵌入：测试驱动开发不是可选项，而是计划结构的一部分——每个功能任务必须包含"写失败测试→运行确认失败→实现代码→运行确认通过"的完整循环，从流程上保证测试覆盖率。 防御性设计哲学：通过 DRY（避免重复）、YAGNI（不做预设）、频繁 commit 等原则约束，防止开发者在实现过程中过度工程化或引入技术债务。"假设执行者对代码库零上下文"的设定确保了文档的自完备性。 严格的质量门禁：自审环节要求扫描规格覆盖缺口、占位符残留、类型命名一致性三类问题，在计划阶段而非编码阶段拦截错误。 潜在局限 overhead 成本：对于简单功能（如修改配置项），完整遵循该流程可能显得冗余，任务拆分粒度可能过细 上下文切换损耗：严格的"子 Agent 驱动"或"顺序执行"模式在小型团队中可能引入不必要的协调成本 工具链依赖：深度依赖 git、pytest、markdown 等特定工具，对非 Python/非 git-flow 团队需要适配 适用人群 技术负责人/Staff Engineer：需要将模糊需求拆解为可外包、可并行化的开发任务 新成员 onboarding：通过标准化的计划文档快速理解代码库结构和团队规范 远程/异步协作团队：计划作为"唯一事实来源"，消除时区差异带来的沟通延迟 风险提示 计划僵硬化风险：过度详细的预设可能抑制实现过程中的合理调整，需配合 superpowers-finishing-branch 的清理流程灵活应对 规格质量依赖：若输入规格本身存在逻辑矛盾，技能会忠实地将其转化为自相矛盾的计划，需配合 brainstorming 技能预先验证规格完整性 原始说明 Use when you have a spec or requirements for a multi-step task, before touching code - guides writing comprehensive implementation plans with bite-sized task...