SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsohos-req-feature-baseline

ohos-req-feature-baseline

Coding & development

View repository

Updated 10-16 03:11

About this skill

OHOS Feature Review Baseline

Announce at start: "I am using the ohos-req-feature-baseline skill to generate 04-feature.md."

Positioning

04-feature.md is the common input for OHOS SIG review meetings and IR generation. The workload grading constraint (PIR #152 P1) is derived from the end-to-end total person-months: three levels—simple (≤5)/standard (≤8)/complex (≤15); complex features must have an independent acceptance boundary. The module coverage completeness check references the code repository analysis table in 02-feasibility.md §2.1; missing modules must have rows added or an exclusion rationale stated. The closed-loop check for remaining issues in 03-arch-decision-record.md §6 blocks the Not Ready Gate.

⭐ Thinking Guidelines

Before giving a splitting suggestion, ask yourself: am I evaluating item by item in the order R1→R2→R3→R4? Do I stop at the first trigger, or have I skipped some checks?

  • Before checking module coverage, ask yourself: am I cross-checking 02 §2.1 against 04 §4 line-by-line, or eyeballing from memory?
  • Before detecting terminology drift, ask yourself: am I comparing every 影响类型 label between 02 and 04, or skipping reusable ones?

Input

  • {docs_dir}/01-requirement.md
  • {docs_dir}/02-feasibility.md
  • {docs_dir}/03-arch-decision-record.md

Process

Template and Artifact Naming

  • Template path:reference/feature.md(template files do not carry the 04- phase number prefix)
  • Artifact path:{docs_dir}/04-feature.md
  1. Read reference/feature.md and all inputs.
  2. From 01-requirement.md frontmatter inherit rr_id into the 04-feature.md frontmatter, and fill in the RR ticket number table row after §1 Overview and Value.
  3. Converge the one-sentence feature, value, goals/non-goals, priority scope, and AC.
  4. The summary records the selected option, the reasons for unselected options, and the Phase 2 verification items.
  5. Specify repositories, modules, Owner/SIG, deliverables, milestones, dependencies, and open items.
  6. Add a "Requirement Change Impact Analysis" section (a supplementary section outside the template, not corresponding to a template §-number): analyze the impact type item by item for the following five parties (positive optimization/no impact/needs adaptation):
    • Northbound application developers: focus on API changes, behavior changes, compatibility
    • Southbound developers: focus on underlying interface changes, new capabilities
    • Distributed devices: focus on cross-device scenario impact
    • System developers (cross-subsystem): focus on inter-subsystem interface/dependency changes
    • Device users: focus on user-perceivable function/experience changes
  7. Module coverage completeness check: extract all repositories/modules from the "Key Code Repository Analysis" table in 02-feasibility.md §2.1, and compare them with the §4 "Affected Modules" table. Repositories/modules that appear in 02 but are missing in 04 must have rows added or an exclusion rationale stated. Write into §4 module coverage check conclusion: pass (complete) or warn (has exclusion rationale), for ohos-req-review-gate to read.
    • Downgrade rule: if 02-feasibility.md does not contain the §2.1 Key Code Repository Analysis table, skip the module coverage check and annotate warn("Module coverage check not executed: 02-feasibility.md is missing §2.1"), do not fail。
  8. Impact type terminology check: compare the impact type labels of the same module in 02-feasibility.md §2.1 and §4. Drift (e.g., "reusable"→"needs extension") must be supplemented in §4 with a change rationale note, and write into §4 terminology consistency check conclusion: pass (no drift) or warn (drift present with justification added), for ohos-req-review-gate to read.
  9. Determine whether to split the proposal, and define each proposal's independent value, boundaries, AC,effort estimateand dependencies. The split table must include the estimated effort (person-months) for each proposal.Calculate the total end-to-end effort(= the sum of each proposal's effort), derive complexity from the total person-months (<5 simple / 5-10 standard / >10 complex), and fill in the §5 "Total End-to-End Effort" and "Complexity" fields—this complexity is the basis for determining the R3 split upper limit (simple ≤5 / standard ≤8 / complex ≤15 person-months).
  10. ⭐ Split Result Confirmation Gate: Present the split plan to the user (each proposal's boundaries, effort, Owner, dependencies), and only allow entry into Step 0.5 after the user confirms or adjusts it. The AI must not finalize the split plan on its own.
  11. Save to {docs_dir}/04-feature.md。
  12. Execute the Review Ready Gate (read the just-saved 04-feature.md to ensure the Gate determination is based on the final version confirmed by the user).

Responsibility Boundaries

Solution selection decisions (ADR) are the responsibility of the ohos-req-arch-decision skill; this skill only converges the Feature review baseline.

Open Issue Closure Verification

Before generating 04-feature.md, the closure status of open issues in 03-arch-decision-record.md §6 must be verified:

  1. Read all open items in 03-arch-decision-record.md §6.
  2. For each open item, check whether the three fields—owner, resolution action, planned closure time—are complete.
  3. If any open item lacks the three fields → the Gate is downgraded to Not Ready, and block_reasons records the missing items.
  4. If §6 is a placeholder ([待用户评审会议后填写]) and there are no actual open items → the Gate is downgraded to Not Ready, and block_reasons records "03-arch-decision-record.md §6 open issues were not input by the user review meeting".
  5. If §6 has no open items (the user review meeting determined no open items are needed) → it is considered passed, with no need to block.

Review Ready Gate

  • Ready: All check items pass; the IR can be generated and formal review can begin.
  • Conditional Ready: No failed items; all conditional items have an Owner, closure action, and time point; a conditional IR can be generated.
  • Not Ready: There are failed items or blocking items without a requirements import plan; generating the IR, proposal, or formal requirements PPT is prohibited.

AC Consistency Verification

After the Gate, the main Session generates an FR→AC traceability table and checks numbering consistency: each FR must map to at least one AC, and AC numbers must be unique and complete within 04-feature.md.

Error Handling

Scenario Recovery Guidance
Not Ready (04-feature.md content incomplete) Inform the user of the specific missing sections and guide them back to the corresponding substep of Step 0.4 to complete them
Not Ready (01-03 incomplete) Inform the user that upstream Steps 0.1-0.3 must be completed first, and list the missing documents
Conditional Ready List the conditional items and guide the user to confirm whether to accept conditional release or return for modification
Split not confirmed (Step 10 gate) Prompt the user to confirm the split plan; do not finalize it on your own

Split Rules

For split rules, see reference/split-rules.md. Core: R1 repository isolation → R2 subsystem isolation → R3 effort constraint → R4 do not split by default. Effort levels: simple ≤5 / standard ≤8 / complex ≤15 person-months.

Self-check

  • Content can be traced back to 01-03
  • RR number has been inherited from 01-requirement.md (frontmatter rr_id + §1 table)
  • Goals, non-goals, AC, and scope are reviewable
  • Impact scope has Owner/SIG and deliverables
  • Conditional items have Owner and closure time point
  • Split conclusion includes factual basis
  • Each proposal in the split table has an estimated workload (person-months, not exceeding the complexity upper limit)
  • §5 end-to-end total workload field is filled in (= sum of workloads of all proposals), and complexity matches the total workload
  • Split result has been confirmed by the user (not finalized by AI on its own)
  • 03-arch-decision-record.md §6 open issues are input from the user review meeting (not AI-generated)
  • In 03-arch-decision-record.md §6, each open item has a complete owner/resolution action/planned closure time

NEVER

  • AI is prohibited from finalizing the split plan on its own: the split result must be confirmed by the user before it is allowed to enter Step 0.5 (reason: splitting involves resource allocation and delivery priority, which are human decisions)
  • AI is prohibited from generating §6 open issues on behalf of the user: open issues must be input from the user review meeting, and must not be automatically derived from feasibility conditional items or risks (reason: AI derivation would introduce fabricated risk items)
  • Generating IR/proposal/PPT when Not Ready is prohibited: when there are failed items, generating IR, proposal, or formal requirements PPT is prohibited (reason: requirements that have not passed the gate entering downstream will cause rework and review blockage)
  • Copying the detailed argumentation of 01-03 is prohibited: 04-feature.md only converges conclusions and does not copy detailed argumentation (reason: to avoid document redundancy and information inconsistency)

Output

  • Path:{docs_dir}/04-feature.md
  • Solution summary section: change to a one-sentence reference to the selected solution in 03-arch-decision-record.md, in the format "Selected solution: PATH-XX (see 03-arch-decision-record.md)", without repeating decision details
  • Return: path, RR number, Gate conclusion, review recommendations, split conclusion, impact analysis conclusion, and blocking items