skills/ohos-req-value-decision/SKILL.md
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
npx skillsauth add openharmonyinsight/openharmony-skills skills/ohos-req-value-decisionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Announce at start: "我正在使用 ohos-req-value-decision skill 记录评审决策纪要。"
Phase 0 Step 0.6 — 评审会议后的决策纪要回流。在 review-gate(0.5)和 review-ppt-gen 之后、feature-to-ir(0.7)之前。
review-gate(0.5) → review-ppt-gen → [评审会议] → value-decision(0.6) → (接纳) → feature-to-ir(0.7)
├─ 不接纳 → 关闭/归档
└─ 下次重新上会 → 退回对应 Step
评审会议纪要中的结论表述可能不标准。以下规则将非标准表述映射为三选一决策:
| 会议纪要原文 | 映射结论 | 理由 | |-------------|---------|------| | "接纳"/"通过"/"同意" | Accepted | 明确通过 | | "不接纳"/"不通过"/"否决"/"驳回" | Rejected | 明确否决 | | "下次重新上会"/"有条件通过"/"基本同意但需修改" | PendingRe-review | 需要修改后重审 | | "原则上同意" | 要求用户明确 | "原则上同意"是歧义表述,必须追问:是接纳(修改意见在后续阶段处理)还是下次重新上会(修改后重审)?不可自行推断 | | 无法判断结论 | 要求用户明确 | 不可凭模糊表述自行决策路由方向 |
Before mapping a conclusion, ask yourself: "Did the user explicitly state one of the three outcomes, or am I inferring it?" If inferring, ask the user to clarify.
Before choosing the rollback Step, ask yourself: which is the lowest-numbered doc requiring modification? Am I tracing each modification requirement to its source document?
Before extracting review opinions, ask yourself: does each opinion have both a handling method and an owner? If not, mark [待补充] rather than leaving blank.
[待补充] 并在自检环节提示。PendingRe-review 时需标注退回哪个 Step。判定依据:
| 修改要求涉及的文档 | 退回 Step | 理由 | |-------------------|----------|------| | 01-requirement.md 需修改 | Step 0.1 | 需求基线变更,下游 02-04 全部需级联更新 | | 02-feasibility.md 需修改 | Step 0.2 | 可行性结论变更影响 03/04 | | 03-arch-decision-record.md 需修改 | Step 0.3 | 方案变更影响 04 | | 04-feature.md 需修改 | Step 0.4 | Feature 内容调整 | | 多个文档需修改 | 退回最低编号 Step | 从源头修复,避免中间文档不一致 |
{
"schema_version": "1.0",
"skill": "ohos-req-value-decision",
"feature_id": "<FEAT-YYYYMMDD-NNN>",
"rr_id": "<从 01-requirement.md frontmatter 继承>",
"review_date": "YYYY-MM-DD",
"participants": ["张三", "李四"],
"decision": "Accepted | Rejected | PendingRe-review",
"review_opinions": [
{"id": "R-1", "opinion": "补充性能基线数据", "handling": "Phase 2补充", "owner": "李四"}
],
"modifications": [
{"doc": "01-requirement.md", "requirement": "补充用户场景量化数据"}
],
"routing": {
"action": "proceed | close | rollback",
"target_step": "0.7 | null | 0.1",
"target_skill": "ohos-req-feature-to-ir | null | ohos-req-requirement-intake"
},
"next_action": "可进入 feature-to-ir (Step 0.7) | 关闭/归档 | 退回 Step 0.X"
}
decision:仅取 "Accepted" | "Rejected" | "PendingRe-review",不可使用其他值routing.action:proceed(接纳→放行)/ close(不接纳→关闭)/ rollback(退回)routing.target_step:仅 rollback 时有值,取最低编号 Stepreview_opinions[].handling + review_opinions[].owner:每条意见必须两个字段同时存在,缺失时填 [待补充]按 JSON Schema 输出。Markdown 人读版仅含:评审日期、参与人、结论(status)、Feature ID、RR单号、评审意见表(编号/意见/处理方式/负责人)、修改要求(如有)、路由结论。
[待补充],不可留空或省略| 场景 | 行为 |
|------|------|
| 未提供评审会议纪要 | 追问用户:"请提供评审会议纪要,我需要从中提取决策结论和评审意见。" |
| 结论表述歧义(如"原则上同意") | 追问用户:"评审结论'原则上同意'是接纳(修改意见在后续阶段处理)还是下次重新上会(修改后重审)?" |
| 评审意见缺少处理方式或负责人 | 该字段填 [待补充],在自检环节提示用户补全 |
| review-gate JSON 显示 Not Ready | 提示用户:"review-gate 判定为 Not Ready,通常不应进入评审会议。请确认是否已通过 Gate。" |
{docs_dir}/value-decision-record.mddevelopment
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- 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). metadata: author: openharmony scope: common
testing
--- name: ohos-req-proposal-to-sr description: Use when every proposal associated with an OHOS IR has passed GATE A and a System Requirement baseline is needed before spec and design work begins. Triggers: 生成SR, proposal转SR, SR基线, 系统需求基线, GATE A通过, 05-proposal to SR. Do NOT use for IR generation (ohos-req-feature-to-ir), feature baseline (ohos-req-feature-baseline), or feasibility analysis (ohos-req-feasibility-analysis). metadata: author: openharmony scope: common stage: requirements ca