context

Context stack loop

Run these phases in order. Skip a phase only when its prerequisite is absent and the fallback says to skip.

1. Orient from committed project context

Read these first, if present:

1. CLAUDE.md or AGENTS.md — agent rules and registered skills.
2. .red/CONTEXT.md — canonical domain glossary.
3. .red/adr/ — architectural decisions, newest relevant ADRs first.
4. .red/CONTEXT-MAP.md — monorepo context routing, if present.

Do not ask the user to repeat information that is already present in those files. If the glossary is missing a term you must use in the answer or plan, add or propose the term through the owning workflow (/start for domain/ADR updates) instead of inventing private vocabulary in chat.

2. Recall prior memory before re-deriving

If memory is configured here (a plugins.memory block in .red/config.yaml, or the legacy .red/memory/config.json), run a targeted recall before deep investigation:

node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" recall "<topic terms>"

Use the configured Memory mode automatically. In graph mode, recall is neighborhood-expanded and supersede-aware; in markdown-only mode, it searches notes. Treat hits as historical claims: cite them internally, then verify against the current worktree before relying on them.

Fallback: if Memory is absent, unbuilt, uninitialized, markdown-only when graph is needed, or failing, continue with ordinary repo reads. Memory is an optimization, not a hard dependency of dev.

3. Refresh structural graph only when explicitly useful

Use graph indexing for large or unfamiliar codebases, impact analysis, onboarding, or repeated work across sessions:

node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" ingest . --root .

Only run this when Memory is initialized in graph mode. Do not run it from read-only skills such as /zoom-out; for those, recommend the command instead. Re-run after large refactors or before a long /afk wave if the graph is stale.

4. Zoom out before drilling in

Use /zoom-out semantics for map-first understanding:

• Start with modules/layers and ownership boundaries.
• Then explain relationships, critical paths, risks/gaps, and optional impact.
• Use Memory graph neighbors/paths only as evidence to interpret, never as raw dumps.
• Verify graph evidence against files before making claims.

For a concrete bug or feature, produce a short orientation map before reading leaf files. This mirrors the Understand-Anything / graphify lesson: the graph is valuable when it teaches how pieces fit together, not when it merely shows complexity.

5. Use the LLM Wiki for durable project knowledge

If .red/agents/wiki.md and .red/wiki/ exist, use /wiki query <question> for compiled knowledge and /wiki ingest <source> for durable external or internal sources.

Rules:

• Read .red/agents/wiki.md before any wiki operation.
• Keep .red/wiki/ gitignored; do not commit raw/private wiki state.
• File back only durable syntheses that would be painful to re-derive.
• Keep source pages, concept/entity pages, contradictions, and index/log current.

Fallback: if the wiki is not initialized and the project would benefit from compounding research/docs memory, recommend /wiki-init with the target domain.

6. Capture only durable learning

After a non-trivial investigation, store one fact per durable lesson:

node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" store "<decision, gotcha, or why-note>"

Store durable operational decisions, root causes, and gotchas. Do not store secrets, Personal facts, biographical details, durable human preferences, transient progress, issue numbers, PR numbers, commit SHAs, or "task done" logs that will be stale in a week. Route human-facing context to Brain with brain capture. If the learning is procedural and reusable, update or create a skill instead of storing it as memory.

7. Use token-efficient terminal surfaces

For noisy development commands, prefer RTK when it is installed and exact raw output is not required:

rtk git status
rtk git diff
rtk vitest run <test-file>
rtk tsc -p tsconfig.json --noEmit

Use raw commands when exact stdout/stderr is the behavior under test, when a filter may hide debugging evidence, or when resolving low-level git conflicts. If an assistant hook already rewrites commands to RTK, let it; otherwise call rtk explicitly.

8. Check self-improvement signals

When Skill telemetry is enabled, inspect it before curating:

node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" status skills --root .
node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" curate skills --root .

memory curate skills is report-only. Mutating workflow stays in /curate, which archives only Curatable skills after explicit approval and can restore them. Never auto-delete skills.

9. Report the context posture

Before moving into implementation, summarize:

• Committed context read: files/ADRs consulted.
• Memory posture: absent / markdown-only / graph ready / graph stale / recall hits used.
• Wiki posture: absent / queried / updated.
• Codebase map: key modules and edges relevant to the task.
• Self-improvement posture: no action / store facts / update skill / run curator.
• Token posture: RTK/hook active / RTK unavailable / raw output required.

Keep this summary concise. The goal is to prove the agent is grounded, not to dump every artifact.

Hard rules

• Do not let graph or memory output outrank the current worktree.
• Do not dump raw nodes, edges, recall hits, or path listings as the final answer; interpret them into project terms.
• Do not write Memory/Wiki/Skill state from a read-only analysis unless the user asked for that side effect.
• Do not commit .red/wiki/, .red/memory/graph.rdb*, generated graph exports, or private memory notes unless the project explicitly made them committable.
• Prefer one focused context refresh over repeated broad searches.
• Prefer RTK-wrapped terminal commands for noisy dev operations unless exact raw output is required.