Monton vs markdown files in git

Many people who work with coding agents keep their plans, specs and notes as markdown files in the repo, next to the code. It's a good default. The agent already reads and writes files, you have every version in git, and you set up nothing else.

It stops working as well once other people need to take part. A product manager, a designer or a client won't clone a repo to read a spec. People send feedback in chat, and someone pastes it back into the terminal. Pull requests work well for reviewing code, but a plan that changes ten times a day doesn't fit one pull request, and people comment there on lines of a diff rather than on the current text. When several people's agents work on the same plan, they either take turns on one branch, or each works on their own branch and someone merges the branches.

What Monton keeps from git

Monton docs are markdown files in folders, and we keep a version of every change, as git does. Each agent write is its own version with the agent's name, the person it works for, and a message the agent writes to say what changed and why. You can compare any two versions, read a doc as it was, and restore it.

Your coding agent can keep working with files. With the monton command line tool, it clones a workspace to a folder, edits the files with its usual tools, and runs monton push -m "what changed and why". We merge each push with what people typed in the browser since the agent's last monton pull. If both changed the same lines, we refuse the push and change nothing. When the agent runs monton pull, we mark the conflict in the file with git-style markers, and the agent resolves it and pushes again.

What Monton adds

People read and edit the docs in a browser or on a phone, with no repo access. They select a passage and comment on it. Agents check their Monton inbox for mentions, replies in their threads and new threads on docs they changed last, make the change each comment asks for, and reply in the thread. Everyone sees the current text and the conversation about it in one place.

Each agent you connect gets its own name, such as "Ana's Claude" or "Ana's ChatGPT". You can share one folder or doc with someone as an editor, a commenter or a viewer, and they can connect their own agents to it. To show a doc to someone without an account, an editor can turn on a public link, and anyone with the link reads the doc without signing in. Agents in chat apps, such as Claude on claude.ai and ChatGPT, can work on the same docs as your coding agent, with no repo.

An agent can also write an HTML page, such as a dashboard or an interactive plan, and people see it as a web page and comment on it.

What to keep in the repo

Keep files that the code depends on, or that should change in the same commit as the code: AGENTS.md and other instructions for agents, READMEs, API docs, and architecture notes that reviewers check with each change.

Move to Monton the docs that people outside the repo need to read or answer: plans, specs before you build them, research, decision docs, release notes for review, and anything a non-developer comments on. When a plan is final, your agent can copy it into the repo.

Try it

Connect Claude Code with one command and set up the CLI: Use Monton with Claude Code. Monton is free while it's in beta.