Change Impact Analysis

Use this skill when the key uncertainty is breadth of impact rather than how to write the code.

Trigger Conditions

Use this skill when:

• a change may affect multiple modules, consumers, or environments
• the team needs to know what else must be updated before implementation
• API, schema, config, docs, tests, or rollout surfaces may be touched indirectly
• the user asks what could break if a change goes in
• release risk depends on understanding downstream effects first

Do not use this skill for root-cause debugging or for deciding the internal structure of a refactor.

Workflow

1. Identify the proposed or in-progress change.
2. Map directly touched files, modules, contracts, configs, and consumers.
3. Identify likely indirect effects and regression zones.
4. Separate must-check surfaces from lower-risk surfaces.
5. Recommend verification focus and rollout cautions.
6. Hand off to the next workflow step.

Output

For non-trivial work, provide:

• impacted surfaces
• direct vs indirect consequences
• likely regression zones
• verification focus areas
• rollout or migration cautions
• recommended next action

Coordination

After impact analysis:

• use planning if scope needs to be re-sliced
• move into the active implementation workflow for execution
• use ship-readiness or release-rollout-strategy when impact affects release shape

Invocation Examples

• "Use change-impact-analysis to show what else this schema change could affect."
• "Use change-impact-analysis before implementation so we know which tests, docs, and clients are in scope."
• "Use change-impact-analysis to identify the likely regression zones for this config change."