Ship code

Every other surface in this section gets an agent to do the work. This one is about what happens to the work when it is done: it becomes a pull request, opened under your own GitHub identity, that your team reviews and merges the way it merges everything else. The agent proposes the change in a sandbox; the decision to land it stays with a person, on GitHub, where your review already lives.

This page is the how-to for that last step. For the operating model behind it, why the agent stops at a proposal and a human approves, read reviewable autonomy.

From a sandbox to a pull request

An agent's work lives in its sandbox until someone ships it. Shipping is a skill, create-pr, that you run as the last step of a Flow or launch as an action on a plan. When it runs, the platform pushes the work to a fresh branch named for you and the moment, pr/your-id/timestamp, opens a pull request against the repository's default branch, and links the PR back to the plan it came from so the work and the proposal stay connected.

Create-pr is one of the operations that always ship: like verifying and reviewing, it always runs the skill that ships for it, so a binding can offer it at a status but cannot swap out the step that opens your pull requests. That is deliberate. The step that puts a change in front of your team is the one step a binding should never be able to reroute.

The pull request is a normal GitHub pull request. It has a branch, a base, a title, a body listing what changed, and a link you can open on GitHub. Nothing about it is special to Disco Parrot once it exists, which is the point: it drops into the review your team already runs.

Two ways create-pr runs

Create-pr reaches a pull request from either of the two places agent work runs, and the result is the same PR.

As the last step of a Flow, it ships work that earlier steps built and verified in the same run. The implement step wrote the change, the verify step checked it, and create-pr opens the PR on what they produced, usually behind a checkpoint so a person signs off before it leaves the sandbox. This is the path for work that runs end to end, and it is the one the worked example below follows.

As an action on a plan, it ships work that is already sitting in the sandbox, without a Flow around it. You open the plan's action launcher, pick create-pr, and it opens the PR on the current state of the working tree. This is the path for a change you made in chat or a single skill run, where there was no multi-step Flow to end on.

Either way the branch is named the same, the PR opens under your identity, and it links back to the plan. What differs is only what came before it: a Flow's worth of checked steps, or a working tree you are ready to ship as it stands.

The pull request opens under your identity

A pull request an agent opens is yours. Once you have connected your GitHub account under Integrations, the platform opens the PR with that identity, so the work is attributed to you and not to a bot, and your team reviews a teammate's pull request rather than a machine's. The credential that authorizes it is held server-side and never reaches the agent; the platform opens the PR on your behalf, the same way it calls any provider for you. If no GitHub account or repository is connected yet, create-pr stops with a clear message instead of opening anything, so a missing connection is an answer up front rather than a half-finished pull request.

This is what makes agent work fit a real team. A pull request from a shared bot account is one your reviewers learn to skim. A pull request under the name of the person who set the work in motion gets reviewed like any other, because the accountability sits where it always did, with a named teammate.

What a good pull request from an agent looks like

The fear an engineer brings to agent-written code is a giant, shapeless diff with a one-line description, the kind of PR a reviewer bounces on sight. A pull request from Disco Parrot is built to be the opposite, because the work that produced it was scoped before a line was written.

A PR opens from a plan, and the plan is the scope. The implement step worked against one plan's worth of change, the verify step checked it against the standard your team encoded in its verify skill, and only then did create-pr open the request. So the diff a reviewer opens is the size of one plan, with a title and a body that say what it does, a link back to the plan it came from, and a verify step's worth of checking already behind it.

It reviews like a teammate's PR because that is what it is built to be: one unit of work, attributed to a person, scoped to a plan, checked before it opened. That is the whole point of shipping agent work as an ordinary pull request instead of a pile of changes you take or leave whole.

See what changed

You do not have to take the agent's word for what it did. Two surfaces show you the change.

Before any PR exists, the agent's work sits in the sandbox as ordinary edits to a working tree, and the code workspace on the initiative is where you read them: the changed files, grouped the way git groups them, each with a side-by-side diff. It is read-only, a view of exactly what the agent touched, so you can look the work over before you decide to ship it and well before it reaches a reviewer. When the diff view is not enough and you want to be inside the running container, you can open the sandbox in your IDE to inspect the files in place or reproduce the change by hand. A plan whose work has not been shipped shows no pull request at all; the PR badge appears only once create-pr has run, which is how you tell at a glance which work is still in the sandbox and which is in front of the team.

After the PR opens, the in-app pull request view shows the diff for the PR itself, alongside the review comments your team leaves on GitHub. You read the change and the conversation about it in one place, without leaving the plan it belongs to. Once the PR is merged or closed on GitHub, that view reflects it and the conversation goes read-only, so the in-app picture always matches the PR's real state.

GitHub stays the merge authority

The pull request opens from Disco Parrot, and from there GitHub is in charge. Your team reviews the PR and merges it on GitHub, with whatever branch protection, required checks, and approvals you already enforce. Disco Parrot does not merge your pull requests for you and does not write back to them: it never posts a comment, an approval, or a merge to the GitHub PR on the agent's behalf. The flow of review is one way, from GitHub into the platform. The architecture behind this, the branch lineage, the two merge paths, and how the platform tracks the change by commit and webhook, is on the code and Git model.

