ohos-req-review-gate

OHOS Review Ready Gate (Structured Determination)

Announce at start: "I am using the ohos-req-review-gate skill to execute the Review Ready Gate on 04-feature.md."

Positioning

OHOS Review Ready Gate is the only independent subagent structured determination in Phase 0 — the main session already holds the full context of 01-04, and deriving the Gate on its own would produce confirmation bias, so the determination must be executed by a subagent with isolated context. The observations field of the Gate JSON output (PIR #152 P1) classifies metrics requiring actual measurement in Phases 5-7, such as performance/power consumption/memory, as observation items, which do not block the Ready determination and are tracked to closure in Phases 1-9.

Applicable Boundaries

✅ Applicable: Phase 0 Step 0.5 (Feature review readiness)
❌ Not applicable: Decision 0 (project initiation review), Decision 1 (solution confirmation), Decision 1.5 (SIG review), Decision 2 (Phase 4 review), Decision 3 (code review), Phase 5 Step 5.2 (design open-issues gate) — these are carried by the main session / subsequent phase processes
If other decision points also need to be materialized later, the JSON output contract of this skill can be referenced for replication and rollout

Input

{docs_dir}/01-requirement.md
{docs_dir}/02-feasibility.md
{docs_dir}/03-arch-decision-record.md
{docs_dir}/04-feature.md
reference/feature-checklist.md(Detailed definitions of check-item determination rules and edge-case handling,must be loaded and read in step 1 of the process）

04-feature.md When it does not exist,directly determine as Not Ready, and return an error explanation (do not attempt to infer).

Gate check items (8 fixed + 3 structural consistency + 1 legacy-issue closure = 12 items; conditional items are separate fields)

The 8 fixed checks correspond to feature.md §1-§5 (split decision and workload constraints both belong to §5) + technical direction (references 03-arch-decision-record.md) + impact analysis (a supplementary section outside the template), avoiding two sets of rules. The 3 structural consistency checks are newly added by this skill to ensure complete cross-document data propagation. The 1 legacy-issue closure check ensures that 03-arch-decision-record.md §6 is input from the user review meeting and its closure is traceable. Read item by item 04-feature.md the corresponding sections, and determine according to the following rules:

Fixed check items (8 items)：

Check item	Requirement	Determination method
Overview and value	Has core demands and business value description	§1 section exists and is not a placeholder
Clear scope	Goals and non-goals are listed	§2 section exists and is not a placeholder
Complete AC	Has observable metrics and verification methods	At least 1 AC row in §3 is not a placeholder
Affected scope	Clearly specifies cross-repo modules, Owner/SIG	At least 1 impact scope row in §4 is not a placeholder
Split decision	Has split conclusion and proposal boundaries	§5 section exists and is not a placeholder
Workload constraints	Each proposal does not exceed the complexity upper limit (simple ≤5 / standard ≤8 / complex ≤15 person-months)	The workload of each proposal in §5 does not exceed the corresponding complexity upper limit
Technical direction	Has a selected solution (references 03-arch-decision-record.md)	The selected solution references 03-arch-decision-record.md (the feature template has no corresponding section)
Impact analysis	All 5 parties' impact types have been analyzed	Impact analysis section (supplement outside the template), all 5 lines are non-placeholder

Structural consistency check items (3 new items, only make the Ready/Conditional/Not Ready decision determination, do not re-validate content)：

Responsibility boundary: ohos-req-feature-baseline The skill performs item-by-item validation and repair of module coverage completeness/terminology consistency during the generation period; this skill only makes the final Ready/Conditional/Not Ready decision determination and references the validation results of the feature skill (does not re-execute validation logic). Conditional item propagation completeness is unique to this skill (the feature skill does not involve cross-document tracing of conditional items in 02/03).

Check item	Requirement	Determination method
Module coverage completeness	04 §4 declares coverage of all involved modules (references the feature skill validation conclusion)	Read the conclusion field of "Module Coverage Check" in 04 §4; conclusion=pass→pass; conclusion=warn or missing→warn (block_reasons: "Module coverage check failed or was not executed")
Impact type terminology consistency	04 §4 impact type labels have no drift (references the feature skill validation conclusion)	Read the conclusion field of "Terminology Consistency Check" in 04 §4; conclusion=pass→pass; conclusion=warn or missing→warn
Conditional item propagation completeness	§5 split preconditions cover all conditional items in 02 §6 and 03 §6	Extract all conditional item numbers in 02/03, verify each appears in 04 §5; missing→warn

Open issue closure check item (1 new item)：

Check item	Requirement	Determination method
Open issue closure	The open issues in 03-arch-decision-record.md §6 are input by the user review meeting and each has a complete owner/solution action/planned closure time	Read 03 §6: ① contains placeholder annotation`[待用户评审会议后填写]`→fail (block_reasons: "03-arch-decision-record.md §6 open issues were not input by the user review meeting"); ② any open issue lacks owner/solution action/planned closure time→fail (block_reasons: "open issue three fields incomplete"); ③ no open issues (user determines none needed) or all complete→pass

Conditional item check (independent field)：

04-feature.md All items marked as "⚠️" or "not passed/unknown" must have an Owner and closure time point, otherwise they are escalated to failure items

Phase 0 observation items (do not block Gate determination)：

The closure of some conditional items depends on quantitative data that can only be obtained in Phase 5-7 (implementation + testing phase) (such as performance benchmark test results, measured power consumption data, memory usage baseline, etc.). Such conditional items objectively cannot be closed in Phase 0. If they are treated as Gate blocking items, the Gate will remain at Conditional Ready forever, the IR will remain Conditional forever, and handoff will remain ConditionalReady forever.

Classification rules：

Conditional item type	Determination basis	Gate impact	Tracking method
Phase 0 closable conditional item	The required information is obtainable within the Phase 0 scope (such as AC missing verification method, module coverage with exclusion reason, etc.)	Missing Owner/action/time point → escalate to fail, block Gate	Conditional item list
Phase 0 observation item	Close items that depend on Phase 5-7 measured data (performance benchmarks, power consumption measurements, memory baselines, stability tests, etc.)	Does not block the Gate Ready/Not Ready determination; the Gate conclusion is determined by other check items	Independent "Phase 0 observation items" field, tracked to closure in Phase 1-9

Observation item identification rules: When a condition item description contains quantitative metrics that require actual execution to obtain, such as "performance benchmark", "power consumption measurement", "memory usage baseline", "stability test", "stress test", etc., it is automatically classified as an observation item. Observation items still need to record an Owner and a target closure time point (pointing to the corresponding Phase 5-7 stage), but they do not affect the Gate conclusion.

Gate conclusion revision rules：

Ready: No fail, no closable warn items (observation items are not counted in the warn statistics)
Conditional Ready: No fail, there are closable warn items and each has an Owner/action/time point (observation items are listed separately and do not affect the escalation determination)
Not Ready: There are fail，orthere are closable warn items but they lack an Owner/action/time point

Process

Read reference/feature-checklist.md to obtain the Pass/Warn/Fail determination rules and edge case handling rules for each check item; read 04-feature.md(if it does not exist → directly Not Ready + error reason).
Read the contents of §1-§5 and the supplementary impact analysis section,citing only the necessary summaries(do not embed the full text of 01-04).
Determine each check according to the rules in the table above pass / warn / fail。
Collect all warn items, and according to theclassification rulesdistinguish between "Phase 0 closable condition items" and "Phase 0 observation items":
- Closable condition items must include an Owner, closure action, and closure time point; otherwise they are escalated to fail
- Observation items record the Owner and target closure time point (pointing to Phase 5-7), but do not affect the Gate determination
Aggregate to obtain the Gate conclusion (observation items are not counted in the warn statistics):
- Ready: No fail, no closable warn items
- Conditional Ready: No fail, there are closable warn items and each has an Owner/action/time point
- Not Ready: There are fail，orthere are closable warn items but they lack an Owner/action/time point
Write two artifacts at the same time:
- tmp/decision_gate_{feature_id}_{timestamp}.json(machine-readable)
- tmp/decision_gate_{feature_id}_{timestamp}.md(human-readable summary)
Return to the main session: path + conclusion + failure/condition item counts.Do not repeat the contents of 01-04.

⭐ Thinking principles

Before executing the Gate check, ask yourself the following questions:

Before evaluating each check item, ask yourself: am I reading the actual § content from 04-feature.md, or inferring from the section title?
Before upgrading a warn to fail, ask yourself: does the warn item genuinely lack Owner/close_action/close_at, or did I fail to extract them?
Before returning Not Ready, ask yourself: have I checked the degradation rules for missing 02/03, or am I blanket-failing all structural checks?

Output contract

JSON Schema (machine-readable)

{
  "feature_id": "<FEAT-YYYYMMDD-NNN>",
  "checks": [ /* 12 项检查结果，含 8 固定 + 3 结构一致性 + 1 遗留问题闭环 */ ],
  "summary": {"pass": 11, "warn": 0, "fail": 0},
  "gate": "Conditional Ready",
  "block_reasons": []
}

(for a complete JSON Schema example, see reference/gate-schema-example.json）

Field semantics

gate: Take only "Ready" | "Conditional Ready" | "Not Ready"
summary.pass / summary.warn / summary.fail: Statistics for the 12 checks
conditions: All closable warn items + closure information (Owner/action/time point); if the Owner/action/time point is missing, this skill automatically escalates it from warn to fail
observations: Phase 0 observation items (metrics such as performance/power consumption/memory that require Phase 5-7 actual measurement), recording the Owner and target closure stage, and not blocking the Gate determination
next_action: Main session routing hint (e.g. "generate IR", "blocked, return to Step 0.4 for completion", "blocked: feature.md does not exist")
block_reasons: Description of the condition item escalated to fail (non-empty only when gate=Not Ready)

Markdown summary (human-readable)

(For the human-readable Markdown summary template see reference/gate-summary-template.md）

Contract with the main Session

When the main session is at Phase 0 Step 0.5:

1. spawn ohos-req-review-gate subagent，task 仅含 docs_dir 绝对路径（不嵌 01-04 全文）
2. 等待 subagent 回传路径
3. 读 tmp/decision_gate_*.json（≤100 行结构化数据，符合 Token 经济性规则）
4. 根据 gate 字段路由：
   - "Ready"           → spawn ohos-req-feature-to-ir
   - "Conditional Ready" → spawn ohos-req-feature-to-ir（task 中追加 conditions 摘要）
   - "Not Ready"       → 阻塞；如 block_reasons 非空，用其内容生成 AskUserQuestion

NEVER

The main session is forbidden from reading 01-04 on its own to infer the Gate: It must be executed by spawning an independent subagent; this skill's JSON output is the sole Gate conclusion (reason: the main session already holds the full context of 01-04, so inferring on its own would produce confirmation bias; the independent subagent's judgment is the only trustworthy conclusion)
Embedding the full text of 01-04 into the task is forbidden: The task contains only the absolute path of docs_dir, and does not embed the full text of 01-04 (reason: embedding the full text would fork the context, causing the subagent's tokens to explode and making isolated judgment impossible)
Repeating the full text of the artifact into the session is forbidden: The formal artifact is written to disk + the path is returned; the full text is not repeated (reason: repeating the full text violates the Token economy rule; the formal artifact only needs to be written to disk + the path returned)
Adding fields outside the schema to the Gate output JSON is forbidden: The fixed fields of schema_version 1.0 cannot be added or removed; the main session only consumes the gate/conditions/block_reasons fields
When 04-feature.md does not exist, attempting to infer the Gate conclusion from 01-03 is forbidden: It must directly judge Not Ready and return an error explanation

Error handling

Scenario	Behavior
04-feature.md does not exist	Return `feature_md_exists: false`、`gate: "Not Ready"`、`block_reasons: ["04-feature.md 不存在，请先执行 ohos-req-feature-baseline"]`
04-feature.md exists but the 8-item table is completely blank	Treat as Not Ready, all 8 items are recorded as fail
02/03 missing but 04 exists	Judge the 8 fixed checks based only on 04; degradation rules for the 3 structural consistency checks: when 02 is missing, module_coverage / term_consistency / condition_propagation are all judged `warn`; when 03 is missing, condition_propagation is judged `warn` + followup_closure is judged `fail`(block_reasons: "03-arch-decision-record.md is missing, legacy issue closure cannot be verified"); when both 02+03 are missing, all 4 items are judged `warn`/`fail`
JSON write failure	Return an error; the main session degrades to a manual Gate

Self-check

The 8 checks are fully aligned with feature.md §1-§5 + technical direction/impact analysis, with no additions and no deletions
The 3 structural consistency checks have been executed (module coverage/term consistency/condition item propagation)
The 1 legacy issue closure check has been executed (03 §6 user input + all three fields present)
Condition items are automatically escalated to fail when Owner/action/timing is missing
Condition items requiring Phase 5-7 actual measurement, such as performance/power consumption/memory, have been classified as "observation items" and do not block the Gate judgment
JSON fields are consistent with schema_version
Number of rows in the Markdown summary table = 12 (8 fixed + 3 structural + 1 legacy)
Do not embed the full text of 01-04 into the task
Return ≤ 15 lines

Output

Path:
- tmp/decision_gate_{feature_id}_{timestamp}.json
- tmp/decision_gate_{feature_id}_{timestamp}.md
Return: JSON path, Gate conclusion, pass/warn/fail counts, number of block_reasons