Change impact analyzer

Skill willianbs/skills/change-impact-analyzer

AI Engineering Operating System

Install

npx -y skills add willianbs/skills --skill change-impact-analyzer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Maps blast radius of a proposed change across services, APIs, data, and clients. Use before risky merges, migrations, or multi-service work. Emits IMPACT_REPORT. Never approves ship without naming affected consumers.

SKILL.md

2.8 KB, as published. Nobody here has run it

Purpose

Quantify who and what a change breaks or touches so planning and QG can size risk correctly.

When to Use / When NOT to Use

Use when: cross-service changes, API/schema edits, shared library bumps, migrations, large refactors, “what will this break?”.

Do not use when: typo/docs-only; pure local private helper with no exports (lite one-liner OK).

Preconditions

Diff, PR, or proposed change description plus CONTEXT_PACK (or ability to search callers/contracts).

Inputs / Outputs

Inputs: change set / plan, CONTEXT_PACK, OpenAPI/proto/schema if present, TASK_GRAPH optional.

Outputs: IMPACT_REPORT

Upstream / Downstream

Upstream: delivery-planner, feature-implementer, api-contract-guardian, engineering-os.

Downstream: delivery-planner, test-strategy-designer, quality-gate, migration-surgeon, pr-generator.

Core Principles

Follow edges: imports, APIs, events, schemas, feature flags, config.
Name concrete consumers (services, packages, mobile/web).
Separate breaking vs compatible vs unknown.
Data/migration impact is first-class.
Unknown consumers → ProceedWithConditions or Block for public APIs.
Prefer evidence (grep, refs, contracts) over guessing.
Do not implement the change.

Process

Summarize the change intent.
Identify exported surfaces touched (HTTP, RPC, events, DB, packages).
Trace inbound/outbound dependents in-repo; note external unknowns.
Classify impact per consumer: None | Compatible | Breaking | Unknown.
Runtime/ops impact — deploy order, flags, dual-write, cache.
Test/rollout recommendations.
Decision for planner/QG.

Evidence Requirements

Cite paths, symbol names, contract files. Mark Unknown explicitly.

Stop Conditions / Failure Modes

Condition	Action
Public API change with Unknown consumers	Block or ProceedWithConditions + required discovery
Cannot access codebase	Refuse

Severity + Confidence

Breaking public contract without migration path → High/Critical.

Output Contract

## IMPACT_REPORT
Change summary: ...
Surfaces touched: ...
Consumers:
  - name, impact class, evidence
Deploy/order notes: ...
Unknowns: ...
Decision: Proceed | ProceedWithConditions | Revise | Block

Handoffs

api-contract-guardian, migration-surgeon, delivery-planner, test-strategy-designer, quality-gate.

Never

Never claim “no impact” without a search.
Never ignore versioning/compat windows for public APIs.
Never silently expand scope into implementing the change.