quality-gate-design

Quality Gate Design (Chinese Version)

When to Use

When evidence-based analysis, design, or verification preparation is needed around the admission conditions, evidence requirements, responsible parties, and exception paths of a release or delivery entry point.
When an existing plan, result, or metric needs to be reviewed and actionable improvement items formed.
When inputs are incomplete, but a constrained initial version with assumptions, information gaps, and human decision boundaries still needs to be delivered.

By default, output Markdown, organized by domain risk, evidence status, priority, and boundaries.
When the user requests a table, CSV, JSON, or ticket format, retain the same finding fields, evidence, and decision boundaries.
Before output enters an automated process, first confirm the schema, enum values, required fields, and evidence sources.

First read and follow prompts/quality-gate-design.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, focusing on gate objectives, admission conditions, evidence sources, responsible roles, exceptions, and rollback.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Turn high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and verification methods.
When information is insufficient, deliver a constrained initial version, clarify which conclusions cannot hold, and do not write static materials as execution results.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized inputs, itemized expectations, and recalculation basis.
Every execution must read prompts/quality-gate-design.md; it is the complete execution specification of this Skill.
When evaluation is needed, read the matching cases under evals/eval.yaml and evals/cases/ .
Only when the directory actually exists and the task requires it, read references/、examples/、scripts/ or output-formats.md, and do not assume assets that do not exist.

For each threshold, record the truth table of obligation, input/version/timeliness, comparison operator, PASS/FAIL, non-executable BLOCKED, missing evidence, or UNKNOWN that cannot be judged; without a record, it must not be regarded as PASS.
Aggregation rules are specified by the project: necessary threshold FAIL takes priority, and if verification is impossible, stop according to fail-closed; UNKNOWN/BLOCKED retain their reason rather than being converted into a failure rate. Only when all necessary thresholds have fresh valid PASS can passing be recommended.
Exceptions separately list obligation scope, authorizer, reason, approval evidence, validity period, compensating controls, and revocation conditions; expired/out-of-bounds/unauthorized exceptions do not take effect and do not rewrite the original FAIL.
Clarify gate triggers, owners, re-verification, and rollback/stop conditions; report design, static evidence determination, and actual pipeline implementation separately, and submit missing rules for Human decision.

Only analyze the admission conditions, evidence requirements, responsible parties, and exception paths of a release or delivery entry point; do not replace the business owner's or Human's risk acceptance, exception approval, and release decision.
Do not fabricate system behavior, fields, metrics, thresholds, data, root causes, execution records, or passing conclusions.
Static design, plans, file existence, or dry-run can only retain the original evidence status and cannot be upgraded to proof of real execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and give the minimum verification method.
When production, privacy, or security is involved, use least privilege, masked data, mocks, dry-run, or an isolated environment.

Gate objectives, admission conditions, evidence sources, responsible roles, exceptions, and rollback are covered, and the source, evidence status, and verification method are recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions are separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, responsible roles, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passing, or release approval.
Residual risks, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without explaining trigger conditions, expected focus points, responsible roles, closure conditions, and evidence.
Treating metrics or tool names from adjacent domains as the complete judgment of a quality gate.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause business loss, quality regression, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record conditions, versions, sources, and evidence.
Enable another engineer to independently install, execute, and review the output of this Skill.