Delivery: Coding Runs, Pull Requests & the Merge Hold

Once a Work Package passes its Definition of Ready and is dispatched, the code is written by a coding agent and arrives as a pull request. The Studio follows that pull request all the way: its Definition of Done reads the change itself, sends what falls short back to the coding agent, and holds the merge until the gate has passed.

The Coding stage

Choose the coding agent and the repository beside Dispatch. The coding agent and repository you last used in the studio are chosen for you next time. Dispatching hands the package to that one agent: it implements the package on its own branch and raises the pull request. No other agent runs at dispatch. The test plan is a Definition of Ready item, written into the package's Plan before approval, so the coding agent receives it in its brief. If the coding run cannot start, the package stays dispatched and Start coding run is offered again.

A dispatched package gains a Coding stage on its page, between the Definition of Ready and Iterate. Coding delivery shows every coding run for the package. Each run’s row leads with what the coding agent is doing, what to do next and the actions (Check progress, Iterate with the agent, Review against the Definition of Done), then the links to the issue, branch and pull request with the merge hold in a word; how the agent was briefed and the pull request’s checks fold away beneath, and open on their own only when something in them needs a look. Dispatching no longer moves you off the page. Once a package is dispatched it cannot be sent back to Wait or Revisit — the work is under way.

The Definition of Done review starts once the coding agent has raised its pull request (open or merged). Until then the page lists the items it will check; the server refuses to start the review earlier, because there is nothing yet for its code items to read.

The coding agents

The studio owner chooses which coding agents the studio dispatches to on Model Config → Coding agents, where each one's cost model, pros, cons and setup are stated and every connected repository shows what it is set up for. The dispatch dropdown offers only the enabled agents the repository is ready for.

Only one coding run is active on a package at a time: Start coding run is withdrawn while one is in progress.

Who starts a run. Every studio member can start a run on a coding agent that works from a GitHub issue (GitHub Copilot, Claude for GitHub, Codex for GitHub): the issue is made with your own GitHub account, and the agent then runs on the repository’s account (its Copilot seats, its Actions minutes, the API key in its secrets). A member starts one run at a time: another can be started once the run in progress has finished, its pull request has been merged or closed, or an owner or reviewer has closed it. From a work package, the system runner and a Claude Code routine are started by the studio owner or a reviewer, because they run on the studio’s AI keys and on someone’s Claude subscription; on the work package a member is offered only the agents they can start there. Every member can also review the proposal of a coding run on a work package and publish it while the package is dispatched or in progress, create a run’s pull request, and reply to the agent: each is done on GitHub as them. A code run started on its own from the Run Board is separate: it exists only where the studio owner has switched the system runner on, and it ends in a proposal to review, which the Studio’s pages do not publish. Dispatching a package, the decisions on its gates, and approve and merge are unchanged.

Where the Actions-based agents run, and what a minute costs

Claude for GitHub and Codex for GitHub run as GitHub Actions jobs in your repository, so their compute is whatever the workflow's runs-on label points at, and that label is yours to change in one line. The AI cost of a run is the same whichever runner it uses and is usually the larger figure; a cheaper runner stops you spending the minutes included in your GitHub plan. List prices read on 7 October 2026 (CodeBuild figures are us-east-1; other regions differ):

GitHub Copilot's coding agent is the exception. GitHub runs it on its own ubuntu-latest; it is compatible only with Ubuntu x64 and Windows 64-bit runners, and on a self-hosted runner its built-in firewall has to be turned off, which widens what the agent can reach. Leave Copilot on GitHub-hosted runners; a larger one is the one-line change there.

As of 7 October 2026 GitHub makes no charge for self-hosted minutes: the platform charge it announced in December 2025 was postponed, and GitHub's pricing page is the word on whether that changes. The Studio's readiness check looks for the agent's action in the workflow, not at runs-on, so changing the runner changes nothing in the Studio.

Setting up Claude for GitHub so it can build and test

A dispatch to Claude for GitHub runs your repository's own workflow. The stock workflow that the Claude GitHub App installs lets Claude read, edit, commit and push, and refuses every other command: Claude cannot install your dependencies, build, run the tests, or open its own pull request (it leaves a "Create a PR" link instead). The Studio sets up one that can.

Reviewing the changes

Once a coding run has raised its pull request, the Coding stage offers Show the changes. The files the pull request changed are listed on the left; every diff is stacked on the right in one panel you scroll through, with line numbers, and images show before and after. Choose a file on the left to jump to it. Very long diffs start folded so they do not bury the rest. Instruct on this file on a file’s header, or a click on a line number, opens the Iterate tab with the instruction pointed at that file and line.

Iterate: the back-and-forth with the coding agent

The Iterate tab, between Coding and the Definition of Done, is where a person and the coding agent go back and forth on the pull request. It opens with what the agent is doing now, as the last Check progress read it: working (with the commits since your instruction), asked a question, finished, waiting to pick an instruction up, or nothing outstanding. While the agent works, the page checks again every minute for up to half an hour. After you send the agent something — a rework, an instruction, an answer, an action on its dispatch issue, or the start of a run — the page also checks by itself: one minute later, then less often while nothing changes, and more slowly while the page is out of focus, for up to an hour or until the agent has finished or asked a question. The same state is shown on the run’s row on Coding, so you no longer have to watch the changed files to tell whether the agent is still at it.

