Skip to main content
Capy ships code by opening pull requests, and subscribing to CI results, review feedback, and merge results.

Capy opens the PR

Ask for a PR and the agent commits, pushes, and opens it with one tool. 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.

What wakes the thread after opening

Once the PR exists, the thread will automatically wake up to certain events:
  • CI result: 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.
  • Automatic Capy reviews: 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.

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.”