# GitMir – an open source IDE that fixes your Claude development > Source: > Published: 2026-08-25 00:01:19+00:00 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. THE WHOLE MECHANISM, IN SIX MOVES CODE MODEL IMPACT DECISIONS AGENT VERIFY Your agent stays yours — Claude Code, Codex or Cursor. What changes is what it knows before it starts. WANT TO RUN IT YOURSELF? 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. 01 Install it One command. Needs Node 22.18 or newer. ``` curl -fsSL https://ide.gitmir.com/install.sh | sh powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://ide.gitmir.com/install.ps1 | iex" ``` Node 22.18+ · installs to ~/.gitmir/local Node 22.18+ · installs to %USERPROFILE%\.gitmir\local Works in the PowerShell that ships with Windows (5.1), in PowerShell 7 and in Command Prompt. Nothing needs administrator rights: the command goes into your user PATH, not the system one. If your organisation blocks running a downloaded script, use the clone route instead — it does the same thing with no installer. The installer adds itself to your PATH. Open a new terminal before the next command — a shell reads its PATH when it starts, so the window you just used does not know about it yet. The installer adds itself to your PATH. Open a new terminal before the next command — Windows applies the change to new windows only. THEN RUNgitmir In a new terminal · on your machine · opens localhost:4599 · no account 02 Connect your agent This is the step that hands over the skills. gitmir mcp add One command, once, for every project. It writes a line into your Claude config and nothing else — no service, no port, no account. OR, FROM A CLONE Cloned the repo instead? The gitmir command comes with the installer. From a clone, run this instead — the path is the folder you cloned into: claude mcp add -s user gitmir -- node "/path/to/gitmir-local/mcp.ts" claude mcp add -s user gitmir -- node "C:\path\to\gitmir-local\mcp.ts" The path is the folder you cloned into, with backslashes: C:\Users\you\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 — run it once from the wrong place and your editor opens the project and finds no tools. Then restart your editor. A client reads its MCP config only at startup, and skipping this is the single most common reason people think it did not connect. Twelve procedures, as slash commands — building the model, planning work that carries its own checks, running the queue, auditing the spec against the code, porting a stack at parity. Fourteen tools the agent calls on its own: what an object is, what breaks if it changes, what a task would touch, where the code already disagrees with the spec, what needs a person right now. Nothing to paste. The procedures are tools, not text. The agent reaches for one when it needs it. You know it worked when claude mcp list shows gitmir as connected, and typing / in your editor lists the skills. 03 Say: set this project up with GitMir The agent does the setup itself, because the procedures are tools it can call. Adds the folder to your dashboard Creates the task queue — todo → in progress → verify → done Reads the repository once and writes the object context into .gitmir/model/ It does not ask you to paste anything. It calls the setup tool, sees there is no model yet, fetches the model-building procedure and follows it against your code. What comes out is the product in its own terms — areas, business objects, functions, endpoints, screens, events, journeys, 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. 04 Ask it something only the model knows What breaks if I change the order status? Which business rules govern cancellation? What should be verified for this task? Where does the code already not do what the spec says? What needs a person here right now? 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. Your dashboard's first screen now shows what those answers cost: how much was served, and how big the files are that the objects in them live in. Not sure it connected? An MCP server has no screen, which makes a broken setup hard to tell from a working one. gitmir check Starts the server exactly as your editor does, asks it what this product is, and prints the answer. From a clone: node mcp-check.ts . model inside the checkout. WHY EACH STEP EXISTS GitMir moves product understanding before execution. Nine steps, and each one exists because of what it costs to skip it. STEPWHAT HAPPENSWHAT IT PREVENTS 01CODEThe system you already run — the only description of the product that cannot be out of date.— 02PRODUCT MODELObjects, rules, states and dependencies, written into your repository as readable files.Prevents reconstructing the same understanding for every change. 03CHANGEThe request, read against that model rather than against a description of it.— 04IMPACTWhat this actually affects, including the areas the ticket never named.Prevents late discovery — the most expensive kind. 05DECISIONSThe product questions that have to be resolved before anybody writes code.Prevents coding against unresolved business logic. 06AGENT CONTEXTThe approved slice, projected into Claude Code, Codex or Cursor before execution.Prevents an agent executing quickly against the wrong premises. 07EXECUTIONYour agent, your machine, your subscription.— 08VERIFYThe resulting product state, compared against the intent that was approved.Prevents “done in code, wrong in product”. 09EVIDENCEWhat was intended, what changed and what was checked — kept, so the next change starts from it.— WHAT THE COMMAND INSTALLS What the engine gives you. You stop explaining the productIt is on one map — areas, objects, rules, states, screens, events — read out of your code. Every question has a screenWhat it does, why it works that way, what a change costs, who owns it, where the model is guessing. You see what a change breaks before it is writtenBoth directions: what depends on this, and what this depends on. The surprises come out before the demoEvery place the code and the written rules disagree, with file and line. Rework gets a numberWhat a change cost to make, and what it cost to finish after it was first shown. Your agent stops re-reading the repositorySixteen MCP tools and twelve procedures it asks instead. Done means verifiedA task closes when its own checks pass, not when the code is written. Draw it, then see what was builtElements and links on the map become tasks; afterwards the screen shows how much of it is real. You know what needs you todayAreas with no owner, findings with no decision, tasks running long, a model behind the code. It works before the code existsThe model is built from what you intend to build, and the code is written against it. OR, WITHOUT THE INSTALLER Nothing here needs the installer. It clones the repository, checks your Node and puts gitmir on your PATH — you can do those three things yourself. Same engine, same skills, same MCP. What you lose is gitmir as a command, so use the clone line in step 02 to connect your agent. What have you got? 01gitmir-modelA shared model of what this product does, read from the real code and linked by stable ids. Everyone works from what the product IS, not what they remember. Where the code and the written rules disagree, spec-audit records it rather than picking a winner. 02task-plannerSplits the goal into small tasks. Each carries its slice of the model and the checks that prove it — nothing is done on faith. 03task-runnerWorks the queue to empty on its own: todo → in progress → verify → done. Runs the checks for real, and writes the fix task when one fails. Run them in this order. Each one finishes before the next begins. In your editor: type / and pick the skill by name What you end up looking at The real thing, running. It walks its own script: the product map, the domains, a checkout end to end, the events, a domain opened into its own diagram, the lifecycle inside it — then an update arrives and it shows what that update touches, what it can break, and whether it knows enough. gitmir / product-model / livePLAYS ITSELF Loading product model The same render the local app draws from your code What the team sees Everything runs on your machine. You choose how much of it is copied to the site for other people. Nothing Your machines talk to each other. Nothing is stored, nobody sees the project from outside. The default The tasks The queue: what each task is and whether it is waiting, running or done. Enough for a client to follow along. Tasks and the map Plus a copy of the product map — and a link you can send to anyone. The local app is the engine. The web layer turns it into team and organizational intelligence. GitMir runs close to the code, on developer machines. The browser layer carries the selected context, tasks, decisions and execution state to the rest of the team — and a Team or Enterprise implementation extends that same foundation with your integrations, your rules and the views each role needs. Not a place to watch from: a place the work is read from. LOCAL GITMIRcode · model · agent · MCP GITMIR CONNECTthe machines and the people, one room GITMIR TEAMyour services, your pipeline, your rules GITMIR ENTERPRISEthe answers your organization pays for