Change risk review

Change Risk Review

Use this skill before making a change when the main question is not only "can we do it?" but also "how risky is it, and what could break?"

Goal

Reduce avoidable incidents by reviewing change risk before execution.

Focus on:

1. blast radius
2. sensitive paths and dependencies
3. reversibility
4. validation needs
5. likely failure modes
6. go-slower signals before change starts

Core Rules

1. Define the change unit clearly

Before reviewing risk, restate exactly what is changing:

• code path
• config value
• dependency version
• build/deploy step
• startup behavior
• feature flag or routing behavior
• data handling path

If the change unit is vague, risk review will also be vague.

2. Identify what the change can touch indirectly

Do not stop at the file being edited.

Ask what else may be affected through:

• shared modules
• common utilities
• config inheritance
• startup/runtime assumptions
• browser-visible behavior
• deployment or packaging steps
• data contracts and integrations

3. Estimate blast radius before making the change

Assess whether impact would likely be:

• narrow and local
• moderate and cross-module
• broad and cross-workflow
• high-risk because it affects shared paths, release flow, or recovery options

4. Separate reversible from hard-to-reverse changes

A safe-looking change may still be hard to undo.

Check whether the change affects:

• code only
• config only
• assets/build output
• migrations or generated data
• user-visible behavior already relied upon
• one-way side effects or downstream consumers

5. Identify validation requirements before coding

Do not wait until after implementation to ask how the change should be validated.

Decide early whether the change needs:

• targeted tests
• browser verification
• performance checks
• deployment verification
• release readiness review
• rollback planning

6. Prefer smaller changes when risk is unclear

If the blast radius or reversibility is still uncertain, prefer:

• smaller scope
• phased rollout
• feature flag or guarded path
• extra validation before merge/release
• a separate worktree or isolated branch

Minis-Specific Workflow

Shell-first review

Use shell commands to:

• inspect touched files and nearby modules
• search for shared usage of the path being changed
• review current repo structure
• inspect config or startup scripts
• identify related tests or build steps

Browser-aware risk review

For web/UI changes, review whether the change may affect:

• shared components
• route behavior
• state transitions
• asset loading
• base-path or deployment behavior

Worktree-aware planning

If the change looks medium+ risk, consider isolating it in a dedicated worktree before implementation.

Risk Review Sequence

Use this order:

1. Restate the change unit.
2. Identify directly touched files/paths.
3. Identify indirect dependencies and shared usage.
4. Estimate blast radius.
5. Classify reversibility.
6. List likely failure modes.
7. Decide required validation and safety controls.
8. Summarize whether to proceed normally, proceed cautiously, or split/narrow the change first.

Common Risk Signals

Watch for:

• shared utility or common config changes
• auth/session/input-validation paths
• startup or environment behavior changes
• path/base-url/asset handling changes
• dependency upgrades with broad usage
• hidden coupling across modules
• changes that are easy to apply but hard to reverse
• changes that need multiple skills to validate safely

Integration with Other Skills

• Use software-architecture if the risk review shows structural ambiguity before coding.
• Use using-git-worktrees if the change should be isolated from other in-flight work.
• Use test-driven-development when behavior needs tight validation.
• Use webapp-testing for browser-visible risk.
• Use deployment-verification if environment-sensitive behavior is part of the risk.
• Use release-readiness if the change is close to shipping.
• Use rollback-planning if the change would be painful to reverse.

Completion Checklist

Before calling the risk review done, check:

• Is the change unit clearly defined?
• Is the likely blast radius described?
• Are shared dependencies or sensitive paths identified?
• Is reversibility understood?
• Are likely failure modes listed?
• Are validation needs and safety controls explicit?
• Is there a clear recommendation on how cautiously to proceed?

Response Template

• Change unit:
• Directly touched paths:
• Shared dependencies / sensitive paths:
• Blast radius:
• Reversibility:
• Likely failure modes:
• Required validation:
• Recommendation:

Example Triggers

• "Before I make this change, review the risk."
• "How risky is this refactor or config edit?"
• "What could this change break outside the obvious file?"
• "Estimate the blast radius before implementation."
• "Tell me whether this should be split into a smaller change first."