Skill · read-only

Impact Map

Before I change this, what else could this change affect? Impact Map turns a change request into an evidence-based blast-radius report — what is affected, why it is affected, how confident the analysis is, and what should happen next. It stops before touching your code.

Soumya Rauth · Creator & maintainer

npx skills add soumyaRauth/skills-hub --skill impact-map

The problem

ticket → find the obvious file → change it → discover later what broke

The obvious file is rarely what breaks. What breaks is the raw SQL in a report, the string comparison in a nightly job, the fixture that keeps CI green while the behavior is wrong, the policy that never learned about the new state. None of those show up in an import graph, and none of them fail at build time.

What Impact Map does instead

ticket → impact map → architecture → dependencies → hidden coupling
→ tests → risks → implementation plan → coding

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Engages	A change alters something other code depends on: a shared status or enum, a schema, an API response, configuration, cross-module behavior, or code read by raw SQL, jobs and reports. Also on “what’s the blast radius?” and “what did this PR miss?”
Stays quiet	New isolated code, copy, typos, formatting, comments, renames the type checker covers, dependency bumps.
Depth	Active. Asked for a map, it reports and stops, read-only. Asked for the change itself, it runs first as a compact pre-step, and the change proceeds on the surface it found.
Works with	ProofBuild, Production Guard, API Contract Guard, Project Compass, Engineering Investigator

Not a file list

Every significant finding carries a classification, the evidence behind it, and a concrete next action. Confidence is tracked separately, and a low-confidence finding is never promoted to must change.

Classification	Meaning
🟥 Must change	Strong evidence this location requires modification.
🟧 Likely affected	Strong relationship established; whether it changes needs confirmation.
🟨 Needs verification	Plausible relationship that must be checked before implementing.
⚠️ Hidden coupling	Indirect dependency — raw strings, SQL, config, duplicated logic, fixtures, serialization, co-change history.
⬜ Out of scope	Inspected and found not materially related.

Evidence or nothing. Speculation is never presented as fact, invented file counts are forbidden, and the skill names what it could not inspect rather than leaving a silent gap.

Example output

Abbreviated. A rename that a type checker would call complete:

🟥 MUST CHANGE

backend/models/enrollment.py
  Symbol:       EnrollmentStatus.COMPLETED
  Evidence:     COMPLETED = "completed" — member name and stored string
                both carry the old name.
  Confidence:   High

⚠️ HIDDEN COUPLING

backend/reports/completion_report.py
  Coupling type: Raw SQL
  Evidence:      WHERE status = 'completed' — never touches the enum.
  Confidence:    High
  Action:        Silently returns zero rows after the rename.

backend/jobs/nightly_sync.py
  Coupling type: Raw string + direct data access
  Evidence:      if row["status"] == "completed" — bypasses the service layer.
  Confidence:    High

RISK

Risk score: 15 / 18 → High

Breadth             3   backend, frontend, jobs, and reporting all in scope
Coupling opacity    3   raw SQL, a direct-read job, a duplicated UI comparison
Test coverage       3   no test asserts report or sync behavior for this status
Reversibility       2   value rename with a backfill of existing rows
Consumer reach      3   a partner system reads the value; BI consumers are
                        suspected and not enumerable from this repository
Area volatility     1   normal churn, except one stale job

Nothing in CI fails if the string-coupled paths are missed.

Five full worked examples ship with the skill: simple change, API change, database change, cross-module change, and the implementation plan that follows it.

Risk is a scored argument

Six factors, each scored 0–3 from what the analysis actually observed, each printed with the observation that set it. The factor table is mandatory — a total without its factors is exactly the invented number this skill forbids. A factor that could not be assessed is scored ?, and the total becomes a lower bound rather than being rounded down.

Factor	What moves it
Breadth	Files → layers → packages → separate runtimes
Coupling opacity	Hard edges only, up to duplicated logic on untested critical paths
Test coverage	Whether anything fails if the change is wrong
Reversibility	Code change → additive schema → contract change → lossy migration
Consumer reach	One caller here → cross-team → consumers outside this repository
Area volatility	Churn, half-finished migrations, and whether anyone still owns it

Not a quality score. No percentages, no health metric, and not comparable between repositories. It is the argument for the band, written down so you can disagree with it.

What the code does not say

Git history

Files that keep being committed together are coupled whether or not any import says so. A file in most of a concept's commits with no reference between them is temporal coupling — reported at Medium confidence, because history proves correlation, not causation. The same pass reads churn as a risk input and CODEOWNERS as review routing, never as attribution.

