For a normal user, enabling MemHooks should be simple. You are not expected to hand-curate MEMHOOKS.md files as the project evolves.
cargo install memhooksFor Hermes/Hermes Desktop, also install the pre-LLM adapter as described in hooks/hermes/README.md.
Inside an Agent Skill environment:
/memhooks init
Direct CLI equivalent:
memhooks init /path/to/projectInitialization creates a root MEMHOOKS.md using schema: memhooks/v2 at the canonical project root.
A minimal hook is conceptually:
---
schema: memhooks/v2
inherits: true
---
# MemHooks
Recall prior decisions, constraints, failures, fixes, rejected approaches, and
unresolved issues concerning this project before substantive changes.After initialization, the normal lifecycle is automatic:
agent works in project area
↓
runtime reports explicit touched paths / agent learns semantic cue
↓
memhooks event / memhooks note
↓
YAML frontmatter is atomically maintained
↓
future agent enters that area
↓
reference resolver reads the same frontmatter
↓
relevant memory is recalled before substantive work
There is no separate Markdown-body JSON note database in v0.6.0. The writer and resolver share one structured data model.
The human user does not need to decide how many local hooks exist, how long they should be, or how individual retrieval questions are phrased. Those are agent/runtime maintenance concerns.
memhooks validate --all
memhooks explain backend/auth
memhooks explain backend/auth --role reviewer
memhooks explain backend/auth --format jsonexplain --format json includes the complete resolved adapter handoff, including source-attributed Markdown guidance.
A clean validation prints:
MemHooks validation passed with no diagnostics.
A typo in the target path is an error rather than a misleading empty success.
MemHooks does not store memories itself. The active runtime translates the resolved routing plan into the configured memory backend.
Provider-native controls remain namespaced:
backends:
mem0:
filters:
user_id: project-agent
top_k: 8
hindsight:
bank: project-memory
memory_types: [experience]Normal users should generally configure provider selection through the host runtime rather than manually inserting provider internals into every hook.
Provider references:
Inside Git, the nearest Git root is a hard boundary unless the host explicitly supplies a containing MEMHOOKS_ROOT. A hook in your home directory cannot silently capture maintenance writes for an uninitialized repository below it.
Continue with Agent integration. It covers the canonical resolver/maintainer APIs, bounded retrieval, provider namespaces, atomic maintenance, and trust boundaries that runtimes should handle on the user's behalf.