# Ohos Req Requirement Intake

> OHOS 需求导入

- Skill: `openharmonyinsight/ohos-req-requirement-intake` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add openharmonyinsight/ohos-req-requirement-intake`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openharmonyinsight/ohos-req-requirement-intake/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: openharmonyinsight (https://skillmd.com/u/openharmonyinsight)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openharmonyinsight/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）