From Issue to Human-Approved Merge

Illustrative session. This walkthrough shows the documented engineering workflow end to end. It is not a production recording and claims no production metrics. For a real, fully public session transcript see the x402 payment session; for a customer deployment with published figures see the case studies.

Request

A team member posts in the swarm's Slack channel:

"The scheduler dropped one-time tasks again after last night's restart. The issue is on the repo with repro steps. Take it — reproduce, fix, open a PR."

The request lands as a GitHub issue on the public desplega-ai/agent-swarm repository: a bug report with reproduction steps, an expected behavior, and a stack trace. Nobody has investigated yet. This is the same intake shape documented in the feature development playbook: a Slack ping or an issue becomes a merged pull request through specialized agents that hand context off instead of losing it.

Starting context

The swarm already has what the work needs. The repository is registered, so the lead knows its guidelines: which checks run before a PR, how reviews work, and who may merge. GitHub and Slack integrations are connected, and every worker starts in its own isolated container with the gh CLI available. The issue itself carries the reproduction steps, so no human time has been spent on triage beyond filing it.

Sources and tools

• GitHub integration and gh CLI — reading the issue, branching, opening the PR, and replying to review comments. See the GitHub integration docs.
• Built-in skills — implement-issue, create-pr, and review-pr ship with the swarm; their source is public in plugin/commands and plugin/pi-skills.
• Task lifecycle and delegation — how the lead routes work to workers is documented under task lifecycle.
• Shared memory — the worker checks swarm memory for past fixes in the same subsystem before touching code.

Task breakdown

1. Intake. The lead picks up the Slack message, opens the issue, and decides this needs direct implementation, not a research phase — the repro steps are already in the ticket.
2. Delegation. The lead assigns the issue to a coding worker with the repo's guidelines attached: run the gates, conventional commits, no merge without human approval.
3. Reproduction. The worker starts in an isolated container, clones the repo into a git worktree, and runs the failing scenario from the issue until it reproduces.
4. Fix. The worker finds the cause — one-time schedules are only reloaded on a polling path, not at startup — and writes the smallest change that fixes it, plus a regression test.
5. Gates. Lint, typecheck, and the test suite run in the worker container. The first run fails on an unrelated flaky test; the worker re-runs the single shard and confirms the failure predates its change before proceeding.
6. PR. The worker pushes the branch and opens a pull request with gh, linking the issue and summarizing the root cause in the PR body.
7. Review. A reviewer agent reads the diff critically — not a rubber stamp — and leaves one inline comment about an edge case. The worker's follow-up task resumes its original session via parentTaskId, so the fix-up commit lands with full context.

Worker roles and handoffs

The lead triages and routes; it never writes the fix. The coding worker owns the issue end to end inside its own container and worktree. The reviewer agent challenges the diff. Context moves between them as task assignments and follow-up tasks, not as copy-pasted chat — each handoff carries the issue link, the repo guidelines, and the session history. The pattern is the one described in worker roles in the feature development playbook.

Approval points

Two gates stay closed until a human opens them. First, the PR requires a human reviewer's approval — the swarm requests review but cannot approve itself. Second, the merge is performed by the human after CI is green. The swarm also posts nothing back to the public issue until a human has seen the proposed reply.

Output

One pull request: a conventional-commit branch, a root-cause summary, a regression test, green CI, and a resolved review thread — linked from the original issue, ready for the human reviewer.

Measurable result

Verifiable artifacts, not vanity numbers: one PR opened against the public repo, all required checks green, one review round completed, and a human-approved merge. This illustrative session claims no production metrics such as cycle time or defect rates.

What stayed human-owned

The decision that this bug was worth fixing now, the final code review, the merge itself, and every word posted back to the public issue. The swarm did the reproduction, the fix, the gates, and the paperwork; the humans kept the judgment calls.

Browse more sessions on the examples index.