RPG-ZeroRepo: A Repository Planning Graph as Agent Memory

The failure mode RPG-ZeroRepo is aimed at

The README states the problem directly: coding agents lose repository-level context across long tasks, requirements drift, architecture decisions disappear, and edits miss hidden dependencies. That is a specific complaint about the shape of agent memory, not about model capability. Agents are described as strong at local edits but weak when repository-level work requires durable context, because requirements, architecture, implementation progress and dependencies have to stay aligned across many steps. Chat history and file search are the two mechanisms the project contrasts itself against. Chat history is ordered but lossy and gets truncated; file search is exhaustive but has no notion of which file matters for the current requirement. Neither carries a decision forward. The audience implied by the repository layout is engineers already running Claude Code or GitHub Copilot on real repositories, plus researchers who want the ZeroRepo forward pipeline (requirements to RPG to repository) or the RPG-Encoder reverse pipeline (repository to RPG). The topics listed on the repository include agent, llm, memory, software-engineering and workflow, which matches that reading.

What a Repository Planning Graph actually holds

The README describes the RPG as a workspace in which requirements, features, architecture and files stay connected. The comparison table names the entities that move through it: requirements, features, architecture, files, and dependencies between them. That is the mechanism. A plan is not a document that the agent reads once; it is a node set the agent can query by requirement, by feature, or by file, and edits are planned by walking the affected nodes and their dependency edges first. CoderMind exposes this workspace through three interfaces according to the README: CLI setup via cmind init, slash commands inside the coding agent, and MCP graph tools. The named MCP tools are search_rpg, explore_rpg and get_node_detail. Those three verbs map onto the workflow claims: search finds nodes by content, explore traverses the graph from a starting node, and get_node_detail returns the full record for one node. The README also lists a fourth tool name that is truncated in the supplied text, so treat the tool list as at least those three. The reverse direction matters as much as the forward one. RPG-Encoder takes an existing repository and produces an RPG, which is what makes the approach usable on code you did not generate with it.

Installing cmind-cli and initializing a workspace

The README gives the install as a uv tool install from a git subdirectory, followed by a health check:

uv tool install cmind-cli --from "git+https://github.com/microsoft/RPG-ZeroRepo.git#subdirectory=CoderMind" cmind check

For an existing repository the documented flow is to change into the repository, run cmind init . --encode, and then invoke a slash command from inside the agent:

cd your-existing-repo cmind init . --encode /cmind.rpg_edit "Add rate limiting to all API endpoints"

The --encode flag is what triggers the repository-to-RPG direction on an existing codebase. For a new project the flow is cmind init my-project, then a sequence of slash commands the README shows as /cmind.feature_spec, then /cmind.feature_build, /cmind.feature_refactor and finally /cmind.code_gen. The README presents that chain with an ellipsis between feature_refactor and code_gen, so the middle steps are not enumerated in the material I have; CoderMind/docs/commands.md is the file to read for the full list. Configuration is documented separately in CoderMind/docs/configuration.md, and the CLI surface in CoderMind/docs/cli-reference.md. The repository also ships a CoderMind Guide at CoderMind/README.md and translations into Simplified Chinese, Japanese, Korean and Hindi.

ZeroRepo, RPG-Encoder and the EpiCoder feature tree

The repository is not only the CoderMind tool. It contains research code for both directions of the pipeline. ZeroRepo implements requirements to RPG to repository, described in the repository as the forward pipeline, and the pipeline documentation at docs/zerorepo-pipeline.md covers Phase 1, Phase 2 and Phase 3 along with checkpoint files and configuration. RPG-Encoder lives under zerorepo/rpg_encoder/ and implements repository to RPG, the reverse direction, and has its own README in that directory. RepoCraft, under repocraft/, is a benchmark with its own README. Separately, the project open-sourced an EpiCoder Feature Tree on Hugging Face as a dataset, described as providing structured knowledge for repository planning in ZeroRepo. That dataset is a real dependency of the forward pipeline rather than an optional extra, which is worth knowing before you assume ZeroRepo runs from the repository alone. The checkpoint-file detail also tells you the forward pipeline is staged and restartable, which fits the framing of long-horizon generation: you can stop after a phase rather than regenerate everything.

