requirement-decomposition

需求分解

核心原则

需求分解 input 只校验已选方案和需求实现方案 artifact 是否存在且完成；产品子需求拆分和当前产品特性拆解方案的评审属于本阶段 output gate，未通过时不能输出正式特性拆解结果；特性拆解方案评审通过后，不得追加最终拆解二次确认。

本 Skill 是 requirement-design 的内部阶段能力，只负责把已选方案和需求实现方案分解成产品子需求、当前产品特性影响和 feature-doc-design 输入。它不写正式特性文档，不开发，不测试，不提交，不创建 PR，也不推进 PMS 状态。

未读取现有 docs/features/**/feature.md，不得声明新增、修改、删除或不变的特性影响。

跨产品需求未完成产品子需求拆分评审，不得拆当前产品特性。

产品子需求拆分评审或特性拆解方案评审请求发给人之前，必须先按对应 subagentPreReview 调度独立 reviewer 子代理；未取得“材料可提交人工审查”预审结论时，不得请求人工评审通过。

当前产品特性拆解方案和计划未评审通过，不得输出正式特性拆解结果。

特性拆解结果不得写 docs/features/**，不得进入开发准备。

新增或修改特性缺少特性四段式设计输入时，不得移交 feature-doc-design。四段式输入必须覆盖 feature.md、technical-design.md、data-model.md 和 business-flow.md。

本阶段不得生成开发计划、测试计划、源码变更、测试代码、提交、推送、PR 或 PMS 状态推进。

什么时候使用

当需求实现方案已经被选定，并且需要拆成产品子需求和当前产品特性拆解输入时使用。

不要在以下情况使用：

• 方案还只是思路候选，或用户仍在比较方案。
• 已选方案或需求实现方案 artifact 缺失。
• 用户要求写正式 feature.md、研发计划、测试计划或代码。
• 用户要求 Nucleus 作为 PMS 后端、PMS 下游工具或独立 Agent 服务推进状态。

本阶段只做什么

• 验证已选方案和需求实现方案 artifact。
• 读取 docs/features/**/feature.md 和必要的特性上下文。
• 判断需求是否跨产品；跨产品时先拆产品子需求并等待评审。
• 输出当前产品特性拆解方案和计划，并等待评审。
• 在特性拆解方案评审通过后，输出正式特性拆解结果和 feature-doc-design 输入。
• 按需调用 multi-review 检查完整性、一致性、越界和证据风险。

本阶段不做什么

• 不重新选择方案，不重新判断需求是否接纳。
• 不替 requirement-design 编排整个需求设计任务包。
• 不替人评审产品子需求拆分或特性拆解方案。
• 不把按钮、字段、表、接口或操作步骤当成 feature。
• 不把四段式设计输入当作正式 docs/features/** 文档写入。
• 不写正式 docs/requirement/**。

行为步骤

1. 验证入口事实。

   • 读取 .nucleus/context/<workflowRunId>.json、已选方案和需求实现方案 artifact。
   • 记录后续 output gate 需要引用的人工事实字段，但不把上游评审是否文件化作为本阶段 input 阻塞。
   • 缺少真实依赖时必须 ALERT_AND_BLOCK。

2. 读取产品和特性事实。

   • 读取相关 docs/features/**/feature.md。
   • 必要时读取 feature group 的 technical-design.md、data-model.md、business-flow.md。
   • 能从仓库事实判断的特性放置，不得问用户。

3. 处理跨产品子需求。

   • 跨产品时，输出产品子需求拆分候选，说明每个产品承担的子需求、边界、依赖、协作点和风险。
   • 输出后必须停在产品子需求拆分评审；评审通过前不得拆当前产品特性。
   • 不跨产品时，记录跳过原因和证据，不能静默跳过。

4. 输出当前产品特性拆解方案和计划。

   • 基于当前产品子需求或非跨产品需求，分析拟新增、修改、删除和保持不变的特性。
   • 每个拟影响特性都必须说明目标 feature path、拆解理由、依赖关系、优先级和后续 feature-doc-design 输入。
   • 每个新增或修改特性都必须提供四段式设计输入。
   • 计划只说明特性拆解方案，不写正式特性文档，不写开发任务。