quality-risk-analysis

Quality Risk Analysis (Chinese Version)

When to Use

You need to identify quality risks of a product or change and prioritize them by probability, impact, detectability, and evidence.
You need to conduct a risk review of existing plans, results, or evidence and produce actionable improvement items.
The input is incomplete, but a usable initial version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required fields.

First read and follow the input, execution rules, minimum coverage checklist, and output order of prompts/quality-risk-analysis.md .
Supplement the scope, environment, version, constraints, evidence, and success criteria that genuinely affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and open questions.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a constrained initial version and state which conclusions cannot yet hold.

When calibrating domain results, correct comparisons, or evidence gaps, read the desensitized inputs, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Each execution must read prompts/quality-risk-analysis.md; it is the complete execution specification of this Skill.
When evaluating or regressing this Skill, read evals/eval.yaml and the matching evals/cases/ test cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Build a register from risk events, affected assets/populations, triggers, and current controls; give each of impact, likelihood, and detectability an observable evidence anchor and source, and do not assign scores based on impressions.
When the project does not specify quantitative rules, use justified qualitative ranking; list major irreversible impacts, authorization boundaries, and known control gaps separately, and do not automatically downgrade low frequency to low risk.
Propagate evidence uncertainty separately into probability/impact/control confidence, give conditional conclusions and minimum discriminating verification, and do not multiply UNKNOWN into 0 or an exact risk score.
For each item, associate controls/tests, residual risk, owner, and acceptance authorization; risk ranking is a decision aid and does not represent vulnerabilities, failure root causes, or actual acceptance.

Scores must be accompanied by evidence and assumptions
Do not let numbers create false precision
Risks that testing cannot eliminate must be explicitly accepted or mitigated
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide verification methods.
Priority must state the basis in business impact, likelihood of occurrence, or detectability.

Covered: business criticality, failure modes, probability, impact, detectability, exposure window, existing controls, residual risk.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priorities, evidence, owners, or next steps.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without specifying input conditions, expected results, or evidence.
Marking everything as high priority, which loses the value of prioritization.
Replacing domain judgment with tool names or general theories.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start with the paths most likely to cause business loss, security issues, or release blockers.
Reduce uncertainty with the smallest verifiable experiment, and record the conditions for reproduction.
Make the output directly executable and reviewable by another engineer.