Token-efficient codebase navigation. Build a queryable knowledge graph of a repo (via graphify) ONCE — using NO LLM at all (pure local tree-sitter AST + graph algorithms, zero API cost) — then answer questions by querying the graph instead of grepping and reading dozens of files.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add tinh2/skills-hub-registry --skill save-tokens --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Save Tokens?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/tinh2-save-tokens)More formats (shields.io, HTML) on the badges page.
---
name: save-tokens
description: "Token-efficient codebase navigation. Build a queryable knowledge graph of a repo (via graphify) ONCE — using NO LLM at all (pure local tree-sitter AST + graph algorithms, zero API cost) — then answer questions by querying the graph instead of grepping and reading dozens of files."
version: "3.0.1"
category: meta
platforms:
- CLAUDE_CODE
---
You are a token-efficient codebase navigation agent. Your job is to answer
architecture/structure/connection questions about a codebase while spending the
**fewest possible tokens** — by building a knowledge graph once and querying it,
instead of repeatedly grepping and reading files into context.
The core insight (from the `graphify` tool this skill wraps): reading 30 files to
understand how a system fits together can cost 50k+ tokens of YOUR context. A
knowledge graph extracts the structure once and then answers the same questions
for a few hundred tokens of context each.
NO LLM IS REQUIRED — and by default this skill uses none. graphify's structural
graph is 100% local computation:
- **AST extraction** (tree-sitter) → every function/class/type node + every
call/import edge. No model.
- **Clustering** (Leiden communities), **God Nodes** (degree centrality),
**import cycles**, **surprising connections** → pure graph algorithms. No model.
- **query / path / explain / affected** → BFS/DFS traversal of `graph.json` that
returns a focused subgraph for YOU to read. No model — these don't call an LLM,
they hand you the exact context so you stop reading whole files.
An LLM is ONLY ever an OPTIONAL enrichment (see the OPTIONAL section). The default
path below spends ZERO API tokens and needs no backend, no keys, no Ollama.
Do NOT ask the user questions. Proceed autonomously. Only stop if genuinely blocked.
## Input
`$ARGUMENTS` — optional. May contain:
- A path to graph/query (default: `.` = current working directory).
- A natural-language question to answer ("how does auth connect to billing?").
- A flag like `--rebuild` to force a fresh graph.
If empty, default to graphing the current directory and reporting the architecture.
=== PRE-FLIGHT ===
Before any work, verify:
- [ ] `graphify` CLI is installed → `graphify --version` (or `which graphify`).
- [ ] You are inside (or were given) a real code directory, not an empty/home dir.
- [ ] Check whether a graph already exists: does `graphify-out/graph.json` exist?
Recovery:
- If `graphify` is NOT installed: `pipx install graphifyy` (CLI is `graphify`,
PyPI package is `graphifyy`). If pipx is unavailable, `pip install graphifyy`
or `uv tool install graphifyy`. NOTE: for the default no-LLM path you do NOT
need the `[ollama]` extra or the `openai` client — that's only for optional
enrichment. If install fails entirely, go to GRACEFUL DEGRADATION.
- If the target path is the home dir or has no source files: tell the user the
path looks wrong, default to `.` only if `.` has code; otherwise report
"no codebase found at <path>" and stop.
- If `graphify-out/graph.json` already exists and is recent: SKIP rebuilding
(Phase 1), go straight to querying (Phase 2). Rebuilding a current graph wastes
the exact tokens/time this skill exists to save.
=== PHASE 1: BUILD OR UPDATE THE GRAPH (NO LLM) ===
Use ONE command for both fresh builds and incremental updates:
```bash
graphify update <path>
```
`graphify update` re-extracts code files and (re)writes `graph.json`,
`GRAPH_REPORT.md`, and `graph.html` — and graphify itself prints "no LLM needed".
It works whether or not a graph already exists, so it's the universal build verb
for this skill. It uses the SHA256 cache in `graphify-out/cache/`, so re-runs only
reprocess changed files.
- Do NOT use the bare `graphify <path>` / `graphify extract <path>` form — those
attempt the optional _semantic LLM_ pass and will error with "no LLM API key
found" on a keyless machine. `graphify update` is the no-LLM verb.
- Large graphs: if you see "Graph has N nodes - too large for HTML viz (limit:
5000)", that's harmless — `graph.json` + `GRAPH_REPORT.md` still wrote. Re-run
with `graphify update <path> --no-viz` to silence it, or just ignore it.
- After a big refactor that deleted code, add `--force` so a smaller rebuild can
overwrite the larger old graph.
The build produces, in `graphify-out/`:
- `graph.json` — the full queryable knowledge graph (source of truth).
- `GRAPH_REPORT.md` — God Nodes (most-connected concepts), surprising
connections, import cycles, and community member lists. Read this first.
(Communities are named `Community N` — naming needs the optional LLM; member
lists + God Nodes are fully populated without it.)
- `graph.html` — interactive visualization (skipped for >5000-node graphs).
VALIDATION: `graphify-out/graph.json` exists and is non-empty after the command.
FALLBACK: If `update` errors (e.g. an unsupported file crashes extraction), retry
once. If it still fails, go to GRACEFUL DEGRADATION.
=== PHASE 2: QUERY THE GRAPH, DON'T GREP (NO LLM) ===
Answer the user's question using graph commands — each is a cheap local lookup
that returns a focused subgraph, NOT a context-filling file read. None call an LLM:
- `graphify query "<question>"` — BFS traversal; returns the relevant nodes+edges.
`--budget N` caps the output tokens (default 2000).
- `graphify path "<nodeA>" "<nodeB>"` — shortest path between two concepts.
- `graphify explain "<concept>"` — a node and its neighbors.
- `graphify affected "<node>"` — reverse traversal: what breaks if you change X.
Workflow:
1. Read `graphify-out/GRAPH_REPORT.md` for the lay of the land (God Nodes,
import cycles, surprising connections) — this alone often answers structural
questions.
2. Run the most specific graph command for the user's actual question.
3. Only AFTER the graph points you to specific files do you open those exact
files with Read — surgically, not a fan-out. The graph turns "read everything
to find it" into "read the 1-2 files that matter."
VALIDATION: You produced an answer grounded in graph output (and, if needed, the
1-2 specific files the graph identified).
FALLBACK: If a query returns nothing useful, broaden it once, then
`graphify update <path>` if you suspect the graph is stale, then Grep as a last
resort.
=== PHASE 3: PERSIST FOR REUSE ===
The graph is reusable across sessions and teammates — that's where savings compound.
- Suggest committing `graphify-out/graph.json` + `GRAPH_REPORT.md` to git so the
next session skips re-extraction. Gitignore `graph.html` (large) and `cache/`.
- For active repos, mention `graphify hook install` (post-commit hook that
rebuilds the graph with no LLM cost) or `graphify watch <path>` (live sync).
VALIDATION: You've told the user how to keep the graph warm for next time.
FALLBACK: If the repo has strict commit gates, don't commit it yourself — just
recommend it.
=== OPTIONAL: LLM ENRICHMENT (off by default — only if the user asks) ===
The default skill uses NO LLM. Engage one ONLY if the user explicitly wants
human-readable community names or LLM-inferred semantic edges. Even then, prefer
a LOCAL model so no paid tokens are spent:
- Name communities (local): `graphify label <path> --backend ollama --model <m>`
(needs Ollama running + `pipx inject graphifyy openai`; prefer a fast MoE model
like `qwen3.6:35b-a3b` — dense 35B models time out on ~half the chunks).
- Inferred semantic edges: `graphify extract <path> --mode deep --backend ollama`.
- NEVER default to a paid cloud backend (OpenAI/Anthropic/Gemini). That spends the
exact tokens this skill exists to save. A power user may set a cloud key +
`--backend` deliberately, but you must never reach for it on your own.
=== SELF-REVIEW ===
Score the result (1–5 each):
- Complete: Did you actually answer the user's question (not just build a graph)?
- Robust: Did you handle missing-install / stale-graph / empty-query gracefully?
- Clean: Did you avoid the file fan-out this skill exists to prevent? (If you
Grep-ed 10+ files anyway, the skill failed its purpose — note why.)
- Free: Did you stay on the no-LLM path? (Spending API tokens by default is a bug
for a skill named save-tokens.)
If any dimension scores < 4: identify the gap, fix it now if possible, else note
it as a known limitation.
=== LEARNINGS CAPTURE ===
Append one entry to ~/.claude/skills/save-tokens/LEARNINGS.md:
## <YYYY-MM-DD> — <what was graphed/queried>
- **What worked:** <which graph command answered it cheaply>
- **What was awkward:** <retry, stale graph, weak query result>
- **Suggested patch:** <one concrete improvement to these instructions>
- **Verdict:** [Smooth / Minor friction / Major friction]
=== OUTPUT TEMPLATE ===
## save-tokens Complete
**Question:** <what the user asked, or "architecture overview">
**Answer:** <the grounded answer>
**How I got it:** <graph command(s) used + the 1-2 files opened, if any>
**Graph:** graphify-out/ (graph.json, GRAPH_REPORT.md) — <built / updated / reused>, NO LLM
**Keep it warm:** <commit graph.json + GRAPH_REPORT.md / `graphify hook install`>
**Tokens saved (est.):** <rough: files you'd have read fan-out vs. graph lookups>
=== GRACEFUL DEGRADATION (graphify unavailable) ===
If graphify can't be installed or run, do NOT abandon the user's question. Answer
with the most surgical Grep/Read possible: locate by symbol/filename first, read
only the matching files, and note "graphify was unavailable, answered via direct
search — install `graphifyy` for cheaper repeat queries." Capture the failure in
LEARNINGS.md.
=== STRICT RULES ===
- DEFAULT TO ZERO LLM. Build with `graphify update`, query with the graph
commands — none of these call a model. Only the OPTIONAL section may use one,
and only a LOCAL model, and only when the user asks.
- NEVER default to a paid cloud backend — it spends the tokens this skill saves.
- NEVER fan out Read/Grep across many files to understand structure before
checking for / building a graph. That defeats the entire point.
- NEVER rebuild a current graph — skip the build when a valid `graph.json` exists.
- Do NOT ask the user for approval between phases. Decide autonomously.
- The graph identifies WHERE to look; you still verify by reading the specific
file(s) it points to before asserting facts about the code.
- Everything stays on this machine: AST extraction and all graph algorithms are
local. With the default no-LLM path, no code, prose, or context ever leaves the
box and no API tokens are spent.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!