Where the approach costs you

The first limitation is stated by the project itself, indirectly. CoderMind is built for Claude Code and GitHub Copilot. The README does not describe adapters for other agents, so if your team runs a different harness, the slash-command layer is not available to you and you would be working against the MCP tools or the CLI directly. The second is that the graph is a maintained artifact. cmind init . --encode creates a workspace in your repository, and the README's own framing is that the RPG is reusable across tasks, which only holds if it is kept current. Nothing in the supplied material describes automatic invalidation when code changes outside the agent, so a stale RPG is a plausible failure mode: the agent plans an edit against a node whose file has already moved. The third is scale. Encoding an entire repository into a graph is a preprocessing step with a cost proportional to repository size, and the README gives no guidance on repository size limits or on what happens when encoding is incomplete. The fourth is that this is a research repository with a tool attached. The release history shows cmind-v0.1.10, cmind-v0.1.9 and cmind-v0.1.8 within roughly a month, which is rapid iteration on a 0.1.x line. The documented install pulls from a git subdirectory rather than a stable package index path, so a version you install today is tied to a commit.

How this differs from plain agent file search

The obvious alternative is what most teams do now: let the agent grep and read files, and keep the plan in the conversation or in a markdown file the agent re-reads. That approach has no dependency model. When the agent edits a function, nothing tells it which other files call that function except another search, and the search returns matches rather than a ranked set of affected nodes. CoderMind's claim is that edits are planned through affected RPG nodes and dependencies, which is a different retrieval primitive: traversal from a known node rather than text matching across the tree. A second alternative is a conventional architecture document or ADR set kept in the repository. That is durable and reviewable, and it is cheaper to maintain than a graph. What it lacks is executability: the agent cannot query it by node, and it does not connect a requirement to the files that implement it. If your repository already has accurate ADRs and your agent tasks are small, the graph adds a maintenance surface without replacing anything you actually needed.

Maintenance, licensing and release cadence

The license is MIT, stated in the repository metadata and in the README badge. MIT is permissive and places few obligations beyond retaining the notice, but the repository also references an external dataset on Hugging Face (the EpiCoder Feature Tree) and two arXiv papers; the licence on the dataset and on any model weights you attach to the pipeline is a separate question from the code licence, and this article is not legal advice. Check those terms yourself if you plan to ship anything built with the forward pipeline. On maintenance: the last push recorded is 2026-08-24, and the three most recent releases are all CoderMind template releases on the 0.1.x line, dated 2026-06-26, 2026-06-29 and 2026-07-22. That suggests active work concentrated on CoderMind rather than on the research modules, though the release list I have only covers cmind-v0.1.8 through cmind-v0.1.10, so I cannot say how often zerorepo or repocraft change. Upgrade cost is the practical concern: because installation is from a git subdirectory, moving to a newer CoderMind means reinstalling the tool, and any RPG workspace you have already encoded may or may not be forward-compatible with the new version. The material does not state a migration path, so pin the subdirectory to a tag if you need reproducibility.

Editorial conclusion

Adopt CoderMind if your agent work spans many files and multiple sessions and you can afford to keep an RPG workspace in the repository; skip it if your tasks are single-file edits, since the graph is overhead you will pay for on every task. Before committing, run cmind check after the uv tool install, confirm the CLI version matches the cmind-v0.1.10 release, and read CoderMind/docs/configuration.md to see which model endpoints the pipeline expects. Verify that cmind init . --encode produces a workspace your reviewers are willing to keep in version control.

Official sources

1. Issues
2. License: MIT
3. microsoft/RPG-ZeroRepo on GitHub
4. README
5. Releases