| name | ripple |
| description | Enforces structured pre-change impact analysis. Use before modifying code to evaluate dependency risk, blast radius, and consistency issues. Does not write code. |
Overview
This skill ensures every change is evaluated before implementation to avoid unintended side effects, breaking changes, and inconsistent patterns.
It prioritizes risk awareness, dependency understanding, and controlled changes over speed.
1. Define Scope First
Before analyzing impact:
- Clearly describe the change (what, where, why)
- Identify affected entry points (files, modules, APIs)
- Classify the change type:
- Refactor
- Rename
- API change
- Behavior change
- Deletion
If scope is unclear:
- Ask for missing details
- Do not proceed with assumptions
Rule: No impact analysis without a clearly defined scope.
2. Trace Dependencies (Vertical Impact)
Map how the change propagates:
- L0 → File being changed
- L1 → Direct dependents
- L2 → Transitive dependents
- L3 → System-wide or shared module impact
Identify:
- Who calls this?
- What depends on it?
- What breaks if it changes?
Classify breaking changes:
- CRITICAL → API removal, schema change
- HIGH → Function signature change
- MEDIUM → Behavior change
- LOW → Internal-only change
Rule: Always trace at least to L2 (L3 if shared/core module).
3. Check Consistency (Horizontal Impact)
Ensure the change aligns with existing patterns:
- Naming conventions
- File structure
- API design
- Type usage
Flag deviations:
- HIGH → Breaks established conventions
- MEDIUM → Inconsistent with similar modules
- LOW → Minor differences
Do not normalize patterns silently — only report inconsistencies.
4. Evaluate Blast Radius
Estimate how large the impact is:
- Number of affected files
- Modules or services touched
- Cross-boundary effects (frontend/backend, services)
Key signals:
- ≥ 10 files → Medium risk
- ≥ 15 files → High risk (recommend PR split)
- Shared/core module → Amplified impact
- Multiple services → Cascade risk
Ask:
- "How far does this ripple go?"
- "What else breaks indirectly?"
5. Detect Cascading Effects
Look beyond direct dependencies:
- Sequential failures across modules
- Feedback loops between components
- Shared resource contention (DB, queues, cache)
- Timing/order issues (async flows)
Trigger when:
- Change touches multiple modules/services
- Dependencies are bidirectional
- Risk appears non-local
Goal: Identify second-order effects, not just direct ones.
6. Risk Scoring
Assign a risk score (1–10) based on:
- Scope (30%)
- Breaking potential (25%)
- Pattern deviation (20%)
- Test coverage (15%)
- Reversibility (10%)
Interpretation:
- 1–3 → LOW (safe)
- 4–6 → MEDIUM (watch)
- 7–8 → HIGH (needs mitigation)
- 9–10 → CRITICAL (block or redesign)
Always justify the score.
7. Recommendation (Go / No-Go)
Based on analysis:
- GO → Safe to proceed
- CONDITIONAL GO → Requires mitigations
- NO-GO → Too risky without redesign
Include:
- Required safeguards
- Testing needs
- Rollback considerations
Expected Behavior
This skill is working correctly if:
- Risks are identified before coding starts
- Dependency chains are explicitly mapped
- Changes are scoped realistically
- Hidden impacts are surfaced early
- Large or risky changes are challenged
Example Usage
User request: "Rename a shared API method"
With this skill:
- Identify all consumers (L1, L2)
- Detect breaking change (HIGH)
- Evaluate affected files (e.g., 12 files)
- Flag risk (HIGH)
- Recommend:
- Add backward compatibility layer
- Update consumers incrementally
- Add regression tests
