核心用法
superpowers-writing-plans 是一个结构化工程规划技能，专为多步骤复杂任务设计。使用时机：已有明确规格或需求文档，但尚未开始编码。核心流程包括：
1. 范围检查 — 验证规格是否可分解为独立子系统，每个子系统对应独立可交付的计划
2. 文件结构映射 — 在定义任务前锁定分解决策：明确每个文件的职责边界、接口定义、变更范围
3. 小粒度任务分解 — 每个任务为 2-5 分钟可完成的原子动作（写失败测试→验证失败→写最少实现→验证通过→commit）
4. 零占位符原则 — 计划必须包含执行者所需的全部实际内容：精确文件路径、具体代码块、预期命令输出
5. 自审机制 — 完成后执行规格覆盖检查、占位符扫描、类型一致性验证
显著优点
- 极端可执行性：假设执行者"有技能但零上下文"，消除隐性知识依赖，降低协作摩擦
- TDD 原生集成：将测试驱动开发嵌入计划结构，非可选建议而是强制步骤
- DRY/YAGNI 原则内建：通过细粒度任务和代码示例重复，自然抑制过度工程
- git 工作流就绪：包含分支管理、commit 规范、完成后的 finishing-branch 衔接
- 双模式执行：支持子 Agent 并行驱动或顺序执行，适应不同规模项目
潜在缺点与局限性
- 计划开销高：简单功能可能产生过度文档，适合 4 小时以上的开发任务
- 刚性约束："无占位符"规则在探索性开发或快速原型阶段可能成为负担
- 文件系统假设：路径格式偏向 Unix/Python 生态，其他语言/环境需适配
- subagent 依赖：推荐的最佳实践依赖
superpowers-subagent-dev技能，单会话执行时失去并行优势 - OpenClaw 适配注释：原版 git worktree 机制需替换为分支模型，可能增加上下文切换成本
适合人群
- 需要为分布式团队编写可移交开发任务的 Tech Lead
- 执行 TDD 但缺乏系统化计划习惯的中高级开发者
- 维护遗留代码库、需精确控制变更范围的重构场景
- 与经验参差开发者协作的代码审查场景
常规风险
- 计划-执行漂移：即使计划详尽，执行中仍可能发现规格盲点，需内置反馈机制
- 过度分解：极端细粒度可能导致 commit 噪音，需权衡"频繁 commit"与"有意义变更"
- 类型/接口漂移：跨任务引用的一致性依赖人工自审，无自动校验
- 安全报告占位：源文档安全认证为占位符，实际风险需结合具体执行环境评估