impact-check

Impact Check — Code Change Impact Analysis

Repo profile — read .claude/repo-profile.md first. This skill is repo-agnostic; arc is the reference implementation. The monorepo layout, package naming, and paths below (packages/, providers/, runtimes/, blocklets/) are arc's — map them to the consuming repo's structure via the profile.

Analyze code changes and find related areas in the codebase that may also need modification.

Input Modes

Parse $ARGUMENTS to determine the diff mode:

Input	Mode	Diff Command
(empty)	working-tree	git diff HEAD
--branch	current branch vs main	git diff $(git merge-base <main> HEAD)..HEAD
--branch <name>	named branch vs main	git diff $(git merge-base <main> <name>)..<name>
--branch <name> --base <base>	branch vs custom base	git diff $(git merge-base <base> <name>)..<name>
contains ..	commit range	git diff <from>..<to>
other	single commit	git diff <ref>^..<ref>

When detecting the main branch, check which of main or master exists.

Analysis Process

Step 1: Collect Changes

1. Determine diff mode from arguments
2. Run the appropriate git diff command (with --stat for summary, and full diff for content)
3. List all changed files and summarize: N files changed, +X -Y lines
4. If no changes found, report "Nothing to analyze" and stop

Step 2: Understand What Changed

For each changed file, read the diff and identify:

• Interface/type changes: function signatures, type definitions, exported types
• Export changes: added, removed, or renamed exports
• Behavioral changes: logic changes that could affect callers
• Configuration changes: package.json, tsconfig, linter/formatter config, etc.
• Schema/model changes: data structure modifications

Step 3: Find Related Code

For each significant change identified in Step 2:

1. Import/reference search: Use Grep to find every file that references the changed module.
   • For a deleted or renamed file/export, grep the bare basename or symbol (e.g. agent-core, deriveAgentTools) to get the full candidate set — then filter comments in Step 4 by reading. Do not rely on a single-line import … from / require(…) regex: it misses multi-line imports (where the from "…" line has no import keyword) and re-exports, silently dropping real breaks.
   • Also search string / dynamic references that no import regex catches: readSource("…/foo.ts"), readFileSync / join / resolve with the file path, dynamic import(…), and worker/route path literals. Cross-package breakage most often hides here (e.g. a runtimes/node/test/** that readSource()s a deleted providers/** file).
2. Symbol usage search: For changed/removed exports, Grep for their usage across the codebase
3. Test file check: For each changed file src/foo.ts, check if test/foo.test.ts exists and whether it was also modified
4. Documentation check: If interfaces or public APIs changed, check if README or docs reference them
5. Conformance test check: If the repo's Custom Impact Checks (.claude/repo-profile.md) declare a provider conformance suite, and a provider changed, verify its conformance fixture was updated
6. Caller check (new exports): For each added export/function/param, grep its call sites repo-wide. Zero callers inside the repo — and not a public API/SDK re-export — is a speculative abstraction with no consumer; flag it. A lower layer nothing calls should not land on its own; the author should point to the consumer, or the follow-up change that adds it.
7. Parity check — mirror & registration: Two flavors, both cross-file invariants a self-contained diff won't reveal:
   • Cross-runtime mirror: multi-target builds must stay in sync — a change that touches one deployment target or a shared cross-target provider means the sibling target(s) need the same semantic. A one-sided change is behavior drift between targets unless intentional. See the repo's Deployment Environments section (.claude/repo-profile.md) for which targets exist.
   • Declaration ↔ dispatch/renderer: the diff adds a variant to an enum / union type / registry / factory (a new widget, message type, provider kind, event, …) in one package → grep the consumer that switches on it (dispatch table, switch, renderer map, handler registry — often in a different package) and confirm it gained the matching case/handler. This is the inverse hazard of reverse-reference: deleting breaks compilation loudly, but adding-without-wiring compiles clean. A default/fallback branch (renders "Unknown", silent no-op, drops the message) swallows the missing case, so check-types and build stay green and the gap only shows at runtime as a degraded/absent result. Also check the reverse — a new dispatch case for a variant the declaration side never added.