Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add synaptixs/spine --skill understand-codebasegit clone --depth 1 https://github.com/synaptixs/spineWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/synaptixs/spine/understand-codebase)<a href="https://agentmods.dev/skills/synaptixs/spine/understand-codebase"><img src="https://agentmods.dev/badge/skills/synaptixs/spine/understand-codebase/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/synaptixs/spine/understand-codebase"><img src="https://agentmods.dev/badge/skills/synaptixs/spine/understand-codebase.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00226 | $0.02240 |
| Opus 5.5 | $0.00090 | $0.00896 |
| Sonnet 5.5 | $0.00045 | $0.00448 |
| Haiku 4.5 | $0.00023 | $0.00224 |
Grade A, and why
understand-codebase scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Understand a codebase with Spine
Spine reads a repository's Product Knowledge Graph — a deterministic, no-LLM index of its
modules, types, functions, call sites, and blast radius, with every fact grounded to file:line.
It covers Python, Java, Kotlin, TypeScript, JavaScript, C#, C, C++, Go, Rust, PHP, Perl and SQL.
These MCP tools turn that graph into decisions, not just lookups: what a change breaks, what's
untested, where work lands. They're read-only, need no credentials, and take a local
repo_path (default: the current repository).
Use them before grepping or guessing about an unfamiliar repo — they're faster and more accurate, and they cite their sources.
Which tool for which question
| You want to… | Call |
|---|---|
| get oriented in a repo you don't know | map_repo — languages, components, call-hotspots, test-coverage gaps, prioritized recommendations |
| know what changing a symbol will affect | blast_radius(symbol=…) — direct callers, callers through an interface the symbol implements (interface_callers, each with the via member — they may reach it, not must) + touches (every node one edge away, either direction, any kind — a neighbourhood, not a transitive ripple set), each file:line. A class's callers are the code that creates it; a Java/C# constructor lists them as instantiated_via_type Each match also lists the repo's docs that describe it (docs, via symbol/class/module) — a class with zero callers can still be what twenty pages tell users to call. Callers are the ones the graph can type — read caller_count as a floor; Python calls it could not trace come back apart as unresolved_calls (a hint: check each receiver). |
| understand one symbol | explain_symbol(symbol=…) — kind, location, who calls it (and who calls it through an interface it implements, called_through_interface with the via member; for a Java/C# constructor, who creates its type, instantiated_via_type), what it calls, what it contains Carries the same docs list. Its callers are the ones the graph can type. |
| find where a feature/ticket lands | investigate(title=…, problem=…) — the real symbols to start from |
| pin a bug from a stack trace | localize(trace=…) — resolve each frame to the repo symbol; the likely fault site |
| see what a change could break silently | regression_gaps(symbol=… or trace=…) — blast-radius symbols with no covering test |
| root-cause a bug (hypotheses + fix approach) | root_cause(bug=…) — fault site, ranked hypotheses with evidence, regression surface, fix approach; deterministic (add use_llm=true for richer hypotheses) |
| find which docs describe code (or how documented it is) | docs_for(symbol=…) — the doc pages that mention a symbol; call with no symbol for a doc-coverage summary + top drift. Ingests .md/.rst/.txt/PDF |
| ask any of the above across several repositories | blast_radius, investigate, explain_symbol, regression_gaps, localize, docs_for all take repos=… — pass a .spine/repos.yaml instead of repo_path. regression_gaps then reports uncovered_elsewhere (a change reaching a different service nothing tests); localize says which repo each frame landed in and lists ambiguous_frames; docs_for answers each repo on its own |
| check whether a requirements change is clear before building it | requirements_check(change_path=…, repo_path=…) — the strict gate (problem, users, outcome, every open question answered or deferred to a named owner) and, with a repo, which criteria already name code that exists. Deterministic, no model. Record an answer with requirements_answer(change_path, question, answer | defer_to) (plan scope; recorded as relayed) |
| see or sanity-check the cross-repo topology | pkg_joins(config=…, mode="propose"|"check") — read-only; it never writes a config |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago Changed · +1 lines 5ad14ae87f69
- 10d ago Changed 6026e56f9ec9
- 11d ago Changed · +1 lines · +41 tokens per session b66f8c087483
- 12d ago Changed 3b888baa63fe
- 20d ago Changed 367f79380478
- 23d ago Changed c14eeaf5425b
- 24d ago Changed f2ba3d64767c
- 1mo ago Changed d591bf6348d7
- 1mo ago Changed · +2 lines 1d1cb335256d
- 1mo ago First seen · 101 lines · 185 tokens per session scan A b51280ac4366
understand-codebase is a skill published in the GitHub repository synaptixs/spine (13 stars, last pushed today), licensed MIT. It adds 226 tokens to every session and 2,240 once invoked, about $0.0009 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
taiyi-integration
A project workflow skill for closing a TaiyiForge change and recording it in a CHANGELOG.md file. It checks review results, tests, and the state of the working tree before archiving the change.
taiyi-requirement
A requirements-analysis process that turns a proposed change into a REQUIREMENT.md document. It records user needs, acceptance checks, terminology, triggers, and dependencies, with different levels of detail for different project sizes.
taiyi-change
A TaiyiForge workflow stage for writing a change proposal in CHANGE.md, with checks for scope, risks, success criteria, and related project documents.
taiyi-test
A project workflow skill for verifying an implementation and producing a TEST.md record. TDD means writing a failing test, implementing the change, and then making the test pass; this skill checks that process and other regression cases.
taiyi-ui-design
A design-planning guide for describing how an application's user interface should look and behave. It produces a UI-DESIGN.md document covering layouts, components, interactions, accessibility, and error states.
taiyi-evolve
A workflow skill that compares the implemented code with the frozen design after development and testing. It records architecture changes and proposes updates to DESIGN.md, the document describing the intended system structure.