评审决策纪要回流

SkillProductivity

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).

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the 评审决策纪要回流 skill

What this skill tells your AI

The instructions your AI receives, as published by openharmonyinsight/openharmony-skills in skills/ohos-req-value-decision/SKILL.md and read by ahel’s review.

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

适用边界

  • ✅ 适用:Phase 0 Step 0.6(评审会议后决策纪要生成与路由)
  • ❌ 不适用:Feature 评审就绪门禁(用 ohos-req-review-gate)、Feature 基线生成(用 ohos-req-feature-baseline)、IR 生成(用 ohos-req-feature-to-ir)

输入

  • 评审会议纪要(用户提供)
  • 01-requirement.md ~ 04-feature.md(现有产物)
  • decision_gate_{id}_{ts}.json(review-gate 产出)

决策歧义处理规则

评审会议纪要中的结论表述可能不标准。以下规则将非标准表述映射为三选一决策:

会议纪要原文映射结论理由
"接纳"/"通过"/"同意"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.

流程

  1. 读取评审会议纪要。如果用户未提供会议纪要,禁止凭空生成决策记录 — 追问用户。
  2. 按上表将结论映射为 Accepted / Rejected / PendingRe-review。遇歧义表述时追问用户明确。
  3. 提取评审意见:每条意见必须有处理方式负责人。缺失时标记 [待补充] 并在自检环节提示。
  4. 根据 conclusions 路由:
    • Accepted:生成 value-decision-record.md(status: Accepted),放行 feature-to-ir
    • Rejected:生成 value-decision-record.md(status: Rejected),关闭/归档
    • PendingRe-review:生成 value-decision-record.md(status: PendingRe-review),标注需退回的 Step 和修改要求
  5. 更新 04-feature.md 的评审状态(如有修改)

退回 Step 判定规则

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.4Feature 内容调整
多个文档需修改退回最低编号 Step从源头修复,避免中间文档不一致

输出契约

JSON Schema(机读)

{
  "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.actionproceed(接纳→放行)/ close(不接纳→关闭)/ rollback(退回)
  • routing.target_step:仅 rollback 时有值,取最低编号 Step
  • review_opinions[].handling + review_opinions[].owner:每条意见必须两个字段同时存在,缺失时填 [待补充]

决策纪要格式

按 JSON Schema 输出。Markdown 人读版仅含:评审日期、参与人、结论(status)、Feature ID、RR单号、评审意见表(编号/意见/处理方式/负责人)、修改要求(如有)、路由结论。

NEVER

  • 禁止在未提供评审会议纪要时凭空生成决策记录:决策结论必须来自用户提供的评审会议纪要,AI 不得替用户做决策
  • 禁止将"原则上同意"直接映射为 Accepted:这是歧义表述,必须追问用户明确是接纳还是下次重新上会
  • 禁止将 PendingRe-review 的退回 Step 留空:必须按退回 Step 判定规则标注具体 Step 编号
  • 禁止在 review_opinions 中省略 handling 或 owner 字段:缺失时填 [待补充],不可留空或省略

错误处理

场景行为
未提供评审会议纪要追问用户:"请提供评审会议纪要,我需要从中提取决策结论和评审意见。"
结论表述歧义(如"原则上同意")追问用户:"评审结论'原则上同意'是接纳(修改意见在后续阶段处理)还是下次重新上会(修改后重审)?"
评审意见缺少处理方式或负责人该字段填 [待补充],在自检环节提示用户补全
review-gate JSON 显示 Not Ready提示用户:"review-gate 判定为 Not Ready,通常不应进入评审会议。请确认是否已通过 Gate。"

自检

  • 决策结论明确(Accepted/Rejected/PendingRe-review),非歧义推断
  • 评审意见每条有处理方式和负责人(缺失标 [待补充])
  • PendingRe-review 时有明确修改要求和退回 Step 编号
  • 退回 Step 为修改要求涉及的文档中最低编号
  • value-decision-record.md 已生成
  • JSON 输出 schema_version 1.0 字段完整
  • routing.target_skill 与 target_step 一致

输出

  • 路径:{docs_dir}/value-decision-record.md
  • 回传:结论 + 评审意见数 + 路由动作 + 退回 Step(如有)

Signals

GitHub stars
34
Forks
7
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
ohos-req-value-decision
Source
github.com/openharmonyinsight/openharmony-skills