openharmonyinsight/skills/ohos-req-requirement-intake

OHOS 需求导入

Announce at start: "我正在使用 ohos-req-requirement-intake skill 生成 01-requirement.md。"

定位

OHOS 电子流需求管理系统的 RR单号（rr_id）是跨 Phase 0-9 的唯一追溯键，从 01-requirement.md frontmatter 继承到 IR/SR/handoff 全链路。requirement 阶段的澄清状态（Draft-NeedsClarification → Clarified）决定 feasibility 是否允许启动——电子流系统据此判定需求是否进入分析阶段。requirement 不得包含技术方案选型，确保 feasibility 的选型中立性。

Do NOT Load

本 skill 仅在 Phase 0.1（01-requirement.md 生成）时激活。以下场景不应加载：

• 可行性分析（02-feasibility.md）→ ohos-req-feasibility-analysis
• 方案架构决策（03-arch-decision-record.md）→ ohos-req-arch-decision
• Feature 评审基线（04-feature.md）→ ohos-req-feature-baseline
• Review Ready Gate → ohos-req-review-gate
• IR 生成 → ohos-req-feature-to-ir

⭐ 硬规则：禁止不确定项输出

01-requirement.md 是 feasibility 的唯一事实输入，任何不确定项都会向后传播并放大。

禁止出现以下任何占位符或模糊表述：

| 禁止项 | 说明 | 原因 | |--------|------|------| | "待确认" | 必须在澄清环节关闭 | 占位符会传播到 feasibility 的事实输入，导致可行性分析基于假设而非事实 | | "待分析" | 必须在澄清环节确认或排除 | feasibility 的评估范围依赖 requirement 确认的边界，待分析会导致工作量估算范围不确定 | | "待采集" | 必须在澄清环节明确采集方案和 Owner | 无采集方案的指标在下游无法验证，电子流系统无法判定需求验收就绪 | | "暂不设指标" | 必须在澄清环节决定：设指标还是确认不设（附理由） | 无理由的"暂不设"在 Gate 评审时无法判定是刻意决策还是遗漏 | | " TBD / TODO / FIXME " | 任何形式的占位符 | 电子流系统将 TBD 视为未完成需求，阻断需求流转 | | 模糊表述 | "快速""稳定""尽可能""优化""提升"等无量化锚点的描述 | feasibility 无法将模糊表述转化为可验证的技术约束，导致 AC 不可观察 |

生成 requirement.md 时，所有字段必须填写已确认事实。如果某项事实缺失，不得写入占位符，而是在澄清环节向用户提问获取答案。

唯一例外：用户明确说"这个我不确定，先放一下"时，可标记为 ⚠️ 用户暂缓:{用户原话}，但必须在回传摘要中单独列出，并计入未关闭澄清项。

⭐ 思维准则

在 01-requirement.md 中写入任何字段前，自问：这是来自用户的已确认事实，还是假设？若是假设 → 写入 clarification-questions.md，而非正文。

Before writing a placeholder, ask yourself: 能否在输入材料（Issue/PRD/会议纪要/设计方案）中找到这个字段的答案？如果可以 → 批量确认而非逐条提问。

Before 定稿, ask yourself: 每条 NFR 是否有基线值+目标值（而非"提升XX%"）？每条 FR 是否有来源依据？RR单号是否已回填或合规标注"未立项"？

输入

• 用户原始描述、Issue、PRD、会议纪要或用户反馈
• 已确认的范围、版本、约束和指标口径
• RR单号（如有）：需求管理系统中的追踪编号

流程（两阶段：草稿 → 澄清 → 定稿）

模板与产物命名

• 模板路径：reference/requirement.md（模板文件不带 01- 阶段编号前缀）
• 产物路径：{docs_dir}/01-requirement.md

第一阶段：草稿生成

1. 读取 reference/requirement.md。

2. 保留需求方原意，将内容归入模板对应章节。

3. 模板保真：必须沿用模板中的 frontmatter、H1、H2 标题，参考模板的表格结构；不得新增模板外的 H1/H2 章节。

4. 必须包含字段 表中的 FR/NFR、受影响模块、优先级等信息，只能归入模板已有章节：

   • 功能点、用户场景、价值 → ## 4. 期望
   • 产品、地区、设备、开发者范围 → ## 5. 适用设备/产品形态
   • NFR、约束、版本、性能/功耗 → ## 6. 约束与期望
   • 证据、来源、受影响仓/路径 → ## 9. 附件与证据
   • 缺失事实和澄清项 → {docs_dir}/_draft/clarification-questions.md
   • RR单号 -> frontmatter rr_id + ## 1. 来源与背景 表格

5. 对缺失事实，不写入占位符，而是记录到「待澄清问题清单」。

6. 检查功能点与 FR、场景与价值、NFR 与量化口径之间是否可追溯。

7. 输出草稿到 {docs_dir}/01-requirement.md（frontmatter status: Draft-NeedsClarification）。

8. 同时输出澄清问题清单到 {docs_dir}/_draft/clarification-questions.md。

   澄清问题清单格式：

   • 每个问题编号 Q-1, Q-2, ...
   • 每条包含：问题描述、优先级(P0/P1/P2)
   • 澄清后在对应问题下方追加 **澄清结论** 段，标注 ✅(已关闭) 或 ⚠️(条件待验证)，附结论摘要

模板保真门禁（生成后必须自检）：

• [ ] H1 只能是 # 原始诉求
• [ ] H2 只能来自 reference/requirement.md
• [ ] 不存在 ## 功能需求、## 非功能需求、## 受影响模块 等模板外章节
• [ ] 模板已有表格未改名（若需调整结构应修改模板而非产物）
• [ ] 缺失事实只出现在 _draft/clarification-questions.md，不在正文中以占位符呈现

