Context Engineering, graphify, and the Knowledge Graph
Scoped subgraphs instead of full-repo reads — how nexus keeps context small and accurate.
Module Overview
This is the Dev Track's equivalent of Module 4. The core program teaches "relevant beats abundant" and manual session management. nexus automates the first half of that discipline with a knowledge graph: instead of you deciding which files are relevant, graphify or codegraph tells each EPAV skill exactly what's in the blast radius. You still own the second half — session lifecycle and isolation.
| At a glance | |
|---|---|
| Covers | Which EPAV skill calls which graph command; the PostToolUse auto-update hook; session lifecycle across an epic; the 5 reviewer subagents as isolation |
| When it runs | Continuously — this is the discipline underneath long EPAV sessions |
| Builds on | Core program Module 4 (Context Engineering & Management) |
| Leads into | Dev 5, where these sessions produce real code |
What you'll produce
A working knowledge graph that stays current automatically, a session-per-epic habit that avoids poisoning across unrelated tasks, and at least one reviewer subagent invoked for an isolated second opinion.
Which Skill Calls Which Graph Command
| EPAV step | graphify backend | codegraph backend | Neither built |
|---|---|---|---|
| /evaluate | graphify query "<task>" | codegraph explore "<task>" | Suggests /graphify ., continues without it |
| /plan | graphify path "<a>" "<b>" | codegraph impact <symbol> | Notes the check was unavailable; best-effort review |
| /validate | graphify query "<what was built>" | codegraph explore "<what was built>" | Skips, notes it in VALIDATE COMPLETE |
The window is a whiteboard, the graph is the index
Module 4's whiteboard analogy still holds — the context window fills and old notes get erased. What changes is how you decide what goes on the whiteboard in the first place: instead of guessing which files are related, graphify path or codegraph impact tells /plan exactly what references the files it's about to touch, so only the actually-relevant blast radius gets loaded.
Auto-Update: One Less Thing to Manage
With graphify, .claude/settings.json wires a PostToolUse hook that runs graphify update . --force after every file edit — the graph never goes stale mid-session, and you never run a manual sync step. With codegraph, its own background sync daemon does the same job; nexus doesn't scaffold a hook for it because it doesn't need one. Either way, by the time /apply finishes, the graph /validate queries next already reflects the change.
{
"hooks": {
"PostToolUse": [
{ "matcher": ".*", "hooks": [
{ "type": "command", "command": "graphify update . --force 2>/dev/null || true" }
]}
]
}
}
OpenCode note — same job, different mechanism
OpenCode has no PostToolUse hook concept. Instead, nexus init . --tool opencode scaffolds .opencode/plugins/graphify.js, which hooks OpenCode's tool.execute.after event to run the same graphify update . after every edit. Functionally identical outcome — the graph never goes stale — just wired through OpenCode's plugin system instead of Claude Code's settings.json. Like the Claude Code hook, it's only scaffolded if you picked graphify at nexus init; codegraph wires and syncs itself regardless of which tool you're on.
Pick one backend
nexus doctor warns if it finds graphs from both graphify and codegraph built in the same project. Two graphs answering the same blast-radius question can disagree — that's a context-poisoning risk in its own right. Choose one at nexus init time.
Session Lifecycle Across an Epic
The core program's continue / compact / start-fresh decision guide applies directly to a day of EPAV work. The natural session boundary in nexus is the Dev Task: one /evaluate → /plan → /apply → /validate cycle per CSV row, same as Module 5's "one task per session" discipline.
| Situation | Move |
|---|---|
| Finished TASK-019, starting TASK-020 in the same epic | Compact — summarize decisions, keep the epic's architecture context |
| Finished the epic, moving to a different one | Start fresh — unrelated context, avoid carrying over decisions that don't apply |
Corrected the same /plan mistake three times | Start fresh, and add the missing rule (Dev 3, Dev 6) before continuing |
Reviewer Subagents as Isolation
nexus init scaffolds five reviewer subagents into .claude/agents/ (or .opencode/agents/ on OpenCode) — code-reviewer, database-reviewer, deployment-reviewer, monitoring-reviewer, performance-reviewer. Each runs in its own isolated context window, exactly the mechanism Module 4 teaches: invoke one mid-EPAV-session for a focused second opinion without polluting the main session with review noise.
# Mid-implementation, want a security pass without derailing the EPAV session: @code-reviewer review src/services/order-notification.ts
The reviewer returns a structured, read-only report (a JSON findings block with severity, file, line, and suggested fix) and never edits files itself — your main EPAV session continues unaffected.
OpenCode note
@-mention invocation works the same way in OpenCode. The one difference: nexus init strips Claude-specific frontmatter fields (tools, model) from each agent file when it copies them into .opencode/agents/, since OpenCode configures tool access and model selection differently. The system prompt — the part that actually defines what the reviewer does — is untouched.
Self-Check
- I know which graph command each EPAV skill calls, and what happens when neither backend is built.
- I understand why the PostToolUse hook (or codegraph's sync daemon) means I never manually re-sync the graph.
- I treat one Dev Task as one session, and compact or start fresh at task and epic boundaries.
- I've invoked at least one reviewer subagent for an isolated second opinion mid-session.
- I know why running both graphify and codegraph in the same project is a risk, not a redundancy.