plan-work

规划工作

将不确定或规模较大的工作整理成可执行的方向，而不刻意制造繁文缛节。

使用 workflow-language.md、document-conventions.md 和 planning-templates.md。

调用与输出

当用户明确提出请求，或工作存在实质性的不确定性、协作需求、跨领域范围、不可逆性或风险时，使用此技能。仅仅是新工作、多步骤工作或非简单工作，并不意味着需要制定计划。

明确调用时，遵循用户要求的输出格式。如果用户要求不要写入文件，就完成规划工作并在聊天中返回。否则，默认保存一份临时 Plan。规划流程和创建 Plan 文件是两个独立的决定。

不要开始实施。

流程

1. 阅读仓库内的说明、当前文档、相关代码以及已有的 Plans 或 Roadmaps。
2. 仅针对可能实质性改变设计的未决问题进行研究；优先查阅仓库内和一手资料。
3. 仅询问仓库无法解答且会阻碍决策的问题。合并相关问题，并提供附有权衡说明的推荐选项。
4. 当方向需要负责人批准时，提供简明的设计简报。如果方向已明确，则跳过重复确认环节。
5. 产出所请求的规划结果。若要保存 Plan，使用 plans/<outcome>.md；仅当多个 Plans 需要优先级排序或进度跟踪时，才创建 Roadmap。
6. 交付前检查内容是否连贯、可执行、范围明确，并核验验证方案和文档生命周期。

当领域术语、状态、关系、不变量、数据流或访问模式是设计的关键依据，或其含义不明确时，应先明确建模，再规划逻辑。针对当前代码和文档，用一两个具体场景对关键术语、关系和不变量进行压力测试。以仓库 Glossary 为准；仅当简洁的调用栈、组件树或数据流示意图有助于解决设计决策时，才添加此类示意图。不要悄然更改规范术语或文档；应在获准的草案或按 Phase 标注的 Doc Delta 中记录未来变更，并明确提出需要负责人决策的事项。

不要创建其内容依赖于尚未解决的关键设计决策的下游 Tasks。如果不同的可行答案会实质性改变数据或模式模型、所有权、契约、迁移或验证方式，该决策就属于关键设计决策。

如果验证方案需要添加模块模拟或大量新的端到端基础设施，应将其作为需要负责人决策的明确事项，并说明其耦合性、维护成本和执行成本。仓库惯例优先于专业技术栈指南。

产物归属

• Roadmap 是对 Plan 链接、候选事项和跨 Plan 约束的精简归组。它可以是主 Roadmap，也可以限定在特定范围内；其排序方式必须标注为 Loose、Strict 或 Mixed。在能够明确说明实施结果和阻塞性问题之前，Candidate 应保持粗略；满足条件后再将其提升为 Plan。
• Plan 负责可选的 Milestones、Phases、Tasks、验收标准、验证方案、评审安排和 Doc Delta。
• Phase 是实施和评审的范围。每个 Phase 都必须包含一次在全新上下文中对其完整范围进行的独立评审。
• 仅在高影响 Tasks 或 Task 组之后添加中间评审检查点。低影响 Tasks 可留待 Phase 评审。
• Target-State Doc 记录当前持久有效的事实。只有纠正内容已经属实时，才在规划期间进行更正。
• 对拟新增的重要持久文档，使用 Draft Target-State Doc。
• 对现有规范文档的未来变更，应写入 Plan 的 Doc Delta，并为每一项明确标注 Phase。
• 仅当决策出乎意料、权衡重大且难以逆转时，才使用 ADR。

创建或更新 Plan 之前，仅处理本身具有独立价值的当前文档或重要草案。未来对现有文档的变更由 Plan 负责，因此 Doc Delta 应作为 Plan 的一部分编写，而不是事先准备。

计划质量

仅保留能指导执行的上下文。请确认：

• 决策、文档、计划任务和验收标准彼此一致；
• 阶段边界清晰，便于审查；
• 验证能够证明所声称的结果；
• 审查检查点反映风险，而非任务数量；
• 每项文档变更都有明确的阶段；
• 未解决的决策清晰可见，下游任务不会假定关键决策已有定论；
• 适用时，明确关键的领域和数据模型决策；
• 工作流文件不会被当作永久产品文档。

直接修复明显的问题。若请求创建或修改文件，请返回文件路径，并附上简短摘要以及仍需负责人决定的事项。