pr-test-impact-analysis

PR Test Impact Analysis (Chinese Version)

When to Use

You need to determine the minimal sufficient test scope from a Pull Request's diff, dependencies, and historical risk.
You need to conduct a risk review of an existing plan, result, or evidence and produce actionable improvement items.
The input is incomplete, but a usable first 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, enum values, and required fields.

First read and follow prompts/pr-test-impact-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 questions to be confirmed.
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 first version and explain which conclusions cannot currently hold.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized input, item-by-item expectations, and recalculation basis.
Each execution must read prompts/pr-test-impact-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.

Fix the repo/base/head SHA and diff scope; list sources for file, symbol, schema/config changes, do not guess impact based on file names or merge test results from different HEADs.
Output a mapping table of changed symbols → direct/transitive consumers → protection obligations → test ID/level/execution version, with edges marked confirmed/candidate/unknown; stop only at isolation boundaries with evidence.
When deleting or weakening tests, verify whether the protected obligations still have independent coverage; do not select only from the current test set in a way that causes disappeared risks to be missed.
When dynamic dependencies are unknown or mappings are missing, conservatively include relevant contract/integration candidates and mark gaps; distinguish candidate scope, executed, and satisfied, and list additional verification/escalation triggers.

Do not infer based only on file names
Test selection must provide an evidence chain
When risk is high and evidence is insufficient, expand the scope
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 in business impact, likelihood of occurrence, or detectability.

Covered: change intent, direct and transitive impact, public interfaces, data changes, configuration, security, rollback, test gaps.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without specifying input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of prioritization.
Replacing domain judgment with tool names or generic theory.
Rejecting outright 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 the conditions for reproduction.
Make the output directly executable and reviewable by another engineer.