SuperAPI AI Directory

memini

Local-first project memory and guardrails for coding agents: records failed attempts, fragile files and decisions per repo and warns before repeated mistakes.

Open website

About this tool

memini is a local-first, guardrail-enforced persistent project memory system designed for AI coding agents. Its core goal is to keep agents from "repeating the same mistakes." Address:https://github.com/lumayapartners/memini。

[Purpose] AI coding agents are stateless: every session starts over as if it has amnesia. An agent that broke the build on Monday may try the exact same edit again on Thursday. memini builds persistent memory for each repository, recording failed attempts, fragile files, decisions, and deployment rules, and forcibly pushes relevant warnings when an agent is about to repeat a mistake. It is not a notebook that an agent can choose to read, but a guardrail that cannot be skipped.

[Memory storage and reviewability] Memories are stored in the .memini/ folder inside the repository, containing a local SQLite index and human-readable Markdown views that can be committed for PR review. Local-first: nothing leaves your machine.

[Guardrail enforcement mechanism] When an agent tries to edit a file with recorded risk, the edit is intercepted before it happens, and the recorded lesson is injected. Example warning: [WARNING] Editing vercel.json broke the build (recorded 2026-07-03) — Tried changing buildCommand; deploy failed. Actual fix: move checkout server-side and set VITE_STRIPE_USE_SERVER=true. Severity levels: at the warn level, the agent gets one warning per session, after which it may continue; at the block level, the edit is always rejected until a human archives that memory. At session startup, a summary of the most important memories is injected (prioritized by severity, limited by token budget).

[MCP tools] Let agents record what they learn, including: remember_failed_attempt, remember_fragile_file, remember_decision, end_session_summary, as well as recall_project_context and check_before_editing.

[Git-aware staleness] Memories hash the files they reference; pm stale flags memories whose evidence has changed, and stale memories stop triggering guardrails until revalidated.

[Quickstart] The materials only give "Quickstart (90 seconds)" and do not provide the specific command content. For Cursor, Windsurf, and other MCP clients: the materials mention pm install-mcp --write cursor is for Cursor.

[Execution chain] memini covers multiple stages: Before editing—edits to guarded files are blocked before they happen; block rejects, warn prompts the user and includes a recorded history; supported platforms include Claude Code (installed via pm init), Cursor 1.7+ (pm install-mcp --write cursor), GitHub Copilot (CLI, cloud coding agent, and VS Code agent mode preview, pm install-copilot). Before commit—install the git pre-commit guardrail via pm init (or pm install-hooks --git) to block any commit that touches block-severity files, regardless of which IDE or agent made the edit; fail-open, can be bypassed with git commit --no-verify. Advisory—any MCP client can use the check_before_editing / recall_project_context tools, plus always-active Cursor rules that guide agents to use them.

[Keeping memory useful long-term] Automatic capture: the Claude Code session-end hook prompts the agent to record persistent lessons when a session actually changed files; idle sessions stay silent. Usefulness tracking: every guardrail trigger is counted, and pm stats shows which memories are working and which have never triggered. pm review: flags near-duplicate content, contradictory guardrails on the same file, and dormant guardrails that were created long ago but have never triggered; all are local heuristics, no LLM used, and you decide whether to keep, merge, or archive. Git-aware staleness: memories hash the files they reference, and when the code changes the memory is flagged and stops triggering until reverified (pm stale / pm verify). Memory types include: decision, failed_attempt, fragile_file, architecture, deployment, client_preference, session_summary.

[Scope and cross-repository sharing] Some lessons are project-specific, while others apply to all repositories on the machine for the same organization or client. memini provides three scopes. Every repository under the workspace folder (including thosecreated later) automatically gets these guardrails. Resolution walks up the directory tree, similar to .gitconfig or ESLint config. Workspace/user-level file guardrails are matched via glob (vercel.json matches vercel.json in any repository, and config/**/*.yml also works), and broader-scope memories only trigger after human verification; agents can only propose memories to the project scope, so a prompt-injected agent cannot plant rules that propagate across repositories. pm doctor shows the currently active scopes.

[Design principles] Enforcement rather than advice: the MCP memory tool is optional for agents, but hooks are not; even if an agent never thinks to check memory, the guardrail path still works. Human-readable, PR-able: each memory is rendered as Markdown under .memini/, and the team reviews it like any other change. Git-linked evidence: memories record the branch, commit, and file hash at the time of their creation, so claims are verifiable and staleness is detectable. Local-first: SQLite + Markdown inside the repository, no account, no cloud, no telemetry, and secrets are automatically redacted from the memory body before storage. Cross-tool: the core is the CLI + files, and Claude Code hooks and MCP are lightweight adapters.

[Security and limitations] Local-first by design: no server, no account, no telemetry; secrets are automatically redacted before storage, file references are confined to the repository, and injected memory text has a size limit and is framed as data. See SECURITY.md for the full threat model, including honest statements of limitations (guardrails intercept editing tools, not arbitrary shell; warn is advisory, block is not).

[Version status] In early v0.1. Team synchronization (shared memory and review workflows across an entire team) is on the roadmap. The material does not provide specific pricing, rates, or the scope of platform support, and these are not yet available.