A coding agent pull request workflow you can inspect and reproduce

Updated 2026-10-23

Give a coding agent a bounded task, agree on the plan, and review the resulting diff and test evidence before merging. This worked example follows an empty-cart bug through those decisions, including a failed check and recovery.

Denly is a control plane for coding agents (Claude Code, Codex, Cursor, Grok Build, Antigravity) that run on your own machines using your vendor subscription or API key. It manages tasks, plans and reviews across projects; Git-backed tasks can open pull requests, while no-Git projects end with a review of local changes. The example below uses the supervised flow with planning and PR review enabled.

A worked example, with runnable checks.The storefront project, task conversation and PR summary are illustrative. The downloadable JavaScript example is real code you can run with Node.js 20 or later, without packages or accounts. This is not a customer case study or a timing benchmark.

1. Write the brief and its acceptance checks

The sample storefront adds a 500-cent delivery charge even when the cart is empty. Use integer cents so the example stays focused on the rule.

Task brief

Fix the empty-cart delivery charge.
An empty cart must total 0 cents.
A nonempty cart keeps the 500-cent delivery charge,
including a cart containing a free item.
Keep the existing payment flow unchanged.
Add regression checks and show their results in the PR.

A real repository also needs the location of its total helper and its normal test command. Add those to the brief or project instructions. Choose the storefront project and an installed runtime, then submit the task for planning.

2. Revise the plan before approving it

Suppose the first plan proposes removing delivery whenever the subtotal is zero. That would also waive delivery on a cart containing a free item. Send back a specific correction:

Plan feedback

Use the number of items to detect an empty cart.
A free item still needs delivery. Add that regression case.
Keep this change in the total helper; do not rewrite checkout.

Read the revised plan. It should name the helper, the empty-cart condition, and all three checks. Approve only that scope. Plan approval starts the build; it does not approve the eventual PR.

3. Reproduce the failure and the correction

Download cart-total-demo.mjs, inspect it, then run it in a scratch folder. The file deliberately retains the original behavior behind --before.

Run the same checks before and after

node cart-total-demo.mjs --before
# Original: 2 pass, 1 fails. Empty cart returns 500 instead of 0.
node cart-total-demo.mjs
# Fixed: all 3 pass.

The complete runnable example

// Worked example for Denly's pull-request workflow guide. No dependencies.
// Run: node cart-total-demo.mjs            (fixed: three checks pass)
// Run: node cart-total-demo.mjs --before   (original: empty-cart check fails)
import assert from 'node:assert/strict';
import test from 'node:test';

const before = process.argv.includes('--before');

function cartTotal(itemPricesInCents) {
  const subtotal = itemPricesInCents.reduce((sum, price) => sum + price, 0);
  if (before) return subtotal + 500;
  return itemPricesInCents.length === 0 ? 0 : subtotal + 500;
}

test('an empty cart has no delivery charge', () => {
  assert.equal(cartTotal([]), 0);
});

test('a nonempty cart keeps the 500-cent delivery charge', () => {
  assert.equal(cartTotal([1200]), 1700);
});

test('a free item still counts as a nonempty cart', () => {
  assert.equal(cartTotal([0]), 500);
});

The correction checks the item count, not the subtotal. These checks establish the behavior of this small helper. A real checkout still needs its repository's integration and browser checks; this fixture does not exercise payments or a Denly runner.

4. Handle a failed run without losing the approved work

If a configured check leaves the task failed, open the task and inspect the reported error and saved changes. Add concrete guidance about the failing case. When available, choose Continue saved work to resume unfinished work from its retained checkpoint; use Retry when you deliberately want a phase rerun. Recovery availability depends on the retained workspace and checkpoint.

A runner that cannot safely recover needs attention. Keep the original machine available for a shared workspace, and inspect the task's recovery message rather than assuming another machine can continue it. Returning to a task is different from promising that every interrupted process resumes automatically.

5. Review the diff and evidence separately

Review question	Evidence in this example
Does the change match the approved scope?	Only the empty-cart condition changes; payment behavior is outside the task.
Does the test catch the original bug?	The same empty-cart check fails with `--before` and passes with the correction.
Is existing behavior preserved?	A 1200-cent item totals 1700; a free item still totals 500.
What remains unverified?	This standalone example does not prove the real storefront UI, payment flow or production environment works.

Example PR summary

Empty carts incorrectly included delivery.
Return zero only when there are no items; preserve delivery otherwise.

Validation: original behavior fails 1 of 3 regression checks;
corrected behavior passes all 3.
Payment and browser integration checks are outside this standalone example.

In Denly's supervised Git-backed flow, the PR waits for your review. Request changes if the diff exceeds the plan or the evidence is incomplete. Merge only after reviewing the code and the required checks. The sample homepage walkthrough illustrates these stages with shortened playback.

Make the workflow fit the repository

Configure command checks, AI reviews and human gates in the task flow. Workspace policy can require steps across projects. A task explicitly using workspace-enabled Autopilot can pass human gates after configured checks; agent questions, blocking reviews and failures still stop it. Keep Autopilot off when reproducing this supervised example.

For a project without Git, Review changes → Approve local changes replaces the PR and merge. Its bounded review diff can contain source or secrets and is uploaded as task evidence; see the data boundary before choosing recording and encryption settings.