Give Your Coding Agents Shared Project Memory With MEX

Agent context dies at the session boundary. One engineer knows why a constraint exists, another has the debugging history, and the agent that found the edge case is gone by tomorrow. MEX, a 2k-star tool, gives that knowledge a durable home inside the repository: readable Markdown files your whole team shares through Git, and a local retrieval layer your agents can query.

Why This Skill Matters

MEX combines two complementary views of a repo. The Wiki explains architecture, conventions, decisions, and patterns in prose people can review; the Code Graph maps symbols and relationships from the implementation into a local SQLite index using bundled Tree-sitter grammars (TypeScript/TSX, JavaScript/JSX, Python, and Rust, with partial C# support). Wiki claims can be grounded to specific graph nodes, and when the code later changes, grounding drift flags the affected explanation for review.

Canonical knowledge is structured Markdown under .mex/, shared by normal commit-push-pull. The indexes are rebuildable local state each teammate keeps in their own checkout. There is no hosted service: the Hub runs on 127.0.0.1, and MEX never pushes, pulls, or commits on its own.

Installation

From the repository root (Node.js 22.5 or newer, SQLite FTS5 in your Node build, and a Git repo):

npx mex-agent@0.8.5 setup

Setup runs a keyboard-driven terminal HUD: pick your tool, and it installs the project instructions plus the official Inbox, Relay, and Statechart skills for the Claude Code or Codex integration you select. When it finishes, review the exact setup-file diff and choose Commit setup. After that, start a fresh agent session and verify it reads the project memory.

Joining a repository that already uses MEX takes three commands instead of setup:

npx mex-agent@0.8.5 graph rebuild
npx mex-agent@0.8.5 wiki rebuild-index
npx mex-agent@0.8.5 hub

Real Workflow: Capture a Decision as Team Memory

You and your agent just worked out why retry handling must be idempotent. Ask the agent to capture it:

• The agent checks existing Wiki records first, then drafts one Inbox proposal — an addition or correction to the relevant knowledge area.
• Publishing writes a Markdown proposal into your checkout for repository review; approval updates the canonical knowledge and keeps the proposal as history.
• A commit and push is what carries it to teammates. The agent never publishes on its own — skill activation is not approval.

The same boundary governs Relays, the handoff record for whoever continues the work next: agents can prepare a draft summarizing what changed, which tests ran, and what remains, but a person reviews and publishes it.

Real Workflow: Explain a Flow With a Statechart

Version 0.8.5's headline feature turns explanations into checked diagrams:

• Invoke /mex-statechart in Claude Code or $mex-statechart in Codex, or just ask your agent to "explain this lifecycle using a state diagram."
• The managed skill uses TLA+ and TLC under the hood and delivers Mermaid in chats that support it.
• Generation stays in scratch space; Review Save shows the exact snapshot files before anything lands in .mex/diagrams/, and sharing remains a separate Git action.

Tips

• Cursor, Windsurf, GitHub Copilot, and OpenCode get instruction anchors but no official MEX skill commands in 0.8 — they read the same .mex/ memory through project instructions.
• mex check runs every deterministic check with no AI and no writes; mex sync fixes what it flags in one interactive agent session.
• There is a standalone path for existing MEX projects: npx skills add mex-memory/mex installs the skills only — the MEX CLI and a configured project are still required, so pick one installer per integration and do not mix them.
• Pseudonymous usage telemetry is on by default; inspect or disable it with mex telemetry inspect / mex telemetry disable.

When Not to Use This

MEX is not a documentation site, a task tracker, or an auth layer — the README's own "What MEX is not" list rules out hosted sync, notifications, RBAC, and Jira-style management. Solo on a throwaway branch? A Wiki nobody else will read is overhead; the README's framing is team memory, with "the next person" sometimes just being you in a new session. And the Code Graph only indexes the languages listed above — a repo outside them gets a Wiki without code-grounded evidence.

See the leaderboard for more skills.