quality-debt-analysis

Quality Debt Analysis (Chinese Version)

When to Use

When you need evidence-based analysis, design, or verification preparation around quality-debt items, origins, impact, age, priority, ownership, and paydown tradeoffs.
When you need to review an existing plan, result, or metric and form actionable improvement items.
When inputs are incomplete but a bounded first draft with assumptions, information gaps, and human decision boundaries is still required.

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-debt-analysis.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, focusing on debt items, originating sources, business impact, age, and paydown tradeoffs.
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 verification methods.
When information is insufficient, deliver a bounded first draft, make clear which conclusions cannot hold, and do not present 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 recomputation basis.
Every execution must read prompts/quality-debt-analysis.md; it is the complete execution specification for this Skill.
When evaluation is needed, read evals/eval.yaml and the matching cases under 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.

List existing product defects, testing/architecture debt, temporary exceptions, and data gaps separately; for each, record its source, current impact, cause of formation, age, and existing controls, and do not call every unfinished item debt.
When estimating risk interest, explain the change path: observable evidence such as subsequent modification cost, failure exposure, detection delay, etc.; without rates/frequencies, give only qualitative or conditional ranges, and do not invent amounts.
Rank by business impact, exposure, detectability, dependencies, and paydown cost/benefit; age is only one signal; a new major risk may take priority over an old minor item.
Paydown completion requires the asset to be fixed, independent behavioral checks, disappearance of the old debt's effects, and acceptance evidence from the responsible person; completing a ticket or document alone cannot close debt, and risk acceptance has a time limit/authorization.

Analyze only quality-debt items, origins, impact, age, priority, ownership, and paydown tradeoffs; 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 passing conclusions.
Static design, plans, file existence, or dry-run can only retain the original evidence status and cannot be upgraded to proof of actual execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and provide a minimal verification method.
When production, privacy, or security is involved, use least privilege, desensitized data, mocks, dry-run, or an isolated environment.

Debt items, their sources, business impact, age, and repayment trade-offs have been covered, and the source, evidence status, and verification method have been recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions have been separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, responsible roles, and closure conditions.
Plans, static checks, or dry-run have not been written as test execution, all passed, or release approval.
Residual risks, stop/escalation conditions, and next steps have been explained.

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 debt.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending that 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.