30-analyze-impact-150

# 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

| Layer | Description | Coverage |
|-------|-------------|----------|
| **Core** | What's directly changing | 100% — must fully understand |
| **Immediate** | Direct dependencies and users | 50% — must assess |
| **Extended** | Secondary effects | 25% — should consider |
| **System** | Full ecosystem | 10% — 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

| Failure | Detection | Recovery |
|---------|-----------|----------|
| **Missed dependency** | Something breaks unexpectedly | Expand upstream mapping |
| **Missed dependent** | Users complain after change | Trace all usages with grep/IDE |
| **Underestimated blast** | "Small change" causes chaos | Re-map with wider scope |
| **Unclear boundaries** | Don't know what's safe | Explicitly mark boundaries |

## Relationship to Other Skills

| Skill | Focus |
|-------|-------|
| **goal-clarity-150** | WHAT we want to achieve |
| **deep-think-150** | HOW to think about it |
| **impact-map-150** | WHAT it affects |
| **max-quality-150** | HOW 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.