quality-metrics-design

Quality Metric Design (Chinese Version)

When to Use

When evidence-based analysis, design, or verification preparation is needed around the definition of quality metrics, calculation criteria, data sources, timeliness, and anti-manipulation boundaries.
When existing plans, results, or metrics need 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.

Default output is Markdown, organized by domain risk, evidence status, priority, and boundaries.
When the user requests 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-metrics-design.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, focusing on checking metric definitions, numerator and denominator, data sources, refresh timeliness, and interpretation limits.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Convert 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, item-by-item expectations, and recalculation basis.
Each execution must read prompts/quality-metrics-design.md; it is the complete execution specification of this Skill.
When evaluation is needed, read evals/eval.yaml and the matching cases under 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.

Establish a metric dictionary: decision purpose, statistical unit, numerator/denominator, time window/time zone, filtering/deduplication, missing handling, version, source, and lineage; the denominator of a rate must not change implicitly.
Distinguish defect entities from status events, first execution from reruns, and closure from reopening; aggregate by project unique key and event time, avoiding counting duplicate IDs/reopens as new defects or retries inflating the pass rate.
Recalculate samples and verify denominator coverage, latency, and exclusion reasons; keep missing records as unknown, and do not fill in 0. For data anomalies, first mark them as measurement issues, and do not attribute them to product quality without evidence.
Output calculation examples, interpretation limits, monitoring threshold sources, and actions; cross-project comparisons must align definitions and windows, and do not write metric correlation as causation.

Only analyze the definition of quality metrics, calculation criteria, data sources, timeliness, and anti-manipulation boundaries; do not replace the business owner or Human in risk acceptance, exception approval, and release decisions.
Do not fabricate system behavior, fields, metrics, thresholds, data, root causes, execution records, or pass 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 provide the minimum verification method.
When production, privacy, or security is involved, use least privilege, masked data, mocks, dry-runs, or isolated environments.

Metric definitions, numerators and denominators, data sources, refresh timeliness, and interpretation limits are covered, and sources, evidence status, and verification methods 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 a complete judgment of quality metrics.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when 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.