Skip to main content
Capy ships code by opening pull requests itself, and the opening is the mechanic that makes everything downstream work: a PR opened through Capy subscribes the thread to that PR’s CI results, review feedback, and merge, and each of those events wakes the thread automatically. A PR opened by hand with gh pr create delivers none of that: the thread never hears about failing checks, review comments, or the merge, so it can’t fix, reply, or go idle. Let the agent open its own PRs.

​
The agent opens the PR

Ask for a PR and the agent commits, pushes, and opens it in one step. When its checkout sits on the branch the PR targets (main, master, develop, a release/* branch, or whatever base you configured), it mints a fresh capy/ branch at publish time, named from the PR title, and pushes there. Your main branch never carries agent work, even when the agent was editing a checkout of it directly. When the checkout is already on a capy/ branch carrying unpublished work, the agent publishes from that branch. When it’s on any other branch (one of yours), it refuses to publish rather than ship from a branch it doesn’t own; tell it which branch the work should ship from.

​
What wakes the thread after opening

Once the PR exists, the thread reacts to it without you relaying anything:
  • CI results. A failing check wakes the thread; it reads the failing job, fixes, re-pushes, and the rerun’s result comes back the same way. Passing checks arrive as one consolidated result once they all finish.
  • The automatic review. If auto-review is enabled for the repository, pushes get review rounds and the verdict lands in the thread that owns the PR; see PR reviews.
  • Human feedback. Review comments and PR comments from people wake the thread; it triages the feedback and replies. Bot comments are ignored by default; your org’s feedback settings can allowlist specific bots.
  • The merge. Merging wakes the thread so it can wrap up, and a thread you marked ready for review settles to idle on its own when a merge lands and no PR anywhere in its task tree is still open. Only a merge triggers the move to idle; a PR closed without merging doesn’t settle the thread by itself, but it doesn’t block a later merge from settling it either.
Two deliberate silences to know about:
  • A PR closed without merging does not wake the thread. The closure lands as context the agent reads whenever it next runs; a rejection is yours to act on, and the agent waits for your call.
  • Capy never merges unless you explicitly ask. Green CI and a clean review mean the change is shippable; the merge stays your call.

​
Stacked PRs

When new work depends on a PR that hasn’t merged yet, the agent opens the next PR with the previous PR’s branch as its base. Each PR in the stack then shows only its own diff, so reviewers see one change at a time instead of an accumulating pile.

​
Which thread owns a PR

Ownership follows the most recent push. The thread that opened a PR owns it; when another thread later pushes to the same branch (a side thread finishing stalled work, a task picking up a review round), that thread takes over, and follow-up events like review verdicts and the merge route to it. “Whose PR is this” is always “who last shipped code on the branch.”