Your agent and Merget

Merget and your coding agent are connected in both directions. One direction commits what the agent does; the other teaches the agent to operate Merget for you. Together they mean a Merget repo mostly takes care of itself: work gets committed without ceremony, and when you do want a version-control operation, you can just ask your agent for it in plain language.

The relationship is two-way

In: committing. Each supported agent (Claude Code, Codex, Cursor, and GitHub Copilot) gets a small Merget plugin. The plugin reports your sessions to the committing daemon as they happen, so your prompts, the agent's actions, and the resulting changes are captured automatically and organized into goals, prompts, and steps. You don't run anything; this is the default behavior described in How Merget works.

Out: operation. Alongside the plugin, Merget installs a skill: a document your agent reads that teaches it to drive Merget itself: check the repo's status, read history, commit when you ask, check out earlier work, and resolve merges. So in a Merget repo, "commit this with a good message," "what was I doing in the auth goal?", or "merge those two goals" are things you can say directly to your agent, and it knows the right commands to run.

What the skill teaches

The short version of what your agent learns:

• The model. Work is organized as Goal -> Prompt -> Step, and the agent is taught what each level means so it can answer history questions accurately. (To the agent and the CLI, a step is called a "subprompt"; see the glossary.)
• Merget is the source of truth. In a Merget repo the agent treats Merget, not Git, as the version control system; it won't reach for Git commands to read or change repo state. See Merget and Git.
• When to commit. Committing is automatic, so the agent is told not to create redundant checkpoints on its own; it commits explicitly only when you ask for a save, checkpoint, or labeled commit.
• How to be careful. Before and after anything that changes state (commit, checkout, merge), the agent checks the repo's status, and it stops to ask you rather than guessing when a request is ambiguous.

Setup, per agent

Plugins install automatically when you install Merget. They install globally, once per user, not per repo - one install covers every Merget repo you work in. To be clear about what's being installed: Merget adds its own plugin to the agents you already have; it never installs the agents themselves (those are separate products you get from their makers; see Supported agents). Because Merget only adds its plugin to the agents it detects, there's one gotcha: if you install a new agent after setup, Merget doesn't know about it yet. Rerun the install and you're covered (see Troubleshooting).

Manual control from the command line:

merget plugins install   # install for all detected agents
merget plugins list      # show installed plugins and detected agents
merget plugins remove    # remove the plugins

install and remove accept --agent to target a specific agent instead of all of them. More in the CLI reference.

Automatic and explicit commits

Day to day you don't think about committing: the committing daemon turns your agent sessions and settled edits into steps on its own. Asking your agent to commit is for the moments you want a deliberate checkpoint with a message you chose: before trying something risky, or to mark a milestone worth finding later. The full picture of when each makes sense is in How Merget works; if you'd rather your own hand edits wait until you commit them, manual commit mode lives in Settings.

Next: Settings | Related: Supported agents | How Merget works | Terminals