When the agent pauses to ask something on the pull request, the question is listed here with Answer. The answer goes back as an instruction addressed to the agent and linked to its comment; until one is sent, the question stays open.

Instruct the coding agent says what must change — about the whole pull request, a file, or a line. How it travels depends on the agent:

Everything sent to the agent is kept in the log under the form — instructions, answers and every rework, including one that could not be sent, and why — and in the audit log. A rework is shown by its parts: what passed, what is not met with your notes, and the warnings. One sent to a Claude Code routine says it went as a new routine session, and links the session at claude.ai. When the Definition of Done agents assess an item that reads the pull request, they read the instructions an owner or reviewer gave, as context for whether a requested change landed, never as evidence that an item is met. A contributor’s instructions stay in the log for the team.

Sending the agents’ findings back for rework

When the Definition of Done agents find an item not met, the findings can go straight back to the coding agent without a decision being recorded first. On the Reviewer agents panel, once every assessment has reported, Send for rework opens a dialog that shows what passed, what is not met (with a note you can add beside each item) and the warnings — concerns raised by reviewers who still said Go, which are advice rather than blockers. The agent receives the same three parts, so it knows what to keep as well as what to fix. While an assessment is still running the panel says the rework waits for it: half the findings would be half the picture. The same findings are sent once; re-run the agents after the coding agent’s changes to send anything new. Choosing Revisit on the human decision still sends a rework too, as before.

Copy rework, beside each of those buttons and in the dialog (and on its own for a member who cannot send), puts the same text on your clipboard without sending anything: paste it into the coding agent’s own session, or into an agent of your own. It is there for every member of the studio, whichever coding agent owns the pull request, when that agent is switched off, and after the rework has been sent. For a Claude Code routine it is how to steer the session that did the work, since a rework sent from the Studio starts a new one; the link beside the button opens the session the work package was dispatched to. The agents’ findings cannot be copied while they are still assessing, or once the Studio has seen the pull request move on from the commit they assessed. Each rework on the Iterate log can be copied too, as it was sent.

The Run Board

The Run Board lists every run in the studio, newest first, with a link back to what started it — the Work Package, the intent, or the repository. Filter by what needs you, by agent, by initiator or by date, and sort by when a run began. Coding runs appear too, with their branch and pull request. Outstanding pull requests sits at the top: every open pull request a coding run produced, the package it delivers, whether its Definition of Done has passed, and the state of its merge hold.

The Definition of Done reads the pull request

Mark a Definition of Done item Reads the pull request and its agent is shown the pull request's code changes when it assesses the item. The flag is on by default for items handed to code-facing agents (code reviewer, security scanner, test architect, code generator) and off for process items, because the diff is most of an assessment's cost.

Sending it back for rework

When the pull request is not good enough, choose Revisit on the Definition of Done. Beside every item that was not met — whether the agent or a person found it wanting — you can add notes for the coding agent: what to change, and where. The rework the agent receives carries your reason, the blockers, and for each item what was found, what the agent asked for, and your notes.

It travels the way an instruction does — a pull request comment as you for Copilot or Claude, a corrective run for the system runner — and appears in the instruction log. If it cannot be sent (no open pull request, or your GitHub account is not connected), the panel says why and offers to send it again.

While the gate waits on your decision, the Human approval panel is outlined and headed Your decision, with larger Go, Wait and Revisit buttons.

Corrective runs

On a system-runner pull request, a coding action starts a corrective run: a new bounded run that reads the pull request's own branch, runs as the agent the checklist item names, and is briefed with the item and the action. Its proposal is listed under the run on the Work Package page. Review it, then choose Publish to branch: it lands as one commit on the open pull request — no new branch, no new pull request — and the item's evidence is marked stale so it can be assessed against the change.

The merge hold

Every pull request a coding run produces carries a commit status — or, for a repository connected through the GitHub App, a check by the app — named productivity-workbench/definition-of-done, on its head: pending until the package's Definition of Done gate passes at the current version, success once it has. It follows the gate — a new commit, a material change to the package or a stale piece of evidence puts it back to pending — and it links back to the package.

Require that status in the repository's branch protection and the pull request cannot be merged until the Definition of Done has passed. Until it is required, the hold is advisory, and the Work Package page and the Run Board say so.

The DevOps panel

The 🛠️ DevOps button on a connected GitHub, GitLab or Bitbucket repository reads its CI/CD pipeline files — GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Azure Pipelines, CircleCI and Jenkins — and describes them in plain terms: when each pipeline runs, its build, test, scan and deploy stages with the commands they run, where it deploys, which secrets it relies on, and what is missing.

Creating a pipeline

On a GitHub repository, Create a pipeline writes a dev pipeline (pull requests and pushes to the default branch: build, test and scan, and a push deploys to dev) and a prod pipeline (a v* tag: build, test and deploy to production), for Node.js, Python, Java, .NET or Go, deploying through a script in your repository — after signing in to AWS, Azure or Google Cloud with OIDC if you choose one.