/slm-graph

name: slm-graph
description: >
  Index and query a codebase as a structural graph — build the code graph, trace blast radius of a
  change, find callers/callees/inheritors, semantic code search by meaning, assemble PR review
  context, and detect what changed since last index. Use when the user asks how code connects, what
  breaks if X changes, what calls a function, what a class inherits from, how to navigate an
  unfamiliar codebase, or to understand risk before editing.
when_to_use: |
  - what calls X
  - what breaks if I change Y
  - what does Z inherit from
  - find code that handles authentication
  - impact analysis before editing
  - code navigation in unfamiliar repos
  - blast radius before a PR
  - pre-commit change detection
allowed-tools: build_code_graph, query_graph, get_blast_radius, semantic_search_code, get_review_context, detect_changes, Bash(slm:*)

slm-graph — Code Intelligence Skill

Index any repo as a code knowledge graph and answer structural questions about it: callers, callees, impact radius, semantic search, and review context. These tools are not in the default tool set: they need `slm tools set code` (or `whole`); see "Tool set requirement" below.

**Prerequisite rule:** every tool except `build_code_graph` self-guards — if the graph is not built it returns `{"success": false, "error": "Code graph not built. Run build_code_graph first."}`. Always index first.

---

Tool Reference

1. `build_code_graph` — index a repository

build_code_graph(
    repo_path: str,
    languages: str = "",
    exclude_patterns: str = "",
) -> {success, files_parsed, nodes, edges, flows, communities, duration_ms}

Parses all supported source files, extracts functions/classes/imports, builds the call graph, detects execution flows, and identifies code communities. Replaces any previous index for the same repo.

• `repo_path` — absolute path to the repository root. Must exist and sit under your home directory; a path outside it is refused with `Invalid repo_path`.
• `languages` — comma-separated language filter, e.g. `"python,typescript"`. Empty string = index all supported languages.
• `exclude_patterns` — comma-separated glob patterns to exclude, e.g. `"**/node_modules/**,**/.venv/**"`. Empty = no exclusions.

When to (re)build:

• Before using any other graph tool for the first time on a repo.
• After significant changes to the codebase (pull, merge, large refactor).
• When `detect_changes` or `query_graph` returns stale/unexpected results.
• Rebuild is safe and idempotent — it replaces the previous index atomically per file.

# Index the full repo
build_code_graph(repo_path="/abs/path/to/myrepo")

# Index only Python, skip tests and generated code
build_code_graph(
    repo_path="/abs/path/to/myrepo",
    languages="python",
    exclude_patterns="**/tests/**,**/generated/**"
)

---

2. `query_graph` — traverse relationships

query_graph(
    pattern: str,
    target: str = "",
    limit: int = 20,
) -> {success, pattern, target, results: [{qualified_name, kind, file_path, name}]}

Query the graph for structural relationships. `pattern` is required and must be one of the eight valid values below. `target` is a qualified name, partial name, or node ID — matched with exact-then-LIKE fallback.

Valid patterns:

| pattern | returns | |---|---| | `callers_of` | functions/methods that call `target` | | `callees_of` | functions/methods that `target` calls | | `imports_of` | modules/symbols that `target` imports | | `imported_by` | who imports `target` | | `tests_for` | test nodes associated with `target` | | `inherits_from` | base classes of `target` | | `inherited_by` | subclasses of `target` | | `contains` | symbols defined inside `target` (e.g. methods in a class) |

# Who calls the auth handler?
query_graph(pattern="callers_of", target="authenticate_user")

# What does the payment processor import?
query_graph(pattern="imports_of", target="PaymentProcessor", limit=30)

# What classes inherit from BaseModel?
query_graph(pattern="inherited_by", target="BaseModel")

---

3. `get_blast_radius` — impact analysis

get_blast_radius(
    changed_files: str,
    max_depth: int = 2,
    max_nodes: int = 500,
) -> {success, changed_nodes, impacted_nodes, impacted_files, edges, depth_reached, truncated}

Computes the full impact radius for one or more changed files using bidirectional BFS (callers and callees). Returns every node and file reachable within `max_depth` hops. Use this before editing to understand risk surface.

• `changed_files` — comma-separated file paths relative to the repo root, e.g. `"src/auth/handler.py,src/auth/models.py"`.
• `max_depth` — BFS depth. Default 2. Increase to 3–4 for deep call chains; lower to 1 for a quick first-degree check.
• `max_nodes` — caps the result set. If `truncated=true` in the response, the real blast radius is larger.

# What breaks if I change the auth handler?
get_blast_radius(changed_files="src/auth/handler.py")

# Deeper analysis across two files
get_blast_radius(
    changed_files="src/payments/gateway.py,src/payments/models.py",
    max_depth=3,
    max_nodes=200
)

If `truncated` is `true`, narrow the scope with `max_nodes` or reduce `max_depth` to get a reliable result.

---

4. `semantic_search_code` — find code by meaning

semantic_search_code(
    query: str,
    kind: str = "",
    limit: int = 20,
) -> {success, results: [{qualified_name, kind, file_path, score, line_start, name}]}

Hybrid FTS5 + vector search over all indexed code entities. Use when you know what the code *does* but not what it's *called*.

• `query` — natural language description, e.g. `"retry logic for HTTP requests"` or `"parse JWT token from header"`.
• `kind` — optional filter: `"Function"`, `"Class"`, `"File"`, or `"Test"`. Empty = all kinds. Case-insensitive match in the engine.
• `limit` — max results. Default 20.

Results include a `score` field (higher = more relevant).