From real code to observable business logic.
GitMir reads the system you already run and writes down what it does — areas, business objects, rules, the states each one moves through. From that it answers what a change would actually affect, hands your coding agent the approved slice before it writes anything, and checks the result against what was agreed.
OPEN SOURCE · RUNS ON YOUR MACHINE · NO ACCOUNT · SOURCE CODE NEVER LEAVES IT
Six moves.
Your agent stays yours.
Claude Code, Codex or Cursor — whichever your team already runs. What changes is not the agent. It is what the agent knows before it starts.
Code
The system you already run — the only description of the product that cannot be out of date.
Model
Objects, rules, states and dependencies, written into your repository as readable files.
Impact
What a change actually affects, including the areas the ticket never named.
Decisions
The product questions that have to be resolved before anybody writes code.
Agent
The approved slice, projected into Claude Code, Codex or Cursor before execution.
Verify
The resulting product state, compared against the intent that was approved.
One command, then the skills do the work.
The engine is open source and runs on your machine. Four moves from nothing to a product model your agent works from.
curl -fsSL https://ide.gitmir.com/install.sh | shNODE 22.18+ · INSTALLS TO ~/.gitmir/local · ADDS ITSELF TO YOUR PATH
The installer adds itself to your PATH, so open a new terminal before the next command — a shell reads its PATH when it starts, and the window you just used does not know about it yet. Then run:
gitmirIN A NEW TERMINAL · ON YOUR MACHINE · OPENS LOCALHOST:4599 · NO ACCOUNT
gitmir mcp addOne command, once, for every project. It writes a line into the agent's config and nothing else — no service, no port, no account. Cloned the repository instead? Run this, with the path to the folder you cloned into:
claude mcp add -s user gitmir -- node "/path/to/gitmir-local/mcp.ts"The -s user scope is not optional: claude mcp add defaults to local, which saves the registration in whatever folder you ran it from — do it once from the wrong place and your editor opens the project and finds no tools. Then restart the editor. A client reads its MCP config only at startup, and skipping that is the single most common reason people think it did not connect.
YOU KNOW IT WORKED WHEN claude mcp list SHOWS GITMIR AS CONNECTED, AND TYPING / IN YOUR EDITOR LISTS THE SKILLS.
The agent does the setup itself, because the procedures are tools it can call. It adds the folder to your dashboard, creates the task queue — todo → in progress → verify → done — and reads the repository once, writing the object context into .gitmir/model/. What comes out is the product in its own terms: areas, business objects, functions, endpoints, screens, events, journeys and lifecycles, linked by stable ids.
YOU KNOW IT WORKED WHEN THE PROJECT APPEARS ON LOCALHOST:4599 WITH A QUEUE, AND THE MODEL SECTION HAS SOMETHING IN IT.
An MCP server has no screen, which makes a broken setup hard to tell from a working one. This starts the server exactly as your editor does, asks it what this product is, and prints the answer:
gitmir checkFROM A CLONE: node mcp-check.ts . model INSIDE THE CHECKOUT.
Product understanding moves in front of execution.
Nine steps, and each one exists because of what it costs to skip it.
| Step | What happens | What it prevents |
|---|---|---|
| 01 · Code | The system you already run. | — |
| 02 · Product model | Objects, rules, states and dependencies, written into your repository as readable files. | Prevents reconstructing the same understanding for every change. |
| 03 · Change | The request, read against that model rather than against a description of it. | — |
| 04 · Impact | What this actually affects, including the areas the ticket never named. | Prevents late discovery — the most expensive kind. |
| 05 · Decisions | The product questions that have to be resolved before anybody writes code. | Prevents coding against unresolved business logic. |
| 06 · Agent context | The approved slice, projected into your coding agent before execution. | Prevents an agent executing quickly against the wrong premises. |
| 07 · Execution | Your agent, your machine, your subscription. | — |
| 08 · Verify | The resulting product state, compared against the intent that was approved. | Prevents “done in code, wrong in product”. |
| 09 · Evidence | What was intended, what changed and what was checked — kept, so the next change starts from it. | — |
The point is not that it answers.
It is where the answer comes from.
Every one of these is walked from the object context, in both directions, and opens with a line saying how fresh that context is. A model older than the code says so.
Answered from objects and their links — not from a search over files, and not from an inference the agent makes privately and differently every time.
Answered from objects and their links — not from a search over files, and not from an inference the agent makes privately and differently every time.
Answered from objects and their links — not from a search over files, and not from an inference the agent makes privately and differently every time.
Answered from objects and their links — not from a search over files, and not from an inference the agent makes privately and differently every time.
Answered from objects and their links — not from a search over files, and not from an inference the agent makes privately and differently every time.