Writing Plans

核心用法

writing-plans skill 是一种计划先行的工程方法论工具，用于在多步骤开发任务开始前，为假设零上下文的工程师生成完整的实施蓝图。其核心流程包括：在独立 worktree 中运行 → 解析需求/规格说明 → 输出结构化 Markdown 计划文档 → 提供两种执行路径选择（本会话子代理驱动 / 新开会话并行执行）。

显著优点

1. 认知卸载彻底：假设执行者" skilled but clueless"，强制文档化所有隐含上下文（文件路径、依赖、测试策略），显著降低知识传递成本
2. TDD 内建：每个任务拆解为"写失败测试→运行确认→实现→验证→提交"的 2-5 分钟原子单元，将测试驱动开发固化为流程
3. 执行路径灵活：支持子代理逐任务迭代（适合复杂/高风险功能）或批量并行会话（适合确定性高的任务），兼顾质量与效率
4. DRY/YAGNI 原则锚定：文档头部强制声明架构取舍，避免过度设计

潜在局限与风险

• 计划刚性成本：高度细粒度的计划可能在探索性开发中成为束缚，适合需求明确的任务，对高度不确定的 R&D 场景可能过度约束
• 维护负担：计划文档与代码双轨维护，若执行中大幅调整，计划文档易沦为"过期设计文档"
• 工具链依赖：深度绑定特定子代理系统（superpowers:executing-plans / subagent-driven-development），跨平台迁移成本未知

适合人群

分布式团队的技术负责人、需要严格代码审查流程的合规场景、新成员 onboarding 时期的高风险模块开发。

常规风险

• 路径漂移：执行者偏离计划却不更新文档，导致计划-执行断层
• 过度计划化：将本可 30 分钟完成的简单任务包装为 10 步计划，产生仪式化 overhead
• 权限边界：子代理驱动的执行模式需明确文件系统/网络访问权限，避免计划中的命令意外越权

Writing Plans 技能评估

核心用法

Writing Plans 是一款纯文档型工程管理技能，专为多步骤开发任务设计。用户在有明确需求或技术规格但尚未编码时启用，输出一份可立即执行的详细实施计划。核心假设：目标工程师技术过关，但对代码库、工具链和问题域零认知。

使用流程四阶段：
1. 前置准备：必须在由 brainstorming 技能创建的独立 worktree 中运行
2. 计划生成：按固定模板输出 markdown 文档，保存至 docs/plans/YYYY-MM-DD-<feature-name>.md
3. 任务拆解：每个任务严格控制在 2-5 分钟可完成的单一动作（写失败测试→运行确认→实现→验证→提交）
4. 执行交接：生成计划后提供两种执行路径——当前会话子代理驱动（superpowers:subagent-driven-development）或新开并行会话（superpowers:executing-plans）

显著优点

• 极致可操作性：要求写出完整代码而非描述性文字（"not 'add validation'"），消除理解歧义
• TDD 内建：强制红-绿-重构循环，每个任务以测试驱动，降低实现偏差
• 防御性设计：假设执行者"questionable taste"和测试设计能力不足，通过模板约束输出质量
• 灵活执行模式：子代理模式适合快速迭代、逐任务审核；并行模式适合批量执行、长时运行
• 工程规范内置：DRY、YAGNI、频繁提交等原则显性写入指导

潜在局限

• 语境依赖重：必须配合 brainstorming 创建的 worktree 使用，单独使用可能上下文缺失
• 模板刚性：Header 和 Task Structure 格式强制，轻度任务可能显得过度结构化
• 未覆盖非编码工作：纯聚焦代码实现，UI/UX 设计、需求澄清、运维部署等环节需其他 skill 补足
• 人力成本：2-5 分钟粒度的任务拆分，大型功能可能产生数十个任务，计划编写本身耗时显著

适合人群

• 中大型软件项目的技术负责人/架构师，需要将设计转化为可分发、可追踪的开发任务
• 远程团队协作场景，需异步传递精确到文件路径和代码行的执行指令
• 测试驱动开发（TDD）践行者，或希望向团队导入 TDD 实践的组织
• AI 辅助编程工作流用户，计划作为人类与 AI 子代理之间的结构化接口

常规风险

• 计划与实际偏差：再详尽的预设计也无法完全预测实现障碍，需预留调整机制
• 过度工程化：模板要求可能诱导对简单功能进行不必要的复杂拆解
• 执行者依赖：若选用"Parallel Session"模式，新开会话的上下文初始化失败可能导致计划理解偏差
• 无回滚策略：文档未提及任务失败或测试意外通过时的处理流程，建议补充 contingency 章节