Maintain Repo-Local Agent Memory with mex
Use mex when coding agents need a versioned project wiki, code graph, routed context, and drift checks instead of rediscovering a repo every session.
npx skills add agentskillexchange/skills --skill maintain-repo-local-agent-memory-with-mex
npx mex-agent setup in the target repository, inspect the generated .mex/ files, run mex graph to build the local code graph, then use mex check and mex sync as part of ongoing agent work.Use mex when an operator wants coding agents to maintain a repo-local, reviewable project memory layer. The workflow maps the codebase, creates a structured Markdown wiki, routes task-relevant context through ROUTER.md, records decisions and patterns, and runs drift checks with commands such as mex graph, mex check, and mex sync.
What this skill actually does
Invoke this instead of relying on normal documentation, one giant instruction file, or a generic memory store when repeated coding-agent sessions need architectural context tied to exact files, symbols, decisions, conventions, and recent work.
The scope boundary is project memory for software repositories: code graph, Markdown wiki, context routing, and drift repair loops. It is not a generic knowledge-base product, chat memory service, or broad framework listing; the operator workflow is setting up and maintaining source-grounded context that agents can reuse during coding work.
Inputs and prerequisites: Node.js 22.5+, npm/npx, Git, a local software repository, and a coding-agent workflow that can read the generated project memory files; optional MCP server mode..
Setup notes: Run npx mex-agent setup in the target repository, inspect the generated .mex/ files, run mex graph to build the local code graph, then use mex check and mex sync as part of ongoing agent work.
Source and verification boundary: use https://mexmemory.com as the canonical reference before running the workflow; keep commands, API calls, CLI usage, and generated outputs reviewable against that upstream source.
Framework fit: publish this as a Multi-Framework workflow only when the operator can invoke the documented toolchain directly, rather than treating the upstream project as a generic product listing.