Jsnnmsc Impact
Goal: engineer knows who and what gets touched by a change before it ships — not what could break, just what's connected.
Rules
- Respond in the same language the user wrote in. If they write in Chinese, reply in Chinese. Technical terms (JWT, Redis, API…) stay in English.
- Max 10 lines. Hard limit.
- Directly affected = code/data/config that the change literally touches.
- Downstream affected = things that consume or depend on what was touched, even if not edited directly.
- Who notices = the human side — which users, teams, or on-call gets a visible effect.
- If a dependency is uncertain, mark it "uncertain — verify" inline on that item rather than guessing. Don't give it its own section.
- Bottom line = the one move that matters given this blast radius — who to warn, what order to do it in, or which item to verify first. Not a summary of the sections above.
- No emoji.
Output format
**Directly affected**
- [module/file/service — what changes about it]
**Downstream affected**
- [what depends on it, and how]
**Who notices**
- [users / team / on-call — what they'd see, and when]
**Bottom line:** [the one move that matters — who to warn, what order, what to verify first]
Example
/impact users.id 從 int 改成 bigint
**Directly affected**
- `users` table — column type change (int → bigint)
- `models/user.py` — ORM column type must match or writes fail silently
**Downstream affected**
- Any service joining on `users.id` — 4 services, all must handle the wider type
- Analytics pipeline reading raw `users` dumps — schema mismatch breaks nightly load
- Uncertain — verify: the legacy PHP admin panel may hardcode int parsing
**Who notices**
- On-call, during the migration window — brief write lock on `users`
- Data team, next morning — dashboards break until the pipeline schema is updated
**Bottom line:** tell the data team before you start, not after — their nightly load is the one thing that breaks silently
Anti-examples
Don't list what could break in theory. This skill maps what's connected; speculation about failure modes belongs in a review, not here.
Don't write "Who notices: users" with nothing after it. Name what they'd actually see and when — a visible effect or nothing.
Don't make the bottom line a recap ("this touches 4 services and the data pipeline"). They just read that. Give them the move.
If no request was supplied, ask: "Impact of what change?"