strata-graphify

name	strata:graphify
disable-model-invocation	true
description	Rebuild the code map so functions/classes show up in Obsidian's graph alongside decisions and domain notes. Use when the user says "rebuild the code graph", "the graph is stale", "update the code map after the refactor", or when /strata:review flags the graph as stale. Command-only — run it explicitly as /strata:graphify.

strata:graphify

Orchestration wrapper. Doesn't bundle Graphify, shells out to whatever graphify is on PATH (install separately: pip install graphifyy).

What it does

The orchestrator runs two steps in sequence:

1. Build the graph. Runs graphify update . (AST-only, no LLM, no network) which produces graphify-out/graph.json with nodes and edges for every function / class / module Graphify can see.

2. Wire it into the vault. Reads the freshly-produced graph.json and writes one markdown note per node into <vault>/<repo>/graphify/, with [[wikilinks]] for each edge. This step is local and mechanical, no LLM, no API key, no network. It's Strata's own implementation of Graphify's --obsidian flag, designed to work without an LLM key.

After both steps, Obsidian's graph view shows one continuous knowledge graph: a decision note that wikilinks [[MedicationService]] visually connects to the Graphify-generated note for that class.

How

# Default — incremental graphify update + vault wiring
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify

# Skip the vault wiring (graph.json still produced)
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --no-obsidian

# Full rebuild instead of incremental (slower, deterministic)
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --rebuild

# Status only — print graph age + size, no build
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --status

# Semantic-edge mode (uses Graphify's LLM path).
# Costs tokens AND sends file content to an external LLM API.
# DO NOT use for regulated content.
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --deep

Resulting vault layout

~/StrataVault/<repo>/
├── decisions/                  # ADRs (Strata-managed)
├── domain/                     # vocabulary (Strata-managed)
├── pr-context/                 # per-branch notes (Strata-managed)
├── lessons/                    # retrospectives (Strata-managed)
├── procedural/                 # recipes (Strata-managed)
└── graphify/                   # per-function / class / module nodes
                                 (regenerated by /strata:graphify)

The graphify/ subfolder is regenerable from graph.json on demand, treat it as build output. Point Obsidian at the vault root and use path:graphify (filter to code nodes only) or -path:graphify (hide them) when navigating the graph.

Role tagging

Each generated note carries a graphify/<role> tag in addition to the generic graphify/code umbrella tag. Roles are derived from path + filename conventions:

Tag	Matches
graphify/test	tests/, __tests__/, *Tests.cs, *.test.ts, *.spec.ts, *_test.py, …
graphify/route	routes/, pages/ files (TanStack, Next.js, SvelteKit, Astro)
graphify/component	components/ or PascalCase .tsx/.jsx/.vue/.svelte
graphify/hook	useFoo.ts(x) React-hook convention
graphify/service	*Service.cs/.ts or under services/
graphify/controller	*Controller.cs/.ts or under controllers/
graphify/repository	*Repository.cs/.ts, *Repo.cs, *Dao.cs
graphify/model	models/, entities/, types/, *Types.cs, *.types.ts, …
graphify/util	utils/, lib/, helpers/, *Utils.cs, *.utils.ts
graphify/code	everything else (umbrella + fallback)

Open Obsidian's graph view → Groups → add a search for each tag (e.g. tag:#graphify/service) with its own colour. The result is a visually distinct dependency map instead of a uniform blob.

Monorepo package tagging

On monorepo layouts, each note also carries a graphify/pkg/<name> tag and a package: frontmatter field. The package is detected from the file's path: if it lives under <category>/<pkg>/... where <category> is one of apps, packages, services, web, libs, gateways, integrations, clients, or servers, then <pkg> is its package.

Examples:

• web/billing/src/routes/index.tsx → pkg: billing
• integrations/legacy-crm/src/Client/Foo.cs → pkg: legacy-crm
• gateways/checkout/tests/Bar.cs → pkg: checkout

Files outside that structure (root-level scripts, shared utilities) get no package tag. In Obsidian's graph view, add one Group per major package (tag:#graphify/pkg/billing, etc.) to colour each package's cluster distinctly. Combined with role tagging, this gives you a two-axis view of the codebase: which package something belongs to, and what shape of thing it is within that package.

When to invoke

• First time: bootstrap the graph for the repo.
• After major refactors (new modules, renames).
• When /strata:review flags the graph as stale.
• Before a session that needs code-structure context (god nodes etc.).

Result

After running, Strata's SessionStart primer shows updated node + edge counts and the top god nodes. The code_graph_status MCP tool returns the fresh summary. The wikilink-to-code bridge (internal, surfaced via recall at layer 2) cross-links decisions referencing code symbols back to their graphify nodes: even via unresolved wikilinks, it resolves [[MedicationService]] to graphify:MedicationService against graph.json.