Problem
Today, "use memtrace first" for code discovery/edits lives entirely in SKILL.md prose (e.g. the memtrace-first skill's "Iron Law" and "Red Flags" sections). That has two gaps:
- No mechanical enforcement. There's no Claude Code hook (
PreToolUse or otherwise) that intercepts Grep/Glob/Read/rg and redirects to the memtrace MCP tools. Whether memtrace gets used is entirely a matter of Claude re-deciding, on every single tool call, that the skill's guidance still applies.
- No durable, always-loaded instruction. The skill only enters context when it's explicitly invoked (
/memtrace-first) or auto-selected by the harness's skill-matching. In a long session, once the skill's content scrolls out of context (or gets summarized away), there's nothiafter invoking the skill, not for the rest of the session.
What graphify does differently
graphify (a comparable knowledge-graph-for-code tool) solves the exact same problem two ways, both via graphify claude install:
- It writes a
## graphify section directly into the project's CLAUDE.md. Since CLAUDE.md is loaded into every session unconditionally (not gated on skill-matching or explicit invocation), the instruction to "check the graph before answering codebase questions, rebuild it after code changes" survives context compaction and doesn't depend on the skill being re-triggered.
- Separately,
graphify hook install adds a git post-commit hook that auto-rebuilds the graph after every commit, so index freshness doesn't depend on the agent remembering to re-index either.write
Neither of these requires a Claude Code PreToolUse hook — they just make the "always do this" instruction structurally hard to forget, instead of relying on an agent re-deriving intent to check list_indexed_repositories at the top of a session and then re-motivating itself for every subsequent action.
Proposal
- A
memtrace claude install (or equivalent) command that writes a short, durable routing directive into the project's CLAUDE.md — something like "this repo is indexed in memtrace; use memtrace tools (find_symbol, find_code, get_symbol_context, get_impact, etc.) before Grep/Glob/Read for code discovery, and before editing/refactoring existing code" — with a corresponding uninstall to remove it.
- Document (or ship) a reference
PreToolUse hook config for Claude Code that can nudge/deny Grep/Glob/rg-shaped Bash calls when the current repo is confirmed indexed in memtrace (via list_indexed_repositories), so consistency doesn't rely purely on prompt-level cooperation. Even a soft warning-and-continue hook would help close the gap versus silent fallback to grep.
- Optionally, tie index freshness to a git hook (
memtrace hook install) analogous to graphify's post-commit rebuild, for repos not running memtrace start's file watcher continuously.
Why this matters
The current setup makes "consistent memtrace use" something the user has to keep re-asking for per session (as in "make sure /memtrace-first applies to all subsequent actions, not just the first"), rather than something configured once per project. A CLAUDE.md-writing install command would make that durable the same way it already is for graphify.
Problem
Today, "use memtrace first" for code discovery/edits lives entirely in
SKILL.mdprose (e.g. thememtrace-firstskill's "Iron Law" and "Red Flags" sections). That has two gaps:PreToolUseor otherwise) that interceptsGrep/Glob/Read/rgand redirects to the memtrace MCP tools. Whether memtrace gets used is entirely a matter of Claude re-deciding, on every single tool call, that the skill's guidance still applies./memtrace-first) or auto-selected by the harness's skill-matching. In a long session, once the skill's content scrolls out of context (or gets summarized away), there's nothiafter invoking the skill, not for the rest of the session.What graphify does differently
graphify (a comparable knowledge-graph-for-code tool) solves the exact same problem two ways, both via
graphify claude install:## graphifysection directly into the project'sCLAUDE.md. SinceCLAUDE.mdis loaded into every session unconditionally (not gated on skill-matching or explicit invocation), the instruction to "check the graph before answering codebase questions, rebuild it after code changes" survives context compaction and doesn't depend on the skill being re-triggered.graphify hook installadds a git post-commit hook that auto-rebuilds the graph after every commit, so index freshness doesn't depend on the agent remembering to re-index either.writeNeither of these requires a Claude Code
PreToolUsehook — they just make the "always do this" instruction structurally hard to forget, instead of relying on an agent re-deriving intent to checklist_indexed_repositoriesat the top of a session and then re-motivating itself for every subsequent action.Proposal
memtrace claude install(or equivalent) command that writes a short, durable routing directive into the project'sCLAUDE.md— something like "this repo is indexed in memtrace; use memtrace tools (find_symbol,find_code,get_symbol_context,get_impact, etc.) before Grep/Glob/Read for code discovery, and before editing/refactoring existing code" — with a correspondinguninstallto remove it.PreToolUsehook config for Claude Code that can nudge/denyGrep/Glob/rg-shapedBashcalls when the current repo is confirmed indexed in memtrace (vialist_indexed_repositories), so consistency doesn't rely purely on prompt-level cooperation. Even a soft warning-and-continue hook would help close the gap versus silent fallback to grep.memtrace hook install) analogous to graphify's post-commit rebuild, for repos not runningmemtrace start's file watcher continuously.Why this matters
The current setup makes "consistent memtrace use" something the user has to keep re-asking for per session (as in "make sure /memtrace-first applies to all subsequent actions, not just the first"), rather than something configured once per project. A
CLAUDE.md-writing install command would make that durable the same way it already is for graphify.