ohos-req-requirement-intake

name	ohos-req-requirement-intake
description	Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline).

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 评审时无法判定是刻意决策还是遗漏