assessing-impact/SKILL.md
Pre-change blast-radius report for a symbol or file. Walks tree-sitting references, augments with a plain-text scan over non-parsed files (configs, plain docs), and clusters affected sites by feature (`_FEATURES.md`) or top-level package. Use when about to refactor, rename, or delete something in a repo you don't own — "what breaks if I change `validateUser`", "who calls this", "is this safe to remove", "where is this used", "blast radius", "impact analysis". This is the CONVERGENT pre-change risk skill — for "what is this repo?" use exploring-codebases; for "where is X?" use searching-codebases.
npx skillsauth add oaustegard/claude-skills assessing-impactInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Cheap, ad-hoc impact analysis for a single target. Not a graph database — a focused walk over an AST cache plus a complementary text scan, clustered into a report that's easy to summarize.
Use this when you're about to refactor / rename / delete a symbol in a repo you don't work in daily, and you want a single artifact that says: "these N files will need to change, in these M packages, with these tests likely affected."
Don't use this for deep ongoing impact analysis on your own codebase — stand up GitNexus, SourceGraph, or your IDE's index. This skill is for the one-shot case.
uv venv /home/claude/.venv 2>/dev/null
uv pip install --python /home/claude/.venv/bin/python tree-sitter
export PYTHON=/home/claude/.venv/bin/python
export IMPACT=/mnt/skills/user/assessing-impact/scripts/impact.py
The script depends on the tree-sitting skill — it imports engine.py
directly. The bundled grammars live with tree-sitting; no separate
language-pack install needed.
$PYTHON $IMPACT /path/to/repo SYMBOL_NAME
Or target a whole file:
$PYTHON $IMPACT /path/to/repo path/to/module.py
The script prints a structured markdown report. Treat it as input for your final summary, not the deliverable. It deliberately doesn't assign a "high/medium/low" risk label — that's your job, after weighing:
If a particular package looks suspicious, follow up with tree-sitting
to read the actual call sites:
TREESIT=/mnt/skills/user/tree-sitting/scripts/treesit.py
$PYTHON $TREESIT /path/to/repo --no-tree 'source:caller_function'
| Flag | Default | Purpose |
|------|---------|---------|
| --features PATH | _FEATURES.md | Root _FEATURES.md — when present, refs get clustered by feature in addition to by package. |
| --skip DIRS | (defaults from tree-sitting) | Extra comma-separated dirs to skip. |
| --limit-per-name N | 500 | Cap refs per symbol name. Bump if you suspect truncation. |
| --json | off | Emit JSON instead of markdown — for downstream tooling. |
# Impact Report: <target>
## Target
Kind, definition sites with line ranges.
## Direct & Textual References (N total)
Top-line counts, then refs grouped by:
- Code references by package
- Test references
- Documentation mentions
## Affected Features (from _FEATURES.md) ← only if file present
Feature name → ref count + file count.
## Suggested Test Surfaces
Test files that already reference the target, plus tests neighboring
the definition. Likely the regression net for the change.
## Caveats
What the scan can't see (dynamic dispatch, cross-language, cross-repo).
exploring-codebases if the repo also has a freshly
generated _FEATURES.md — the impact report will cluster refs by
feature, which makes the blast radius story much more legible than
raw package directories.tree-sitting to drill specific call sites once impact has
identified them.searching-codebases when you want regex/AST search over the
same corpus rather than impact analysis on a known target.run, init, handler) will
pick up unrelated symbols. Prefer running this on distinctive names;
otherwise expect noise and read the snippets.getattr, duck-typed
method calls, virtual dispatch in C++) is missed or over-matched.scripts/impact.py — Single-entry CLI. Resolves target → walks AST
refs → augments with text scan → clusters by package and (optionally)
by feature → renders markdown or JSON.development
--- name: verifying-claims description: Check that a document's claims about code are actually true by reading the prose, the code, and the tests and reporting (or fixing) where they disagree. Use whenever the user wants to verify a README, guide, spec, or docstring still matches the code; whenever they mention documentation drift, doc-code sync, "is this still accurate", stale docs, or keeping docs/tests/code consistent; before publishing or merging a docs change; or as a periodic doc-accuracy
tools
Query, filter, and transform Markdown structurally with mq — a jq-like CLI for Markdown. Use to extract headings/sections/code-blocks/links from .md files, build a table of contents, pull code blocks of a given language, slice or reshape LLM prompt/output Markdown, or batch-transform docs. Triggers on "extract sections from this markdown", "get all the code blocks", "jq for markdown", "mq", or any structural query over Markdown that grep/Read can't do cleanly.
development
Composes single-file HTML artifacts (PR review writeups, status reports, incident postmortems, slide decks, design systems, prototypes, flowcharts, module maps, feature explainers, kanban boards, prompt tuners) from a small JSON spec instead of hand-written HTML/CSS/JS. Use when the user asks to "compare options side-by-side", requests an HTML version of a report or review or deck, asks for a flowchart, status update, postmortem, design system reference, interactive prototype, custom editor — or explicitly says "HTML artifact", "single HTML file", "self-contained HTML". Skip for ad-hoc HTML snippets (forms, emails, embedded widgets) where there's no template fit.
development
DAG workflow runner that encodes control flow in code, not prose. Use when a procedure has 3+ steps with branching, retries, or validation that must be enforced — gates as `when=`, edge contracts as `validate=`, predicate loops as `retry_until=`. The runner owns the graph; the LLM provides leaves. Also covers parallel execution, checkpoint resume, detached side-effects.