writing-plans

编写计划

在交接前敲定所有实现决策。执行者编写代码；规划者明确约定、步骤、模式和验证依据，消除选择实现方案的需要。计划中不得包含生产代码和完整测试代码；仅在需要消除歧义时，才包含签名、数据示例或简明算法。

输入：需求、目标仓库、当前问题或文档，以及范围约束。输出：一份与需求及已检查修订版本相绑定的当前实现计划，其中包含已解决的决策、确切路径／符号、有序步骤、验证映射和阻塞式就绪结果。

写入：需求问题中的 ## Implementation Plan 评论，或单一规范本地文档中的计划部分，且不得超出授权发布范围。不得修改实现文件，也不得自主分派执行者。读取仓库和跟踪系统。仅针对缺失的授权或会产生重大影响的意图提出询问；对本问题进行规划的授权已涵盖此范围，因此无需重复征求批准。如果发布由协调流程负责，则向其返回草稿。

可选配套工具：prd-quality-gate（规范计划模板和执行就绪检查）以及 executing-plans（scripts/plan-header.mjs）。这两者均不随此技能提供。如果无法使用，请使用以下清单进行就绪检查，并手动记录基础提交和需求文本的哈希。

约定

输入：

• 需求、目标仓库、当前问题或文档，以及范围约束。
• Harness 选定的规划者和授权发布范围。

输出：

• 一份与需求及已检查修订版本相绑定的当前实现计划。
• 已解决的决策、确切路径／符号、有序步骤、验证映射和阻塞式就绪结果。

创建／修改：

• 需求问题中经授权的 ## Implementation Plan 评论，或单一规范本地文档中的计划部分。
• 不得修改实现文件，也不得自主分派执行者。

外部副作用：

• 读取仓库／跟踪系统，以及经授权发布计划。

所需确认：

• 仅针对缺失的授权或会产生重大影响的意图提出询问。准备或规划此问题的授权已涵盖此范围；无需重复征求批准。 如果发布由协调引擎负责，则向其返回草稿。

委派给：

• 运行委派技能时，读取其同级目录下的 ../<name>/SKILL.md 并遵循其中说明；此处的技能仅由用户调用，因此 Skill 工具无法加载它们。
• prd-quality-gate，用于获取规范计划模板和执行就绪检查。

研究并作出决策

1. 阅读实时需求、相关注释、仓库说明和架构、当前修订版本及现有实现。若可用，从 prd-quality-gate 加载规范的执行就绪度参考。
2. 梳理现有路径／符号和至少三个相近模式；若不足三个，记录搜索范围和现有证据。明确标注拟新增的文件和符号。遵循仓库架构，不进行推测性重构。提供相关源代码证据，不要只给容易失效的行号。
3. 在适用时，明确解决架构、接口、数据形状、验证、授权、并发、错误、兼容性、UI 状态、迁移和发布行为。指定名称和具体规则；避免使用“妥善处理”“选择一个库”或“遵循最佳实践”等表述。
4. 在一个计划和一个 Issue 中涵盖完整功能。技术层应作为步骤，而非拆分为多个完成任务。只有确实需要拆分时，才应用共享的独立结果规则；保留父项的验收和集成义务。
5. 每个步骤都必须明确具体文件／符号、变更内容、选定的模式和决策参考、前置条件及完成条件。按逻辑确定步骤大小，不要限制固定分钟数，也不要要求每做一点微小改动就提交一次。每个步骤都必须使用规范模板，并包含 Touch（所有允许修改的路径，包括生成的输出）、Pattern（现有路径／符号、决策 ID，或附理由的 None）、Check（精确命令、工作目录和预期结果）以及 Stop if（需要规划者介入的条件）。执行者只能修改 Touch 中的路径。
6. 识别需求所隐含、但现有检查尚未覆盖的最重要输入类别或故障模式。将每项对应到所属步骤和具体 fixture；若没有遗漏，记录已检查且无遗漏。将每个验收 ID 映射到决策、步骤和具体检查。检查命令定义和 CI 配置；记录工作目录、允许的执行主机、环境／fixture 及预期结果。拟议新增测试必须提供精确路径、行为／fixture，以及通过已验证运行器调用的方法，而不是完整测试代码。
7. 记录可复现的基础提交、需求指纹和计划修订版本。若 executing-plans 的 scripts/plan-header.mjs digest 命令可用，则使用该命令基于已保存的 Issue 正文计算指纹。所有就绪度检查通过后，在草稿中设置 Readiness: READY，并在发布前确认 plan-header.mjs check（若可用）对当前 head 检查通过。解决所有规划者负责的未知项。用户意图未明或前置条件不可用时，必须明确列为阻塞项，绝不能把选择交给下游执行者。

审查、存储与交接

以阻塞式 execution-readiness 模式运行 prd-quality-gate（或手动应用上述检查）。修复覆盖缺口、名称／契约不一致、含糊选择和未经验证的命令假设。给出附有证据的结论，不要只写标题式检查结果。

在现有授权范围内发布，或将草稿交还协调者。将需求保留在 Issue 正文中，并在该 Issue 上保留一条当前的 ## Implementation Plan 评论。遵循共享元数据和新鲜度协议。链接当前评论并明确标记旧计划已被取代；不要将含糊的计划拆散到未标注的多条评论中。如果内容超出跟踪系统限制，应减少重复内容，或拆分为确实独立的结果，而不是截断决策。

报告 Issue／计划链接、检查的修订版本、就绪度结论和阻塞项。 不要编造派发标签，也不要让用户选择执行策略。执行前必须进行实时新鲜度验证。任何实现缺口都必须退回规划者；执行者不得修改决策或验收标准。