ohos-req-arch-decision

OHOS Solution Selection Decision Analysis

Announce at start: "I am using the ohos-req-arch-decision skill to generate 03-arch-decision-record.md."

Positioning

03-arch-decision-record.md Record the comparison of candidate solutions and the user's decision conclusion to provide a selection basis for the SIG preliminary review. OHOS SIG adopts a collective review system; the authority for solution selection belongs to the SIG review meeting (composed of SIG Maintainers + domain Owners). AI only provides candidate solution comparisons and recommendation tendency references, and does not exercise decision-making authority on behalf of others — the decision conclusion must be provided by the user (representing the SIG review conclusion).

Core Principles ⭐

The decision conclusion must be provided by the user; AI does not make decisions on the user's behalf.

Two-phase execution:

• Phase A (candidate solution analysis): Generate a candidate solution comparison table and AI recommendation tendency, and output a draft for the user's decision reference.
• Phase B (decision finalization): After the user provides the decision conclusion, fill it into §5-§6 and output the final version.

⚠️ After Phase A is completed, it must pause; the main Session presents the candidate solutions to the user and waits for the user's decision. It is not allowed to skip the user's decision and directly proceed to Phase B or subsequent Steps.

Input

• {docs_dir}/01-requirement.md
• {docs_dir}/02-feasibility.md
• Additional input for Phase B: the user's decision conclusion (selected solution, rationale, decision-maker) + the list of remaining issues identified by the user's review meeting

Mindset Prompts

Before executing key steps, ask yourself the following questions. These questions convey the real constraints of the SIG review meeting to the AI — the authority for solution selection belongs to the review meeting, and AI is only responsible for candidate comparison and recommendation tendency references. Any step that makes a decision on the user's behalf will let an unreviewed solution enter downstream.

• Before writing §1 (Background and Problem), ask yourself: am I reading constraints from 01-requirement.md, or am I inferring hard constraints on my own? Hard constraints should be briefly described in one line, not expanded into a table.
• Before constructing §3 (Candidate Solution Comparison Table), ask yourself: Are the candidate solutions the objective paths given by feasibility, or am I expanding/trimming them on my own? Does each solution have a one-sentence description + effort + advantages + disadvantages + risks + AI recommendation tendency? Is the comparison table presented neutrally, without smuggling in a selection conclusion?
• Before writing §5 (Decision Conclusion), ask yourself: Does this conclusion come from the user (representing the SIG review), or am I making the call on the user's behalf? Is §5 still a placeholder?
• Before writing §6 (Remaining Issues), ask yourself: Was this list provided by the review meeting, or am I automatically deriving it from feasibility condition items/risks? AI derivation will introduce fabricated risk items.
• Before pausing after Phase A, ask yourself: Did I really pause and wait for the user's decision, or did I directly proceed to Phase B? Does status remain PendingDecision？
• Before triggering the single-solution fast path, ask yourself: Does feasibility §6 explicitly mark the other paths as ❌infeasible with supporting evidence? Or is there only one solution marked ✅ while the rest are not ruled out? When the trigger conditions are not met, you must return to the standard two-phase process.
• Before writing the §6 placeholder in Phase B (the user has not provided remaining issues), ask yourself: Did I retain [待用户评审会议后填写] and keep status=PendingDecision, rather than filling in §6 on my own to fake a closed loop?

Phase A: Candidate Solution Analysis (executed by subagent)

