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

CORE FIRST: Always clearly define what's changing before mapping impact
TRACE BOTH WAYS: Map upstream (dependencies) AND downstream (dependents)
MARK BOUNDARIES: Know where the impact stops
ESTIMATE BLAST RADIUS: Understand the scale of potential effects
DOCUMENT SURPRISES: Note unexpected connections discovered
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:

### [date - 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.

30-analyze-impact-150