# Check Change Impact

> Inspect a code diff, branch, commit, or PR and report its concrete blast radius with minimal prose. Use when asked what changes after merge or deploy, which APIs, requests, responses, data, jobs, external calls, shared consumers, schemas, or neighboring features are affected, or whether any impact surface was missed.

- Skill: `cham0287/check-change-impact` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add cham0287/check-change-impact`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cham0287/check-change-impact/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: cham0287 (https://skillmd.com/u/cham0287)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/cham0287/check-change-impact

---


# Check Change Impact

Trace the actual diff to its callers and consumers. Report only evidenced changes and meaningful gaps. Do not edit code, post comments, or pad the result with generic risks unless the user separately asks.

## Operating contract

- **Problem:** a changed-file list does not show the runtime blast radius of shared contracts, data, jobs, external calls, generated types, or neighboring consumers.
- **Use when:** one concrete diff, branch, commit, or PR needs an impact report.
- **Do not use when:** the user wants implementation, fixes, a general code review, or an explanation without a resolvable change artifact.
- **Produce:** a compact distinction between direct changes, indirect consumers, confirmed unaffected paths, and material unverified surfaces.

## Composition boundary

Own exactly one artifact: the blast-radius report for a concrete repository, comparison base, and head SHA.

- Use this skill when the user wants impact explanation without review findings or fixes.
- Reuse a current report only when repository, base, and head SHA still match.
- Do not reconstruct the implementation plan, run a general code review, classify unrelated findings, or apply fixes.
- Expand beyond immediate callers only when the diff or a shared symbol provides evidence of an indirect consumer.

## Workflow

1. Lock the target: repository, branch/commit/PR, and comparison base. Read applicable repository instructions.
2. Inspect the changed-file list and relevant full diff. Compare changed behavior with the base version.
3. Search every changed public symbol with `rg`: routes, serializers, models, tasks, schedules, callers, shared consumers, tests, and generated contracts.
4. Trace the owner path:

   ```text
   inbound request or scheduler -> owner logic -> external call -> database
                                -> response/schema -> direct and shared consumers
   ```

5. Check these surfaces, but report only material results:

   - API: exact endpoint and method, auth, path/query/body changes.
   - Response: added/removed fields, null/status semantics, ordering, pagination/cardinality.
   - Data: table/field reads and writes, migration, historical mutation, backfill, retention.
   - Async/external: task cadence, target eligibility, request parameters, call count, retry/error behavior.
   - Indirect: shared serializers/helpers/models, other endpoints, generated types, frontend or service consumers.
   - Runtime cost: added queries, joins, payload growth, or result growth when meaningful.
   - Unaffected: nearby paths that were searched and confirmed unchanged.

6. Verify relevant tests and current CI when available. Mark real external API or production behavior as unverified unless runtime evidence exists.

## Evidence Rules

- Distinguish inbound API request changes from outbound third-party request changes.
- Distinguish runtime response changes from OpenAPI/generated-type-only changes.
- Distinguish “no migration” from “no data writes” and “no historical backfill.”
- Treat shared serializers and helpers as indirect contract surfaces even when one caller omits the new field at runtime.
- Note pagination impact when newly eligible rows can change counts or page contents.
- Do not say “no other impact” until usages and adjacent routes have been searched.
- Label facts as confirmed, inferences as such, and missing runtime proof as unverified.
- Avoid hypothetical failure lists that are not specific to the diff.

## Output

Keep the answer compact and use this shape. Omit empty sections.

```markdown
결론: <one sentence>

핵심 변화
- <maximum three bullets>

| 범위 | 변경 전 -> 변경 후 | 영향 소비자 |
| --- | --- | --- |
| API/Request | ... | ... |
| Response | ... | ... |
| Data | ... | ... |
| Job/External | ... | ... |

간접 영향
- <shared contract or neighboring consumer only>

변하지 않는 것
- <confirmed nearby paths, one compact bullet>

검증/미확인
- <tests/CI and first meaningful runtime gap>
```

Prefer one table and at most eight total bullets. Include clickable file links when referring to local code.