Claude-skill-registry 30-analyze-impact-150

[30] ANALYZE. Understand how changes impact the system — what's the core, what's affected, what depends on what. Use when planning changes, analyzing systems, debugging issues, or anytime you need to see the full picture of cause and effect. Triggers on \"what's affected\", \"impact analysis\", \"dependencies\", \"scope mapping\", or when you need to understand ripple effects.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/30-analyze-impact-150" ~/.claude/skills/majiayu000-claude-skill-registry-30-analyze-impact-150 && rm -rf "$T"
manifest: skills/data/30-analyze-impact-150/SKILL.md
source content

Analyze-Impact 150 Protocol

Core Principle: Understand the ripple effects. See how changes in one part affect the whole system.

What This Skill Does

When you invoke this skill, you're mapping:

  • Core — What exactly is being changed
  • Impact — What will be affected by the change
  • Dependencies — What the core depends on and what depends on it
  • Boundaries — Where the effects stop

The Impact Model

         [UPSTREAM]
    What the core depends on
              ↓
         [CORE]  ←── What we're changing
              ↓
        [DOWNSTREAM]
    What depends on the core
              ↓
        [BOUNDARIES]
    Where effects fade out

The 150% Impact Rule

  • 100% Core: Complete understanding of what's being changed
  • 50% Enhancement: Clear view of dependencies and downstream effects

When to Use This Skill

Universal trigger: Anytime you need to understand impact and dependencies.

Specific triggers:

  • Before making changes to code/systems
  • When debugging to understand cause chains
  • Planning features that touch multiple parts
  • Refactoring decisions
  • Risk assessment
  • Understanding legacy systems
  • When you hear "why did changing X break Y?"

Key insight: Impact mapping prevents surprises. Changes don't happen in isolation.

The Impact Layers

LayerDescriptionCoverage
CoreWhat's directly changing100% — must fully understand
ImmediateDirect dependencies and users50% — must assess
ExtendedSecondary effects25% — should consider
SystemFull ecosystem10% — be aware

Execution Protocol

Step 1: DEFINE CORE

Clearly identify what's changing:

  • What exactly is being modified?
  • What files/components/systems?
  • What's the nature of the change?

Step 2: MAP UPSTREAM

Identify dependencies (what the core needs):

  • What does this component use?
  • What must exist for this to work?
  • What configurations/data/services?

Step 3: MAP DOWNSTREAM

Identify dependents (what uses the core):

  • Who/what uses this component?
  • What breaks if this changes?
  • What needs to be updated?

Step 4: TRACE RIPPLES

Follow the effects outward:

  • What do the downstreams depend on?
  • Where do effects stop?
  • What's the blast radius?

Step 5: MARK BOUNDARIES

Define where impact ends:

  • What's definitely NOT affected?
  • Where can we safely stop analyzing?
  • What's the "fence" around the change?

Impact Mapping Questions

About the Core:

  • "What exactly is changing?"
  • "What's the nature of the change?"
  • "Is it additive, modifying, or removing?"

About Upstream (Dependencies):

  • "What does this use/import/call?"
  • "What must exist for this to work?"
  • "What configs/data does it need?"

About Downstream (Dependents):

  • "What uses/imports/calls this?"
  • "What would break if this changes?"
  • "Who relies on this behavior?"

About Boundaries:

  • "Where do the ripples stop?"
  • "What's definitely unaffected?"
  • "What's the maximum blast radius?"

Output Format

When using Impact-Map 150:

🗺️ **Impact-Map 150 Complete**

**Core Change:**
[What exactly is being changed]

**Upstream Dependencies:**
- [What this needs to work]
- [Required services/data/configs]

**Downstream Impact:**
- 🔴 Critical: [What definitely breaks]
- 🟡 Affected: [What needs checking]
- 🟢 Monitor: [What might be touched]

**Boundaries:**
- Impact stops at: [clear boundary]
- Definitely safe: [unaffected areas]

**Blast Radius:** [Small/Medium/Large/System-wide]

**Risks Identified:**
- [What could go wrong]

Ready to proceed with awareness.

Visual Impact Map

Example: Changing User Authentication

            [Config Files]     [Environment Vars]
                   ↓                   ↓
              ┌─────────────────────────────┐
              │    🎯 CORE: Auth Module     │
              └─────────────────────────────┘
                   ↓           ↓           ↓
            [Login API]  [Session Mgmt]  [Token Gen]
                   ↓           ↓           ↓
            ┌──────────────────────────────────┐
            │ 🔴 CRITICAL: All Authenticated   │
            │    Endpoints, User Sessions      │
            └──────────────────────────────────┘
                   ↓           ↓
            ┌──────────────────────────────────┐
            │ 🟡 AFFECTED: Mobile App, Web App │
            │    Admin Panel, API Clients      │
            └──────────────────────────────────┘
                   ↓
            ┌──────────────────────────────────┐
            │ 🟢 BOUNDARY: Analytics, Logging  │
            │    (may need token format update)│
            └──────────────────────────────────┘

Operational Rules

  1. CORE FIRST: Always clearly define what's changing before mapping impact
  2. TRACE BOTH WAYS: Map upstream (dependencies) AND downstream (dependents)
  3. MARK BOUNDARIES: Know where the impact stops
  4. ESTIMATE BLAST RADIUS: Understand the scale of potential effects
  5. DOCUMENT SURPRISES: Note unexpected connections discovered
  6. VALIDATE WITH CODE: Don't guess — check actual imports/usage

Examples

❌ Without Impact Mapping

Task: "Update the date format in utils.js"
Action: Changed format from 'MM/DD/YYYY' to 'YYYY-MM-DD'
Result: 47 pages broke, 3 API integrations failed, customer reports corrupted
Why: Didn't map what used that utility

✅ With Impact-Map 150

Task: "Update the date format in utils.js"

🗺️ Impact-Map 150:

Core: formatDate() in utils.js

Upstream Dependencies:
- moment.js library
- locale config

Downstream Impact:
- 🔴 Critical: Invoice generation (uses formatDate)
- 🔴 Critical: API responses (15 endpoints)
- 🟡 Affected: All UI date displays (23 components)
- 🟢 Monitor: Log timestamps

Boundaries:
- Database stores as ISO, unaffected
- External APIs have their own formatting

Blast Radius: Large — touches most of UI

Action: Create formatDateNew(), migrate gradually, deprecate old

Failure Modes & Recovery

FailureDetectionRecovery
Missed dependencySomething breaks unexpectedlyExpand upstream mapping
Missed dependentUsers complain after changeTrace all usages with grep/IDE
Underestimated blast"Small change" causes chaosRe-map with wider scope
Unclear boundariesDon't know what's safeExplicitly mark boundaries

Relationship to Other Skills

SkillFocus
goal-clarity-150WHAT we want to achieve
deep-think-150HOW to think about it
impact-map-150WHAT it affects
max-quality-150HOW to do it well

Workflow:

goal-clarity-150 → impact-map-150 → deep-think-150 → max-quality-150
       ↓                 ↓                ↓                ↓
   Understand        Map what's         Think           Execute
   the goal          affected          through           well

Session Log Entry (MANDATORY)

After completing this skill, write to

.sessions/SESSION_[date]-[name].md
:

### [HH:MM] Analyze-Impact 150 Complete
**Core Change:** <what is changing>
**Blast Radius:** <Small/Medium/Large>
**Key Dependencies:** <critical up/downstream>
**Risks:** <identified risks>

Remember: Every change has ripple effects. The question isn't "will something else be affected?" but "what will be affected and how much?" Impact mapping turns surprises into planned awareness.