Your reviewers' comments are read in and shown on the in-app pull request view next to the diff they are about, so the change and the conversation about it sit in one place. What the platform does with a reviewer's comment, turn it into more agent work, is the next section.

Review comments become more work, not a thread

A reviewer asks for a change. On most teams that change is a back-and-forth: a comment, a reply, a new commit, another comment. Disco Parrot keeps the first half of that loop exactly where it is, on GitHub, and turns the second half into agent work.

When a human review comment lands on the PR, the in-app PR view shows it with a Fix this button. Click it and an agent picks the comment up in a fresh sandbox, makes the change it asks for, and pushes it as new commits on the same pull request. The fix arrives the way the original change did, as a diff your team reviews and merges on GitHub. The PR thread carries the request; the commits carry the answer. The full story of how a comment becomes a finding, how the agent rechecks its own fix, and what happens when it does not converge is the PR review loop.

This is a deliberate line. The agent answers review by doing more work, never by editing the conversation about it. It does not resolve a comment, mark a thread done, post a reply, or approve its own change. The record of what was asked stays human and stays on GitHub, and the only thing the agent adds is code. A reviewer reading the PR a week later sees the comments their team left and the commits that answered them, with nothing the agent wrote into the discussion in between.

The agent answers review the only way it ships anything: with code a person reviews. It carries the conversation into the app and never into the merge. That line, proposal by the agent and decision by a person, is the whole of reviewable autonomy, and this page is where it ends, on a pull request your team merges on GitHub.

The plan keeps up with the pull request

You do not have to tell the plan what happened to its PR. When the pull request moves on GitHub, the platform hears it through a webhook and updates the work to match. On a plan, a merged PR is recorded as merged, so the plan carries a Merged pull-request badge and anyone looking can see its work has shipped. On a bug, a merged PR moves the bug to fixed and records the PR as what fixed it. A PR closed without merging moves the link back rather than leaving the work marked as shipped. The pull-request state you see on the work is the state of the PR itself, kept current without anyone updating it by hand.

A pull request, end to end

Maya has the CSV download button plan ready to ship. The implement and verify steps of the CSV Export Flow have already run; the work sits in the sandbox, and the verify step reported it ready. The last step is create-pr, and the run pauses at the checkpoint in front of it. Maya reads the verify summary, types "Headers match the spec, ship it," and approves.

The platform pushes the work to a fresh branch, pr/maya/1706-2042, and opens a pull request against orcette/insights under Maya's GitHub identity. The PR carries a real diff, a title, and a body listing what changed, and it links back to the plan. To Tom, who reviews it, it is a teammate's pull request, not a bot's, so he reviews it the way he reviews Maya's other work.

Tom leaves one comment on GitHub: the new button should respect the existing column filter. The platform reads the comment in and shows it on the in-app PR view, where Maya clicks Fix this. An agent picks the comment up in a fresh sandbox, makes the change, and pushes it as new commits on the same PR. Tom re-reviews, approves on GitHub, and merges.

Nobody updates the plan by hand. Tom's merge fires the webhook from the section above, and the CSV download button plan flips to a Merged badge on its own. The work that started as a plan a person wrote ends as a commit on main a person merged, and every step in between is on the record where the next person can read it.

Merge straight to main

Most work should go through a pull request, because a PR is where review happens. For the cases that do not warrant one, there is a direct path: merge to main writes your selected changes to the main branch as a single commit, recorded in your name, without opening a PR first.

This is a deliberate, narrow capability. It is gated to your owners and admins, it is marked destructive, and it lands a commit straight on main, so it is the move for a trusted, low-risk change by someone you have given that authority, not the everyday path. The everyday path is a pull request your team reviews and merges on GitHub, and the product steers you there by making the PR the thing every Flow and every action produces.

Who can ship and merge

Opening a pull request and merging straight to main are separate permissions, because they carry different weight.

Opening a PR ships on the Member role and the roles built on it, your members, leads, and workspace operators, along with admins and owners, so the people who run agent work can put the result in front of the team as a pull request. Merging straight to main is held by your owners and admins alone, the same people you trust with the rest of a workspace's irreversible moves. The split matches how the work actually flows: many people propose, and a small, accountable set holds the keys to the main branch, with GitHub's own controls layered on top of both.

Why shipping works this way

The hard part of letting an agent write code is not the writing. It is the landing: how a change an agent made reaches your main branch without slipping past the review every other change goes through. The wrong answer is a special agent-merge path that bypasses your process. Disco Parrot's answer is to make the agent's output an ordinary pull request and stop there, so the change meets the review every other change meets instead of routing around it.

For a planner, shipping agent work changes nothing about how work lands: a PR opens, your team reviews it, and it merges on GitHub the way it always has, so adopting an agent does not ask your team to learn a new way to ship. For an engineer, the PR carries a real diff under a real teammate's name, and review comments turn into more agent work through Fix this rather than into a thread the agent quietly edits. For a lead, the merge stays on GitHub under your branch protections and required approvals, and merging straight to main is an owner-and-admin capability you grant deliberately. For the person who has to sign off on letting agents near your repository, the agent never holds your Git credentials and never merges its own work: it proposes, a person decides on GitHub, and the proposal is a pull request you would have recognized before you ever added an agent. There is no new merge path to threat-model, because there is no new merge path.