Update to pstack

{
  "description": "Find what a code change could break outside the diff by tracing callers, contracts, shared data, external integrations, lifecycle behavior, and downstream consumers. Use for 'blast radius of X', 'what could this break', risky PR reviews, regression analysis, and checking whether a small change is actually isolated.",
  "included_files": [],
  "name": "blast-radius",
  "skill_md_contents": "---\nname: blast-radius\ndescription: \"Find what a code change could break outside the diff by tracing callers, contracts, shared data, external integrations, lifecycle behavior, and downstream consumers. Use for 'blast radius of X', 'what could this break', risky PR reviews, regression analysis, and checking whether a small change is actually isolated.\"\n---\n\n# Blast radius\n\nFind what a change could break somewhere else.\n\nDo not stop at the diff or a list of direct callers. The useful part is finding effects that are separated from the changed code by data, timing, configuration, persistence, events, or another system.\n\nUse this skill for questions like:\n\n* \"What could this break?\"\n* \"What's the blast radius of this PR?\"\n* \"Is this change actually isolated?\"\n* \"What else depends on this?\"\n* \"Could this cause a regression elsewhere?\"\n* \"Review this small diff. I don't trust it.\"\n\nUse `how` when you first need to understand the behavior being changed.\n\nUse `why` when an odd constraint or workaround may exist for a historical reason.\n\n## Read the change first\n\nInspect the actual change when it is available.\n\nThat may be:\n\n* a PR\n* a diff\n* a commit\n* a patch\n* changed files supplied by the user\n* a proposed change described in the conversation\n\nWork out what behavior changes, not just which lines change.\n\nIdentify:\n\n* symbols added\n* symbols changed\n* symbols deleted\n* types whose shape changed\n* persisted data that changed\n* messages or API contracts that changed\n* configuration that changed\n* lifecycle or ordering changes\n* behavior removed implicitly\n\nA ten-line diff can change a contract used by the whole system.\n\nA hundred-line internal refactor may change nothing outside one module.\n\nJudge the behavior, not the size.\n\n## Find the safety fact\n\nMost changes depend on a small number of facts being true.\n\nFind them.\n\nFor example:\n\n```text\nThis is safe only if every caller already handles a missing value.\n```\n\nOr:\n\n```text\nThis is safe only if this field is never read after the session closes.\n```\n\nOr:\n\n```text\nThis is safe only if no other service consumes this JSON field.\n```\n\nOr:\n\n```text\nThis is safe only if duplicate delivery is already handled downstream.\n```\n\nWrite the safety fact plainly.\n\nIf several independent facts must all hold, list them separately.\n\nDo not bury them inside a long risk report.\n\n## Check the obvious references\n\nFind direct dependencies first.\n\nLook for:\n\n* callers\n* imports\n* implementations\n* interface consumers\n* subclasses\n* tests\n* configuration references\n* constructors\n* dependency injection wiring\n\nThis establishes the immediate scope.\n\nIt does not establish the whole blast radius.\n\n## Look where symbol search stops\n\nMany regressions happen through relationships that do not share a symbol name.\n\nTrace the changed behavior through the system.\n\nCheck for these when relevant.\n\n### Data\n\nFollow data that crosses a boundary.\n\nLook for:\n\n* JSON properties\n* database columns\n* serialized types\n* cache keys\n* files\n* generated code\n* environment variables\n* configuration keys\n* message payloads\n* shared schemas\n\nA field rename can break code in another service that never imports the changed module.\n\n### Persistence\n\nIf stored data changes, check who reads old and new records.\n\nAsk:\n\n* Can old records still be loaded?\n* Can new code read data written by the previous version?\n* Can the previous version read data written by the new version?\n* Does a migration need to happen before deployment?\n* Are defaults different for existing rows?\n* Does a derived value now mean something different?\n\nTreat compatibility across deployments as part of the change.\n\n### APIs and messages\n\nCheck consumers of:\n\n* HTTP requests\n* HTTP responses\n* webhooks\n* events\n* queues\n* topics\n* RPC calls\n* command payloads\n* file formats\n\nLook beyond the repository when the contract crosses repository boundaries.\n\nDo not assume an API is private because there are no callers in the current repo.\n\n### Lifecycle and timing\n\nA change can preserve the same types and still change behavior through timing.\n\nCheck:\n\n* initialization\n* cleanup\n* mount and unmount\n* connection setup\n* retries\n* timeouts\n* asynchronous callbacks\n* event ordering\n* transaction boundaries\n* shutdown\n* background jobs\n* concurrent access\n\nAsk whether something now happens earlier, later, more often, less often, or more than once.\n\n### Shared state\n\nFind state read or written by more than one part of the system.\n\nLook for:\n\n* database rows\n* cache entries\n* files\n* global state\n* shared objects\n* branches or versioned state\n* distributed locks\n* counters\n* queues\n\nA local-looking write may change behavior far away.\n\nApply `principle-separate-before-serializing-shared-state` when concurrent writers are involved.\n\n### Configuration\n\nCheck whether the path changes according to:\n\n* feature flags\n* tenant settings\n* environment\n* deployment mode\n* product tier\n* runtime configuration\n* platform\n* version\n\nA path that looks dead in one configuration may be active in another.\n\n### External libraries\n\nIf safety depends on library behavior, inspect the version the project actually uses.\n\nDo not rely on memory of how the library usually behaves.\n\nCheck:\n\n* the pinned version\n* the library documentation for that version\n* source when available\n* local wrappers\n* patches\n* version-specific behavior\n\nTreat library behavior you cannot verify as an assumption.\n\n## Follow effects downstream\n\nDo not stop when the changed function returns.\n\nAsk what happens to its result.\n\nTrace:\n\n```text\nchange\n-> caller\n-> state change\n-> serialized data\n-> downstream consumer\n-> user-visible effect\n```\n\nThe important regression may be several steps away from the changed line.\n\nFor event-driven systems, follow the event to its consumers.\n\nFor UI changes, follow state through rendering and cleanup.\n\nFor persistence changes, follow the stored value to later reads.\n\nFor APIs, follow the response or request into its consumer when that source is available.\n\n## Check deletion carefully\n\nRemoved code deserves its own search.\n\nWhen a symbol, field, endpoint, branch, or behavior disappears, look for:\n\n* direct references\n* dynamic references\n* serialized names\n* configuration\n* documentation that drives external clients\n* tests\n* migrations\n* scripts\n* another repository\n* operational tooling\n\nA search that finds no direct references is useful evidence.\n\nIt is not proof that no external consumer exists.\n\n## Rate each real risk\n\nDo not return a page of hypothetical failures.\n\nKeep risks that have a credible path from the change to a failure.\n\nFor each risk, state:\n\n* what breaks\n* how the change reaches it\n* the evidence\n* likelihood\n* impact\n* what would prove or disprove it\n\nUse simple likelihood labels:\n\n* low\n* medium\n* high\n\nUse simple impact labels:\n\n* low\n* medium\n* high\n\nDo not invent numeric probabilities without data.\n\n## Separate risks from cleared concerns\n\nA concern you investigated and disproved is useful.\n\nPut it under `Cleared`.\n\nFor example:\n\n```text\nCleared\n\nOlder sessions can still be loaded. The new field has a default and the\ndeserializer accepts records where the field is absent.\n```\n\nThis prevents someone else from repeating the same investigation.\n\nDo not leave cleared concerns mixed into the active risk list.\n\n## Evidence levels\n\nSay how strongly each important safety fact has been checked.\n\nUse these levels.\n\n### 1. Assumption\n\nThe claim sounds plausible but has not been verified in the available source.\n\nDo not call the change safe based on this.\n\n### 2. Source evidence\n\nConcrete code, documentation, configuration, or contract supports the claim.\n\nCite the source.\n\n### 3. Path traced\n\nYou followed the relevant behavior through its callers, state changes, boundaries, or consumers and could not reach the failure case.\n\nExplain the path.\n\n### 4. Automated evidence\n\nAn existing test, CI result, recorded reproduction, or other executable evidence directly exercises the safety fact.\n\nInspect the test or result before relying on it.\n\nA passing build is not enough when the relevant behavior is not tested.\n\n### 5. Runtime evidence\n\nA recorded runtime reproduction, production observation, integration result, or equivalent evidence demonstrates the behavior in the real system.\n\nUse this only when that evidence is actually available.\n\nDo not claim a higher level than the evidence supports.\n\n## Do not pretend ChatGPT ran the code\n\nThis skill may be used in a chat where code execution is unavailable.\n\nNever say:\n\n* \"I tested this\"\n* \"I reproduced this\"\n* \"This passes\"\n* \"I verified this at runtime\"\n\nunless an available tool actually produced that evidence.\n\nExisting CI or test results may count as evidence when you can inspect what ran and whether it covers the claim.\n\nIf the safety fact needs execution and you cannot execute it, mark it:\n\n```text\nUnproven\n```\n\nThen give the smallest test or reproduction that would settle it.\n\nFor example:\n\n```text\nUnproven: whether duplicate delivery can create two payments.\n\nTest before merge:\ndeliver the same payment event twice with the same event ID and assert that\nonly one payment record exists.\n```\n\nThat is better than pretending static analysis settled a runtime question.\n\n## Review the test coverage that matters\n\nDo not ask whether the project \"has tests.\"\n\nFind whether a test covers the exact safety fact.\n\nA useful test should fail if your concern is real.\n\nIf changing the risky behavior would leave the test green, that test does not prove the behavior.\n\nWhen existing tests do not cover the risk, describe the smallest useful test.\n\nDo not demand broad test suites when one focused regression test would settle the question.\n\n## Handle cross-repository changes\n\nWhen a contract leaves the repository, inspect connected repositories when they are available.\n\nSearch for:\n\n* endpoint paths\n* event names\n* JSON properties\n* schema names\n* database contracts\n* package versions\n* protobuf fields\n* GraphQL fields\n* shared type packages\n\nIf you cannot access likely consumers, state the limitation.\n\nDo not write:\n\n```text\nNo other consumers exist.\n```\n\nwhen all you know is:\n\n```text\nNo other consumers were found in this repository.\n```\n\n## Handle PR reviews\n\nFor a PR, inspect more than the patch when the source is available.\n\nUseful evidence includes:\n\n* PR description\n* changed files\n* review discussion\n* linked issues\n* relevant commits\n* tests changed with the PR\n* CI results\n* surrounding implementation\n* consumers outside the diff\n\nA reviewer who reads only the changed lines sees the author's framing of the change.\n\nBlast-radius review checks whether the rest of the system agrees.\n\n## Output\n\nKeep the report focused.\n\nUse this shape for a meaningful change.\n\n### What changed\n\nExplain the behavioral change in a few sentences.\n\nInclude behavior that is easy to miss from the diff.\n\n### Safety facts\n\nState the facts that must hold for the change to be safe.\n\nFor each one, give its evidence level.\n\nExample:\n\n```text\nSafety fact\n\nAll exit attempts already tolerate a missing payment record.\n\nEvidence level: Path traced.\n\nThe exit handler treats a missing payment as unpaid and refuses the exit.\nBoth camera and manual exit paths use the same handler.\n```\n\n### Risks\n\nInclude only credible risks.\n\nFor each one give:\n\n```text\nRisk\nHow it breaks\nEvidence\nLikelihood\nImpact\nHow to settle it\n```\n\nUse prose when that reads better than a template.\n\n### Cleared\n\nList concerns you checked and ruled out.\n\nSay why they are safe.\n\n### Before merge\n\nGive the smallest tests, checks, or reproductions that would settle anything still unproven.\n\nIf everything important is already supported by strong evidence, say so instead of inventing more work.\n\n## When the change is small\n\nDo not force the full report onto a tiny diff.\n\nA small answer may be:\n\n```text\nThis change has one meaningful dependency outside the diff.\n\nThe new nullable value reaches `createInvoice`, but that function already\nhandles absence by skipping invoice creation. I traced both callers and found\nno serialized or external use of the field.\n\nThe remaining unknown is the mobile client. It consumes the same API but its\nrepository is not available here, so compatibility with that client is\nunproven.\n```\n\nThat is enough.\n\n## Writing\n\nApply `unslop` to the answer.\n\nCite real source.\n\nState what you checked and what remains unknown.\n\nDo not turn possibilities into bugs.\n\nDo not turn absence of evidence into proof of safety.\n\nDo not pad the answer with every caller you found.\n\nFind the few facts the change depends on and test those facts as far as the available evidence allows.\n\nReply with the blast-radius analysis itself.\n"
}