blast-radius
WHEN investigating impact analysis or what a change could break beyond its diff; NOT for a requirement verdict; maps material risks and decisive checks
- License 许可
- MIT
- 所属仓库
- mintuz/skills
- 最近更新
- 2026-11-13
- Stars
- ★ 35
- Forks
- 7
01 前言 Front Matter
- name
- blast-radius
- description
- WHEN investigating impact analysis or what a change could break beyond its diff; NOT for a requirement verdict; maps material risks and decisive checks
03 SKILL.md 正文
Blast radius
Trace the smallest set of assumptions that covers every material failure path. A single reassuring fact is enough only when it actually clears them all.
- Read the change and current implementation; establish the changed contract and relevant source/version. Follow direct callers, then indirect consumers: serialized or persisted data, other languages/processes, extensions, integrations, flags, lifecycle and task ordering. Check the shipped library version and local patches where semantics matter.
- For each reachable material risk, record the boundary, failure sequence, consequence and source locator. Use evidenced reachability and impact rather than invented probabilities. Keep confirmed facts, cleared paths and unresolved assumptions separate; a failed search is a bounded finding, not universal absence. A property or field rename, including one described as persisted, does not show that a stored or encoded key changed. Inspect the coding keys, schema, or equivalent mapping before concluding that the encoded key changed. Until that evidence exists, an encoded-key change is an assumption and the persistence risk stays unproven.
- Choose the cheapest decisive check for each independent assumption. Reuse a focused existing test when it exercises the real code. Check whether its fixture, timing, version and boundary coverage leave material assumptions untouched; add a narrow reproduction only for the gap. Execute available checks within the authorized scope; unavailable execution leaves the corresponding assumption unproven.
- Report the change, risk-to-check map, results and remaining proof gaps. Label static reasoning, unit, simulator, physical-device, browser and deployed evidence separately, with revision/environment identity. Name untested target environments explicitly: simulator-only mobile evidence leaves physical-device extension/lifecycle behavior unverified. A passing UI path does not prove persistence migration, wire compatibility or another process's lifecycle. Do not describe that save as a fresh or current-format round trip, or say that it exercises a new key, unless the evidence says so.
Keep the inquiry about regression risk. Requirement satisfaction belongs to acceptance-review; explanation and rationale belong to how and why. Independent review may help a wide change when authorized, but no particular reviewer, model, source host or new test framework is required.
04 同仓库更多 Skills
xstate
WHEN React state changes in response to an external answer — async submit, in-flight or loading flags, retries, cancellation, polling, optimistic updates, stale responses — or to an interaction with an interruptible middle, such as a drag or a gesture; or WHEN building, reviewing, testing, or visualising XState 5 actors and @xstate/react integrations; NOT for a value one event sets completely, such as a text draft, a focus flag, or a plain open and closed toggle; models typed lifecycles and renders legal Mermaid stateDiagram-v2 charts.
web-design
WHEN refining UI layout, typography, color, or polish; NOT code implementation; provides concise principles for intentional, legible design.
tailwind
USE WHEN writing, fixing or reviewing styling in a project that uses Tailwind CSS, even a one-class change or a request that does not name Tailwind: colours, focus rings, spacing, class names chosen by a prop, map or CVA variants, theme tokens and dark mode in the Tailwind stylesheet or tailwind.config, setup or upgrades (if unsure whether the project uses Tailwind, check package.json or the main stylesheet first); NOT WHEN writing plain CSS or Sass in a project without Tailwind; produces class names Tailwind can find, syntax for the installed major version, visible focus indicators, and no unrequested dependency or invented brand value.
refactoring
WHEN you need a plan to refactor, restructure, or clean up working code and the test result is known, either green or a recorded failing set; NOT for new feature delivery or any behavior change; reversible-baseline safety with prioritized improvements.
react
USE WHEN changing the logic, data, props, state, Effects or rendered text of a React component, hook or page, even a one-line change; NOT WHEN the request is styling only (class names, Tailwind, CSS, dark mode, spacing, shadows) or tests only, or when it models submit, in-flight, loading, retry or failure states, even for a named React form (xstate covers that, including its React wiring); applies React 19 composition, state, Effect, structure, API and performance rules with only the project's installed libraries.
react-testing
USE WHEN writing, fixing or reviewing a React Testing Library test for a component, hook or context provider, even one small test, or when asked for an end-to-end journey inside a Vitest or React Testing Library suite; NOT WHEN changing the component itself (react), testing XState actors or @xstate/react (xstate), or writing a Playwright or Cypress test; covers renderHook, providers, async results, forms and false-pass anti-patterns, and declines end-to-end journeys with the testable slices.