change-impact-analysis

Change Impact Analysis (Chinese Version)

When to Use

When you need to identify affected capabilities, regression scope, and release risks from code, configuration, data, and dependency changes.
When you need to conduct a risk review of existing plans, results, or evidence and form actionable improvement items.
When 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, enum values, and required items.

First read and follow the input, execution rules, minimum coverage checklist, and output order of prompts/change-impact-analysis.md .
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 issues 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 constrained initial version, and explain which conclusions cannot currently hold.

When calibrating domain results, correct comparisons, or evidence gaps, read the desensitized input, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Each execution must read prompts/change-impact-analysis.md; it is the complete execution specification of this Skill.
When this Skill needs to be evaluated or regressed, 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 change version and scope, and output a typed evidence graph of changed files/symbols/configurations→dependent→business obligations→test ID; record the source, version, and confirmed/candidate/unknown for each edge.
Traverse direct and transitive consumers, deduplicating cycles; stop only when contracts are isolated or it is proven that there are no consumer edges, record the basis for stopping, and do not truncate based on directory boundaries.
Keep dynamic registration, runtime configuration, or untracked dependencies as unknown; add consumer contract/integration verification candidates according to risk, and do not treat the absence of mapping as no impact.
Output inclusion/exclusion reasons, minimum verification, residual risks, and additional scope triggers; this Skill can analyze changes to code, data, configuration, etc., while PR-specific work separately retains base/head and diff identity.

Distinguish proven impact from speculative impact
Do not select tests only by changed files
Dependencies that cannot be traced must be explicitly marked as risks
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 state the basis in business impact, likelihood of occurrence, or detectability.

Covered: direct impact, transitive impact, data compatibility, interface contracts, permissions, runtime dependencies, rollback, observability.
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 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.
Directly refusing when the 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 reproduction conditions.
Make the output directly executable and reviewable by another engineer.