regression-scope-analysis

Regression Scope Analysis (Chinese Version)

When to Use

You need to determine the coverage boundary and depth of regression testing based on changes, dependencies, risks, and resources.
You need to conduct a risk review of existing plans, results, or evidence, and form 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, enumeration values, and required items.

First read and follow prompts/regression-scope-analysis.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly 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 limited initial version, and explain which conclusions cannot yet hold.

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/regression-scope-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.

Start from the change and the current baseline, and list a matrix of change → affected obligations → test layer/platform/data state → inclusion/exclusion and evidence; regression protects existing behavior, and does not conflate full testing of new features with regression.
Check direct, transitive, and dynamic dependencies, historical escapes, and non-functional impacts; list unknown dependencies separately, do not treat no mapping as no impact, and exclusion requires contract/evidence proof.
When the budget is insufficient, retain the minimum critical obligations and risk margin, provide non-coverable items, minimum alternative evidence, owners, and conditions for authorized acceptance/escalation; do not silently cut high-risk items.
Output candidate scope, order, resources, and signals that trigger scope expansion; record selected tests, executed tests, and satisfied tests separately, and do not use planned counts as passing evidence.

Scope reduction must explain the risk
Do not treat full regression as the default answer
Clearly define stop conditions and scope expansion triggers
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 explain the basis of business impact, likelihood of occurrence, or detectability.

Covered: core journey, direct impact, downstream impact, platforms and roles, data migration, integrations, non-functional, uncovered risks.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, owner, or next steps.
The output includes verifiable judgment criteria rather than vague statements.
No unauthorized production writes or destructive actions were performed.

Only listing checkpoints without stating input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of trade-offs.
Replacing domain judgment with tool names or generic theory.
Outright refusing when 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.
Use the smallest verifiable experiment to reduce uncertainty, and record reproduction conditions.
Make the output something another engineer can directly execute and review.