graft
Graft is an agent that combines finished work from many coding agents into a shared trunk. It updates each change to fit the latest code, runs your checks, and adds the result with a record of what happened.
Install
Install one executable on macOS or Linux. Git must already be available.
curl -fsSL https://graftd.dev/install | bash
graft init
graft doctorRun these commands from the repository root on trunk. graft init finds the repository, signs you in if needed, and writes a policy file for you to review. graft doctor confirms that the setup is ready.
Quick start
Once a feature branch is committed, its agent describes the intended behavior and submits it to Graft. You can follow along or wait for the agent to tell you it landed or needs your input.
graft intent submit- Submit the intent. Run this from the committed feature branch. Review Graft's description of what the branch should do, edit it if needed, then submit.
graft status- Check progress. See whether Graft is working, needs a decision, is waiting for review, or has landed the branch.
Only if Graft asks for human review
Most changes land without human review. Graft pauses only when policy requires approval, usually after rebuilding around a conflict or when the intent asks for review. Your agent should explain the proposed result and ask before it lands.
graft review <branch>- Inspect the proposed result. See the final diff, its checks, and what Graft changed while preparing it.
graft review approve <branch>- Approve and land. Use this only after you understand what will change. Approval and the landing attempt happen together.
graft why <commit>- Explain a landed change. Your agent will usually summarize this. Run it yourself to see the intent, source, checks, review, and decisions kept with the commit.
Why it exists
Sandboxes, worktrees, and separate environments let agents work at the same time without overwriting one another. They do not update finished branches when trunk changes.
Graft does. It keeps submitted work compatible with the latest trunk, runs the repository's checks, and asks a person only when approval or a product decision is needed.
Not a merge queue
Pull requests and merge queues organize completed code, but people still maintain branches, resolve conflicts, and repeat reviews as trunk changes. Graft takes the finished code and its intent, updates the code for the latest trunk, and verifies that exact result.
Graft lands one commit, keeps a record of what changed and why, and leaves no pull request branch to rebase. Human review happens only when policy or a product decision requires it.
What happens when things conflict?
Graft tries the simplest safe fix first. Each step is called a rung.
- Rung 0: Use Git. If the change fits cleanly, no model is needed.
- Rung 1: Replay the commits. If Git can move the branch onto the latest trunk without a conflict, Graft does that. No model is needed.
- Rung 2: Rebuild the change. Graft adapts the code to the latest trunk while preserving the intent.
- Rung 3: Ask a person. If the remaining choice changes product behavior, Graft offers concrete options and continues after the answer.
Every result runs the same checks and agent review. Human approval is added only when policy requires it.
Connect your coding agent
MCP is the connection between your coding agent and Graft. Through it, the agent can submit finished work, follow progress, inspect proposed results, and land changes when policy allows.
Point your agent to graftd.dev/AGENTS.md for the complete operating guide. Approval and product choices you have not delegated still come back to you.
How it works
agents finish in parallel
branch A ─┐
branch B ─┼──▶ Graft
branch C ─┘ │
▼
current trunk + branch A
│
▼
update + run project checks
│
▼
trunk gains commit A
│
▼
repeat B and C on new trunkGraft handles each submitted branch separately. After one lands, it updates the remaining branches for the new trunk before checking and landing the next one.
What happens after you submit
- On submission: Graft saves the committed branch and its intent. It leaves unsubmitted branches alone.
- When trunk or the branch changes: Graft prepares an updated result.
- Before landing: It runs setup, project checks, and agent review in a clean workspace.
- When a person is needed: Graft stops if policy requires approval or the code raises a product choice.
- At landing: Graft confirms trunk has not changed again. If it has, Graft updates and checks the work again.
FAQ
What changes when I use Graft?
Agents keep working in ordinary Git branches. When work is complete, the agent describes what it should do and submits it. Graft updates, checks, and lands the result. It asks you only when policy or a product decision needs you.
Does Graft replace Git?
No. Git remains underneath. Graft handles the work between a finished branch and trunk: keeping it current, checking it, and landing it.
Can I run several coding agents at once?
Yes. Give each agent its own branch and worktree. Graft updates each submitted branch for the same trunk, even as other changes land.
What happens when changes conflict?
Graft tries Git first. If the change no longer fits, Graft rebuilds the smallest change that preserves the intent. A person is asked only when the remaining choice changes product behavior.
How is this different from a merge queue?
A merge queue orders and retests code that is already approved. Graft also updates finished work for the latest trunk, then checks the exact result that will land.
What does Graft check before a change merges?
Every proposed result runs the repository's configured checks and a fresh agent review. Repository policy decides whether a person also needs to approve it.
Can I explain a merge after the branch is gone?
Yes. Graft keeps the explanation with the commit in Git, so the branch and worktree can be gone. graft why shows the intent, source, checks, review, and decisions later.
Do I need to keep Graft open?
No. Graft starts a background process when a command needs it and stops after it has been idle. The next command starts it again.