第二阶段：逐轮人工澄清 ⭐ 强制门禁

草稿生成后，必须暂停并进入逐轮澄清对话。不允许直接进入 feasibility。

澄清规则：

1. 主 Session 将「待澄清问题清单」逐条向用户提问
2. 每轮提问 ≤5 个问题（按 P0→P1→P2 优先级排序）
3. 批量确认已知答案（PIR #152 P2）：对输入材料（Issue/PRD/会议纪要/设计方案）中已有明确答案的问题（如 RR 单号、交付版本、提出人等），一次性呈现全部已知答案让用户批量确认（✅确认/✏️修正），不逐条单独交互。仅真正不确定的问题才逐条澄清。
4. 用户回答后，更新 requirement.md 对应章节（替换为确认事实）
5. 每轮澄清后立即回填结论到 clarification-questions.md：在对应问题下方追加 **澄清结论** 段，标注 ✅（已关闭）或 ⚠️（条件待验证/P2延后），附结论摘要和影响的下游文档章节。不允许只更新 requirement.md 而不回填 clarification-questions.md。
6. 每轮澄清后检查：
   • 是否产生新的待澄清项？→ 继续下一轮
   • 是否所有字段都有确认事实？→ 进入定稿检查
7. 澄清完成后执行定稿检查：

定稿出口门禁（全部 ✅ 才可进入 feasibility）：

• [ ] 「必须包含字段」表中所有"定稿必填"字段均有确认事实（逐项对照表格自检）
• [ ] 正文中无任何占位符（"待确认""待分析""TBD""FIXME"等任何形式）
• [ ] 正文中无模糊表述（"快速""稳定""尽可能""优化""提升"等无量化锚点）
• [ ] RR单号已回填或合规标注"未立项"并附依据
• [ ] clarification-questions.md 所有问题已回填 **澄清结论**，无未关闭项
• [ ] frontmatter status 已更新为 Clarified
• [ ] 模板保真：H1/H2 仅来自模板，无模板外章节，表格结构未改名
• [ ] 功能点↔FR、场景↔价值、NFR↔量化口径 之间可追溯

任何一项不通过 → 继续澄清，不允许进入 feasibility。

8. 定稿检查全部通过后，更新 frontmatter status: Clarified，输出最终版。

澄清状态检测（输入材料已有澄清结论时）

当用户提供的输入材料已包含澄清结论时（如标记为"已完成 P0 澄清"或包含 Q-1~Q-N 全部 ✅ 结论），skill 应：

1. 检测输入材料中的澄清状态标记或澄清结论覆盖度
2. 若已澄清完成且覆盖所有必填字段，只做格式归一化和定稿检查
3. 若定稿检查通过，直接输出 status: Clarified，跳过逐轮对话
4. 若定稿检查不通过（仍有不确定项），仍需逐轮澄清
5. 在回传摘要中标注"澄清状态: 已完成/需补充/无标记"

必须包含字段（草稿/定稿对照）

| 字段 | 草稿必填 | 定稿必填 | 说明 | |------|---------|---------|------| | 需求方/提出时间/来源/触发场景/现状和问题 | ✅ | ✅ | 归入 §1 来源与背景 | | RR单号 | ✅ | ✅ | frontmatter rr_id + §1 表格；无 RR单号时标注"未立项"并附依据 | | 用户痛点 | ✅ | ✅ | 必须有影响描述和严重程度（不是笼统"体验差"） | | 功能点/用户场景/价值 | ✅ | ✅ | 归入 §4 期望 | | 可量化目标 | ✅ | ✅ | 必须有基线和目标值（"提升XX%"不算量化） | | 产品/地区/设备/开发者范围/期望版本 | ✅ | ✅ | 归入 §5 适用设备/产品形态 | | FR | ✅ | ✅ | 必须有来源依据 | | NFR | ✅ | ✅ | 必须有量化口径（基线+目标值） | | 受影响模块 | ✅ | ✅ | 必须有具体仓/路径（不是"待确定"） | | 约束 | ✅ | ✅ | 归入 §6 约束与期望 | | 优先级 | ✅ | ✅ | P0/P1/P2 每项有判定依据 | | 证据 | ✅ | ✅ | 归入 §9 附件与证据 |

禁止包含

• 候选方案和推荐方案（原因：requirement 是 feasibility 的唯一事实输入，混入技术方案会污染可行性分析的选型中立性）
• 技术架构、接口设计和代码路径（原因：requirement 阶段的架构决策会在 03-arch-decision-record.md 被 feasibility 推翻，提前写入会导致文档冲突）
• 无依据的精确成本、ROI、性能或成功率（原因：requirement 阶段无源码验证能力，编造的数值会被下游 feasibility 的代码证据包证伪）
• 可行/不可行或批准/拒绝结论（原因：可行性判断属于 02-feasibility.md，批准/拒绝属于 03-arch-decision-record.md，提前下结论会跳过 Gate 门禁）
• 任何占位符或模糊表述（"待确认""待分析""TBD""尽可能"等）（原因：见上方「禁止项」表的原因列）

输出

• 路径：{docs_dir}/01-requirement.md（status: Clarified）
• 澄清问题清单：{docs_dir}/_draft/clarification-questions.md（澄清完成后保留，每个问题必须回填 **澄清结论**段；仅当全部问题已回填且 status 标记为"已完成"时才可考虑删除）
• 回传：路径、需求方、RR单号、目标版本、FR/NFR 数量、澄清轮次、未关闭项数量（必须为 0）