1. Read reference/arch-decision-record.md and the input file. The template file does not carry 03- Phase number prefix;03-arch-decision-record.md only as {docs_dir} the output filename under. The template only defines the output structure (6 sections); all process rules (two-phase writing, AI does not make decisions on the user's behalf, etc.) are controlled by this skill and are not presented in the template.
2. Define the decision question and hard constraints → write into §1 Background and Problem (write constraints as a one-line brief, do not expand into a table).
3. Extract options from the feasibility candidate paths, generate a candidate option comparison table (one-sentence description + effort + main advantages + main disadvantages + main risks + AI recommendation tendency) → write into §3 Candidate Option Comparison.
4. §5 Decision Conclusion, §6 Open Issues Leave blank as a placeholder(annotate [待用户评审会议决策后填写]). Note: both §5 and §6 are provided by the user; the AI does not act on the user's behalf. §5 comes from the user's option selection decision, and §6 comes from the list of open issues identified by the user's review meeting. In the template, §5/§6 have no phase hint comments; these process rules are controlled by this skill.
5. Output to {docs_dir}/03-arch-decision-record.md, add to frontmatter status: PendingDecision(the template frontmatter does not contain a status field; it is injected by the skill).

Phase A return

≤15 lines: path + candidate options A/B/C in one sentence each + AI recommendation tendency + key risks + blocking conditions.

Phase B: Decision Finalization (executed by subagent)

Preconditions: The user has explicitly provided the decision conclusion in Step 0.3.2.

1. Read {docs_dir}/03-arch-decision-record.md(Phase A draft).
2. Read the user's decision conclusion (injected into the task description by the main Session):
   • Selected option: Option A / B / C (or custom)
   • Decision rationale: the rationale given by the user for the choice
   • Decision maker: name/role of the person who made the final call
3. Write the user's conclusion into §5 Decision Conclusion (selected option + rationale + decision maker).
4. Read the list of open issues identified by the user's review meeting (injected into the task description by the main Session), and write it into §6 Open Issues After Decision. Table column structure:| 遗留项 | 描述 | 负责人 | 解决动作 | 计划关闭时间 | 状态 |(consistent with §6 of the template arch-decision-record.md). Each open item must include: description, owner, resolution action, planned closure time.
   • ⚠️ §6 open issues must be provided by the user; the AI does not generate them on the user's behalf. The AI must not automatically derive open issues from feasibility condition items or risks. If the user has not provided a list of open issues, §6 retains the placeholder annotation [待用户评审会议后填写], and status remains PendingDecision, and it is not allowed to proceed to subsequent Steps.
5. Update frontmatter status: Accepted(injected by the skill; the template does not contain a status field).
6. Output to {docs_dir}/03-arch-decision-record.md。

Phase B return

≤15 lines: path + selected option + decision rationale in one sentence + number of open issues + status (Accepted).

Phase determination rules

Phase	Trigger condition	status value	Output
A	Step 0.3.1 (requirement + feasibility ready)	PendingDecision	§1-§3 filled, §5-§6 placeholders
B	Step 0.3.3 (user provides decision conclusion + open issues list)	Accepted	§5 filled (user decision), §6 filled (user open issues), full text finalized

It is not allowed to directly output in Phase A status: Accepted or fill in §5 decision conclusion yourself. It is not allowed to output when the user has not provided a list of open issues in Phase B status: Accepted or fill in §6 yourself.

Mandatory rules

• Open issues closure gate: each open item in §6 must have an owner, a resolution action, and a planned closure time. If any open item lacks these three fields → block the Phase 0→1-9 handoff.
• AI recommendation tendency is for reference only: the "AI recommendation tendency" column in the §3 candidate solution comparison table is for the user's decision reference only and is not the final conclusion.

Single-solution exception

When there is only one objectively feasible solution, it is permitted not to construct false alternatives, but the evidence that other paths are infeasible must be stated.

Single-solution fast path (simplify two phases into one phase)：

When the feasibility phase has clearly ruled out other solutions (objectively there is only one feasible path), the candidate solution comparison table may be skipped and a simplified process used:

1. Phase A simplification: directly present the only solution analysis (solution description + effort + advantages + infeasibility evidence),do not generate a candidate solution comparison table(mark §3 as "single-solution scenario, no feasible alternatives")
2. Single confirmation: present the only solution + evidence that other paths are infeasible to the user all at once; the user only needs to confirm adoption once,no two-phase pause required
3. After the user confirms adoption, directly finalize §5 (selected solution + reason: "only feasible solution, no alternatives" + decision-maker), and set status directly to Accepted

Trigger conditions: in the feasibility.md §6 conclusion, only one solution is marked as ✅feasible or ⚠️conditionally feasible, all other solutions are marked as ❌infeasible, and the infeasibility is supported by evidence.

When trigger conditions are not met(≥2 feasible solutions), still execute the standard two-phase process.

Responsibility boundary

This skill only produces solution selection decisions and does not produce the Feature review baseline (goals/non-goals/AC/delivery impact); these are the responsibility of the ohos-req-feature-baseline skill.

NEVER

• AI is prohibited from making decisions on behalf of the user: the selected solution, decision rationale, and decision-maker in §5 are provided by the user; AI does not act on their behalf (reason: the authority for solution selection belongs to the SIG review meeting; AI recommendation tendency is for reference only)
• AI is prohibited from generating open issues: the open issues in §6 are input from the user review meeting and must not be automatically inferred from feasibility conditions or risks (reason: open issues reflect open risks identified by the user; AI inference would introduce fabricated risk items)
• Phase A direct finalization is prohibited: it is not allowed to output in Phase A status: Accepted or fill in §5 yourself (reason: skipping user decision-making would allow unreviewed solutions to enter downstream)
• Filling in §6 when the user has not provided open issues is prohibited: in Phase B, if the user has not provided them, §6 retains placeholders and status remains PendingDecision(reason: open issues not recognized by the review meeting do not constitute closure)

Self-check

• the status field is injected by the skill (PendingDecision→Accepted), not filled in by the template
• the §5 solution comparison comes from the user, not AI inference
• the §6 open issues come from the review meeting, not AI inference
• after Phase A is completed, it has paused and is waiting for the user's decision
• the single-solution exception still executed the two-phase process
• Each legacy issue includes owner/resolution action/planned closure time

Error handling

Scenario	Behavior
01-02 Not ready	Prompt the user to first complete upstream Step 0.1-0.2, and list the missing documents
User did not provide candidate options	Ask the user: "Please provide at least 2 candidate options for comparison"
User has not made a decision (after Phase A)	Keep status: PendingDecision, and ask: "Please provide the review meeting decision conclusion"
Legacy issue not provided	§6 Keep the placeholder [to be filled in after the user's review meeting], do not fill it in yourself

Output

• Path:{docs_dir}/03-arch-decision-record.md
• Phase A return: path, candidate options summary, AI recommendation preference, key risks, blocking conditions
• Phase B return: path, selected option, decision rationale, number of legacy issues, status