██████╗ ██████╗ █████╗ ██████╗ ██╗ ██╗
██╔════╝ ██╔══██╗██╔══██╗██╔══██╗██║ ██║
██║ ███╗██████╔╝███████║██████╔╝███████║
██║ ██║██╔══██╗██╔══██║██╔═══╝ ██╔══██║
╚██████╔╝██║ ██║██║ ██║██║ ██║ ██║
╚═════╝ ╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═╝ ╚═╝
The live code map
forge keeps a dependency graph of the whole repo — built once, then patched automatically as files change, so your structural context never goes stale. It's a zero-dependency, fully-local synthesis of the three things a code graph is good for:
- god-nodes — the most-depended-on files (highest fan-in); the architectural hotspots to touch with care.
- modules / clusters — the architecture at a glance (which directories form cohesive units, how many communities exist).
- neighbors / impact — who imports a file, and the transitive blast radius of changing it.
- cycles · dead files · orchestrators — dependency cycles (refactor hazards), orphaned files (0 in / 0 out, non-entry), and high-fan-out composition roots.
It updates itself: a SessionStart hook injects a fresh map and triggers a background refresh; the Stop hook patches changed files after every turn (mtime-diff — only changed files are reparsed). You usually read the injected map for free; reach for the CLI when you need a specific answer.
When to use it
- Before editing a shared file — run
impact to see everything that could break.
- Entering an unfamiliar repo — run
map to learn the hotspots and module layout in one call (cheaper and more accurate than grepping around).
- "Where is X / what uses X" —
neighbors gives importers and imports directly.
- It's the structural layer
forge:understand leans on — use the graph first, then read only the files on the path.
Commands
G=~/.claude/skills/forge/scripts/graph.js
node "$G" map # god-nodes + module map for this repo
node "$G" neighbors <file> # direct imports ↑ and importers ↓ of a repo-relative file
node "$G" impact <file> # transitive blast radius — who breaks if this changes
node "$G" stats # files / deps / clusters / last-built
node "$G" refresh # build if missing, else mtime-patch (the hooks do this for you)
Paths are repo-relative with / separators (e.g. src/api/client.ts), exactly as the map prints them.
What it does and doesn't see
- Edges = static imports/requires/includes, resolved to real repo files: JS/TS (
import/require/dynamic-import, relative + index resolution + tsconfig/jsconfig baseUrl/paths aliases like @/…), Python (absolute + relative, incl. nested-package suffix match), C/C++ (#include "…"), Ruby (require_relative), Rust (mod). It respects the repo's .gitignore (single-name dir/file entries) so generated/ignored code isn't counted.
- It does not follow dynamic dispatch / runtime reflection, monorepo workspace-package imports (bare
@scope/pkg → another package), or Go module-path imports. Languages without an extractor yet — Go, Java, Kotlin, PHP, C#, Swift — are counted as files but appear as edgeless nodes. Treat the map as a high-accuracy skeleton, not a completeness proof; confirm a critical call path by reading the code (forge:verify).
- If a deeper symbol-level call graph is available (e.g. CodeGraph MCP via
/codegraph-here), prefer it for precise caller/callee analysis; forge:graph is the always-on, zero-setup baseline.
Freshness
The map is patched after each turn, so during a session it tracks your edits. If you've just made sweeping changes and want certainty before a big query, run node "$G" refresh first. Disable the whole subsystem with FORGE_GRAPH=off.
1---2name: graph3description: Query forge's live, always-fresh code map — a dependency graph of the repo with god-nodes, modules, and neighbors/impact (blast-radius) queries. Use before editing to know what depends on a file, to find the most-depended-on hotspots, to map an unfamiliar codebase's architecture, or whenever you need current structural context instead of guessing.4---56```7 ██████╗ ██████╗ █████╗ ██████╗ ██╗ ██╗8██╔════╝ ██╔══██╗██╔══██╗██╔══██╗██║ ██║9██║ ███╗██████╔╝███████║██████╔╝███████║10██║ ██║██╔══██╗██╔══██║██╔═══╝ ██╔══██║11╚██████╔╝██║ ██║██║ ██║██║ ██║ ██║12 ╚═════╝ ╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═╝ ╚═╝13```1415# The live code map1617forge keeps a **dependency graph of the whole repo** — built once, then patched automatically as files change, so your structural context never goes stale. It's a zero-dependency, fully-local synthesis of the three things a code graph is good for:1819- **god-nodes** — the most-depended-on files (highest fan-in); the architectural hotspots to touch with care.20- **modules / clusters** — the architecture at a glance (which directories form cohesive units, how many communities exist).21- **neighbors / impact** — who imports a file, and the **transitive blast radius** of changing it.22- **cycles · dead files · orchestrators** — dependency cycles (refactor hazards), orphaned files (0 in / 0 out, non-entry), and high-fan-out composition roots.2324It updates itself: a `SessionStart` hook injects a fresh map and triggers a background refresh; the `Stop` hook patches changed files after every turn (mtime-diff — only changed files are reparsed). You usually **read the injected map for free**; reach for the CLI when you need a specific answer.2526## When to use it27- **Before editing a shared file** — run `impact` to see everything that could break.28- **Entering an unfamiliar repo** — run `map` to learn the hotspots and module layout in one call (cheaper and more accurate than grepping around).29- **"Where is X / what uses X"** — `neighbors` gives importers and imports directly.30- It's the structural layer `forge:understand` leans on — use the graph first, then read only the files on the path.3132## Commands33```bash34G=~/.claude/skills/forge/scripts/graph.js35node "$G" map # god-nodes + module map for this repo36node "$G" neighbors <file> # direct imports ↑ and importers ↓ of a repo-relative file37node "$G" impact <file> # transitive blast radius — who breaks if this changes38node "$G" stats # files / deps / clusters / last-built39node "$G" refresh # build if missing, else mtime-patch (the hooks do this for you)40```41Paths are **repo-relative with `/` separators** (e.g. `src/api/client.ts`), exactly as the map prints them.4243## What it does and doesn't see44- **Edges = static imports/requires/includes**, resolved to real repo files: JS/TS (`import`/`require`/dynamic-`import`, relative + index resolution **+ tsconfig/jsconfig `baseUrl`/`paths` aliases like `@/…`**), Python (absolute + relative, incl. nested-package suffix match), C/C++ (`#include "…"`), Ruby (`require_relative`), Rust (`mod`). It respects the repo's `.gitignore` (single-name dir/file entries) so generated/ignored code isn't counted.45- It does **not** follow dynamic dispatch / runtime reflection, monorepo *workspace-package* imports (bare `@scope/pkg` → another package), or Go module-path imports. Languages without an extractor yet — **Go, Java, Kotlin, PHP, C#, Swift** — are counted as files but appear as **edgeless nodes**. Treat the map as a high-accuracy skeleton, not a completeness proof; confirm a critical call path by reading the code (`forge:verify`).46- If a deeper **symbol-level** call graph is available (e.g. CodeGraph MCP via `/codegraph-here`), prefer it for precise caller/callee analysis; forge:graph is the always-on, zero-setup baseline.4748## Freshness49The map is patched after each turn, so during a session it tracks your edits. If you've just made sweeping changes and want certainty before a big query, run `node "$G" refresh` first. Disable the whole subsystem with `FORGE_GRAPH=off`.
vasu-devs