agentleFS
jhlee0409jhlee0409/omni-harness-kit/skills/blast-radius/SKILL.md

blast-radius

Skill2 starsChanged 4 months agoMITView on GitHub

Enumerate the full impact set of a symbol before or during a change — every reference, caller, implementation/subtype, and reverse import — plus an explicit list of what could NOT be resolved (dynamic dispatch, reflection, generated code). Use before touching a shared / exported / widely-imported symbol, before an interface or signature change, or when the user asks "what breaks if I change this?", "어디까지 영향 가?", "누락 없이 찾아줘", "전부 찾았어?". Produces an evidence table + an "enumeration complete?" checklist; read-only.

111 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ketchup-video, principle-never-block-on-the-human and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • tristanphvnSkill

    ketchup-video

    Catch the user up like /keel:ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /keel:ketchup-video.

    Also in 14 projects that use this

  • jaydubya818Skill

    principle-never-block-on-the-human

    Apply when safe reversible implementation details can proceed inside scope.

    Also in 44 projects that use this

  • ianclearySkill

    principle-explain-the-number

    Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.

    Also in 29 projects that use this

  • eryzerzSkill

    make-bot-ui

    Use when building a custom UI (page, dashboard, buttons) that should wake a Grok Bot over a webhook, when the user must provide a webhook sender key, or when exposing that UI on Tailscale.

    Also in 20 projects that use this

  • bnemaSkill

    setup-pstack

    Configure which Pi models pstack uses per role. Detects available provider/model specs and writes pstack's user configuration. Use for /setup-pstack, "configure pstack models", or changing pstack model choices.

    Also in 25 projects that use this

  • jaydubya818Skill

    principle-make-operations-idempotent

    Apply when an operation must tolerate retries after partial completion.

    Also in 46 projects that use this

  • +6 more from jaydubya818

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 106 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run every layer available.

    line 33
  2. Distinctive:

    call hierarchy — incoming callers and outgoing callees.

    line 42
  3. Distinctive:

    Unknowns: every unresolved region + why.

    line 78
  4. Distinctive:

    Read-only — enumerate and report.

    line 96

“Common” is measured: kept by at least 6 in 10 of the 106 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

blast-radius — enumerate impact, surface the unknowns

You produce the impact set of a target symbol so a change can be made without missing a callsite. The honest contract of this skill: no tool guarantees omission-free discovery. LSP misses dynamic dispatch; grep misses renames; generated code and reflection defeat both. So you do NOT claim "completeness" — you guarantee all discovered edges, deduped with provenance, plus an explicit list of what you could not resolve. The unknowns section is the point, not an afterthought — it tells the human exactly where to look by hand.

1. Scope the target

Resolve the target symbol(s): a function / method / class / type / constant / API route / DB field / component / exported name. For a signature or rename change, capture BOTH the old and the new name. Note the declaring file:line.

2. Enumerate — layered, strongest signal first

Run every layer available; do not stop at the first. Cross-check the counts between layers — a divergence is itself a finding (a match one layer sees and another misses is a candidate omission).

  1. Code-intelligence (LSP / SCIP), if available — the strongest signal, because it resolves bindings, not text:
    • references — every use of the symbol.
    • implementations / type hierarchy — every impl / subtype (for an interface or base type).
    • call hierarchy — incoming callers and outgoing callees; traverse recursively with a depth cap and a cycle guard. Record the provider and that support was present. If no LSP/index is available, say so explicitly (it changes the confidence of the result).
  2. AST inventory (tree-sitter), if available — enumerate declarations, imports/exports, class inheritance, and call-shaped expressions. Use it to catch structural uses and to sanity-check the LSP count.
  3. Text sweep (ripgrep) — always — grep both the old and new names across the repo, excluding node_modules, .venv, dist, build, .next, coverage, and vendored dirs. This catches string/symbol refs the import graph misses (config keys, DI tokens, dynamic route strings, docs). Treat lexical matches as candidates, never as resolved references — never present a grep hit as a precise call edge.

3. Categorize the impact

Bucket every discovered edge so the human can reason about coverage:

  • Direct references — uses of the symbol.
  • Callers — incoming call sites (who breaks if the signature changes).
  • Implementations / subtypes — every type that must change together.
  • Reverse imports / dependents — modules that import the declaring module.
  • Tests / config / docs — test files, fixtures, config keys, and docs that name the symbol (often missed, often where a change actually breaks).
  • UNKNOWN / unresolved — dynamic dispatch, reflection, eval/metaprogramming, generated or macro-expanded code, framework-convention wiring, cross-language boundaries, and monorepo edges an unconfigured LSP can't cross. List each with why it's unresolved. THIS is where the human verifies by hand.

4. Report contract (BLUF)

  • Target: the symbol(s) + declaring file:line.
  • Searched scope: which layers ran (LSP? which provider / AST? / ripgrep) and the exclusion set — so the reader knows what was and wasn't covered.
  • Impact table: one row per edge — file:line · category · provider (lsp/ast/grep) · confidence (resolved / candidate).
  • Unknowns: every unresolved region + why. Non-empty is normal and expected.
  • Enumeration complete? checklist — answer each:
    • LSP available and used? (if no, recall is reduced — say so)
    • Old AND new name swept (for a rename)?
    • Tests / config / docs scanned?
    • Any layer-count divergence investigated?
    • Dynamic / generated / reflective code present and listed as unknown?

Constraints

  • Never claim completeness. State "all discovered edges + N unresolved regions (listed)", never "all callsites" / "nothing else uses it". A terminal claim of completeness on a symbol with unresolved dynamic edges is the failure mode this skill exists to prevent.
  • Degrade gracefully: no LSP → run AST + ripgrep and lower the stated confidence.
  • Consume a code-intelligence index if present; never ship one. Use the host's LSP or an existing SCIP/LSIF index when available — generating/maintaining an index is heavy and out of scope (an enterprise-adapter concern, not the portable kit).
  • Read-only — enumerate and report; make no edits.
  • Cite every edge with a file:line confirmed by Read/grep; a count with no rows is not evidence.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.