The coding agent pull request workflow: plan, approve, build, review, merge

Updated 2026-09-02

An autonomous coding agent gets expensive when a diff lands that nobody read. Denly puts you at two fixed points, the plan before any code is written and the pull request before anything merges, and records who passed each one.

Denly is a control plane for coding agents (Claude Code, Codex, Cursor, Grok Build, Antigravity) that run on your own machines and your own subscription: you describe a task, the agent plans it, you approve, it builds locally and opens a pull request. The lifecycle below is what "you approve" means in practice.

The lifecycle, and who holds each gate

Stage	Who acts	What you can do
Backlog	You	Edit the title and description, set priority, make it private, or send it to the planner. This is the only stage where the brief itself is still editable.
Plan	The agent	Watch it work, or wait.
Approval gate	You	Approve the plan, or send it back with notes and the agent plans again. Nothing is written until you pass this.
Build	The agent, on your machine	Answer the questions it asks. Retry a failure from the last step, from the beginning, or fresh on another runtime.
Review	You, and any configured reviewers	Read the pull request. AI review, security review and human sign-off can each be required by workspace policy.
Merge	You	Merge through the recorded gate. The agent has no merge path of its own.

Use the approval gate

Reading a plan costs less than reading the wrong diff, so send plans back with notes; the agent replans against them. A backlog task can also skip planning and go straight to build, which is the right call for a chore whose instruction is already exact.

Making the gates policy rather than habit

A flow combines planning, build, AI or security review, human sign-off, command steps, QA, deploy and merge. Workspace policy can leave a flow optional, require it as a minimum, or pin it exactly, so no project can drop the review step on its own.

The naming conventions live on the Defaults screen, at workspace scope or per project: the branch, commit and pull-request title shapes the agent uses, with placeholders such as the task number and slug, plus the merge method – squash, merge or rebase.

When a run goes wrong

It asked a question. The task waits. Answer it and the run continues.
It failed. Fix the cause, then retry from the last step, from the beginning, or fresh on another runtime.
It went the wrong way. Pull the task back out of the agent's hands. Insights counts those separately from failures, because they mean something different about the brief.
You need it later. Park it and resume it when you want.

Projects without Git

A local project with no Git repository follows the same path up to the end, where Review changes → Mark complete replaces the pull request and the merge. The runner never initializes Git in that folder.