Skill v1.0.2
currentAutomated scan100/1001 files
version: "1.0.2" name: memtrace-impact description: "Compute the blast radius of modifying a symbol through transitive graph impact. Use when the user asks about blast radius, impact, what breaks, risk, upstream callers, downstream dependencies, or consequences of modifying a symbol, before or during source-code changes. Do not use Grep or manual reference search; Memtrace computes transitive graph impact. For a full risk-rated plan covering a multi-part change, use memtrace-change-impact-analysis."
Overview
Compute the blast radius of changing a specific symbol. Traces upstream (what depends on this) and downstream (what this depends on) through the knowledge graph to quantify risk before making modifications.
Quick Reference
| Tool | Purpose | |
|---|---|---|
get_impact | Blast radius from a symbol name (target) | |
detect_changes | Scope symbols affected by a diff/patch |
Parameter types: MCP parameters are strictly typed. Numbers (depth,limit, etc.) must be JSON numbers — not strings.
Required parameters — get_impact
| Parameter | Required | Default | Notes | |||
|---|---|---|---|---|---|---|
repo_id | yes | — | ||||
target | yes | — | Symbol name (e.g. "validateToken") — not symbol_id | |||
direction | no | "both" | "upstream" \ | "downstream" \ | "both" | |
depth | no | 5 | BFS depth (max 15) | |||
as_of | no | now | ISO-8601 for time-travel |
{ "repo_id": "memdb", "target": "validateToken", "direction": "both", "depth": 5 }
Full parameter spec for every Memtrace tool: references/mcp-parameters.md (bundled at the memtrace-skills plugin root).
Steps
1. Identify the symbol name
If you don't know the exact name:
find_symbol(name="...")for exact identifiersfind_code(query="...")for natural-language queries
Use the returned `name` (and optional file_path hint) — graph tools resolve by name, not internal IDs.
2. Run impact analysis
{"repo_id": "memdb","target": "validateToken","direction": "upstream","depth": 5}
3. Interpret the risk rating
| Risk | Meaning | Action | |
|---|---|---|---|
| Low | Few dependents, leaf node | Safe to modify; minimal testing needed | |
| Medium | Moderate dependents | Test direct callers; review interface contracts | |
| High | Many dependents across modules | Coordinate changes; comprehensive test coverage | |
| Critical | Core infrastructure, many transitive dependents | Plan migration strategy; backward-compatible changes |
4. For diff-based analysis
When you have an actual code diff, use detect_changes:
{ "repo_id": "memdb", "diff": "<unified git diff text>" }
Or pass changed_files: ["path/a.rs", "path/b.ts"] when no diff text is available.
Decision Points
| Situation | Action | |
|---|---|---|
| Changing a single function | get_impact with direction: "both" | |
| Reviewing a PR or diff | detect_changes with the diff content | |
| Renaming/removing a public API | get_impact with direction: "upstream", higher depth | |
| Refactoring internals | get_impact with direction: "downstream" |
Output
get_impact returns the blast radius for the target symbol:
| Field | Example / meaning | |
|---|---|---|
| Risk rating | High — one of Low / Medium / High / Critical (interpret via step 3) | |
| Upstream | Transitive dependents (callers/importers) within depth hops — what breaks if the target changes | |
| Downstream | Transitive dependencies — what the target relies on |
detect_changes returns the set of symbols affected by the supplied diff / changed_files, plus the affected processes (execution flows).
Common Mistakes
| Mistake | Reality | |
|---|---|---|
Passing symbol_id or name | Required param is `target` | |
Omitting repo_id | Both repo_id and target are required | |
Defaulting depth to 3 | API default is 5 |