Monorepo scope

Scope follows the package graph, not directory proximity: read the workspace config, find the package the change originates in, invert the graph for its dependents. The report states what was in scope, what was not, and why — partial coverage that names its boundary beats partial coverage presented as complete.

Architecture graph

When the surface branches or crosses three or more layers, it is drawn: one subgraph per layer the repository actually has, every edge labelled with its relationship, solid for hard edges and dashed for the quiet ones. It renders findings already in the report — no invented boxes.

A change you already made

Point it at a branch, a PR, or uncommitted work. The change statement comes from what the code now does, the analysis runs on the diff's symbols, and then the already-changed files are subtracted. What remains is the finding: the surface the change touches but never visited.

From map to plan

The map stops before implementation. Ask for the plan and you get a handoff artifact — executable by an engineer, or by a fresh agent session that never saw the analysis. Still no code.

STEP 2 — Rename the enum member and its stored value

  Files:      backend/models/enrollment.py
              backend/services/enrollment_service.py
  Resolves:   F1, F2
  Depends on: Step 1 deployed.
  Change:     Rename the member and its value; update the typed writer in the
              same step — the rename breaks it, so they are one commit.
  Verify:     The existing service test passes against the new member; the type
              checker reports no remaining references to the old name.
  Rollback:   Revert. Step 1 left every reader tolerant of both values.

COVERAGE
  F1 → step 2   F2 → step 2   F3 → step 4   F5 → prerequisite   …
  Deferred: none      Unmapped: none

Every finding id maps to a step — a must change with no step is an invalid plan
Needs verification findings become prerequisites, resolved before the steps that depend on them
Every step leaves the system working, and is sized to one commit
Verification is an observation, never “verify it works”
If implementation contradicts the map, the rule is to stop and name the finding that changed

Install

Any Agent Skills-compatible agent

npx skills add soumyaRauth/skills-hub --skill impact-map

Claude Code

npx skills add soumyaRauth/skills-hub --skill impact-map --agent claude-code --copy

Using it

No slash command — installed skills are matched by description, so you just ask for what it does:

“What's the blast radius of adding an approval step to course completions?”
“Before you change anything, map the impact of renaming this status.”
“Deep impact analysis on switching the notification provider.”

Normal vs deep

Deep mode triggers on deep analysis, full impact analysis, blast radius, thorough, or comprehensive. It means more investigation — not a longer file list.

	Normal	Deep
Repository reconnaissance	✅	✅
Direct dependency tracing	✅	✅
Cross-layer inspection	✅	✅
High-value hidden coupling	✅	✅
Exhaustive string / SQL / config sweep	—	✅
Events, jobs, schedules, permissions	as relevant	✅
Fixtures, generated code, external boundaries	as relevant	✅
Co-change history per concept	high-value only	✅
Transitive dependent packages	direct only	✅

When to use it

Good fit

Business logic, shared services, state machines
Schema and API contract changes
Unfamiliar or legacy codebases
Changes crossing modules, layers, or teams
Auth, permissions, and visibility rules
Anything consumed by jobs, reports, or integrations

Skip it

Typos, copy changes, formatting
Dependency bumps
Greenfield code with no consumers
You already know the surface and it is one file
You need the code written right now

Read-only by design

During analysis the skill does not modify source files, create migrations, edit configuration, install packages, delete files, commit, push, or “fix” what it finds. It reads files, git metadata, and dependency manifests. Implementation happens only when you explicitly ask, after the map.

Team customization

Drop a company-architecture.md into the skill's references/ folder describing your domain boundaries, layer locations, naming conventions, shared modules, integrations, and business terminology. The skill reads it during reconnaissance, where it overrides generic framework assumptions. A template ships with the skill.

Pairs with Production Guard

ticket → impact-map → implement → production-guard → ship

Impact Map runs before implementation and maps what a change will touch. Production Guard runs after and validates that what was built is safe to ship. Neither requires the other.

Limitations

Impact Map is instruction-driven, not a static analyzer. It does not claim completeness, and it cannot prove one.

Results vary with the agent, the repository, and how the request is phrased
Dynamic dispatch, reflection, runtime configuration, and generated clients are where it is weakest
It only sees one repository — cross-repo and warehouse consumers surface as open questions at best
Large monorepos need scoping
It does not run your tests and cannot verify its own findings

Treat the output as a well-evidenced starting point for engineering judgment.