quality-dashboard-design

Quality Dashboard Design (Chinese Version)

When to Use

When evidence-based analysis, design, or validation preparation is needed around the quality dashboard's audience, decision questions, panels, drill-downs, refresh, and alerting boundaries.
When an existing plan, result, or metric needs review, and actionable improvement items need to be formed.
When inputs are incomplete, but a constrained first 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-dashboard-design.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with a focus on audience, decision questions, panels, drill-down paths, refresh, and alerting.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then rank by risk and evidence strength.
Convert high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and validation methods.
When information is insufficient, deliver a constrained first 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 the desensitized inputs, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Every execution must read prompts/quality-dashboard-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 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 the panel mapping of question→metric→definition/time window→data source/version→actionable action→owner based on audience decisions; do not work backward from easily obtainable data to decisions.
Display the numerator and denominator of values, the last refresh time, and source status; present 0, null, NOT_RUN, BLOCKED, and stale values separately; do not fill missing values with 0 or carry over a stale green light.
Aggregation must retain P0/blocking items, minority high-risk groups, and unknown evidence; the overall pass rate cannot override individual release blockers, and status aggregation comes from project rules.
Provide each panel with a path to drill down to run/obligation/defect evidence, a refresh contract, and action triggers; when there is no data or threshold, deliver the design and gaps, and do not declare the current quality as passed.

Only analyze the quality dashboard's audience, decision questions, panels, drill-downs, refresh, and alerting boundaries; do not replace the business owner's or Human's 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 validation method.
When production, privacy, or security is involved, use least privilege, masked data, mocks, dry-runs, or isolated environments.

The audience, decision questions, panels, drill-down paths, refresh, and alerts 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 kept separate.
High-risk items have P0/P1/P2/P3 or an equivalent priority, an accountable role, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passed, or release approval.
Residual risks, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without explaining trigger conditions, expected focus points, accountable roles, closure conditions, and evidence.
Treating metrics or tool names from adjacent domains as the complete judgment of a quality dashboard.
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.