Graphify Usage

Notes and workflow ideas for /graphify — any-input-to-knowledge-graph skill. Vault-wide, not business-specific; consolidated here (Core/AI/Tools) rather than under a single business folder.

Ideas backlog (from 2026-05-13 session)

1. Hook graphify update into session-close

Session-close currently doesn’t run /graphify --update, so the graph goes stale after any session that creates/moves/modifies KB files. Suggested addition: after writing the log and updating _tmp.md, run /graphify <vault-path> --update — it only re-extracts changed files, so cost is low.

2. Drop stale-reference warnings once fixed

When writing task Background sections, stale references found during research get flagged. Once fixed, the warning becomes noise. Pattern: fix immediately, omit the warning from the task file entirely — the task file should describe current truth, not history.

3. `task-prep` auto-generates Background from Graphify

Manual today: graphify query → Claude reads files → Claude writes Background. Could automate: take task filename → BFS query derived from title/keywords → read top 4–5 connected files → auto-write Background. Would cut task prep from ~10 min to ~2 min for well-indexed tasks.

4. Cross-vault indexing

Any business KB not yet graphified has no cross-vault graph path for tasks spanning multiple businesses. Keep all active business KBs indexed and updated for cross-vault context queries.

5. `--wiki` output as agent entry point

--wiki generates graphify-out/wiki/index.md + one article per community — a lower-token orientation path than manual “read these files”: read the wiki index (~1k tokens) to orient on the whole KB, then drill into community articles. Worth evaluating against the current BFS-query approach.

6. Git post-commit hook (`graphify hook install`)

Auto-rebuilds the graph after every commit in a git-backed vault/repo — eliminates remembering to run /graphify --update manually. One-time setup, zero ongoing cost. Install: cd <repo> && graphify hook install.

Including dev repos in the graph

The default graph covers a KB vault only. To connect KB docs to actual source code (components, utilities, scanners), three approaches:

Option A — Symlinks into the vault (recommended for targeted inclusion)

Symlink specific repo directories into the vault; graphify follows symlinks transparently and the AST extractor picks up code files on the next --update (no LLM needed for code — fast, free).

ln -s ~/projects/monorepo/sites/template/src/components/brand  _WorkingOn/refs/brand-components
ln -s ~/projects/monorepo/src/brand/mbr                        _WorkingOn/refs/brand-mbr

Gives direct edges from KB doc nodes (e.g. a component spec) to actual code nodes. Add symlinks per active task, remove when done to keep the graph lean. Tradeoff: symlinks need updating if repo paths change.

Option B — Separate graph per repo, merged on demand

cd ~/projects/monorepo && /graphify .
graphify merge-graphs <kb-graph.json> <repo-graph.json> --out graph-merged.json

Tradeoff: two graphs to maintain, cross-repo edges only exist in the merged output and need manual regeneration. Better for large repos with occasional cross-repo queries.

Option C — Git post-commit hook on the repo

graphify hook install inside the repo keeps its graph perpetually current as a side effect of normal commits (AST-only, no LLM). Pairs with Option B’s merge step for the cross-repo view.

Recommendation

Option A for active task work (surface per task is always small). Option B merge when a full cross-repo picture is needed (tracing a concept from strategy doc → product spec → implementation). Also worth running Option C on any actively-committed repo — one-time setup, zero ongoing cost.

Task type	Symlink target
Brand component work	`sites/template/src/components/brand/`, `src/brand/mbr/`
Rate scanner work	Rate scanner package src dir
Utility work (pdf2md, etc.)	Utility `src/` dir