Sign in, then approve the App on GitHub. You choose the account or organisation it lands on.
It opens the pull request. Then a separate reviewer — a different context, with nothing invested in the answer — gives one verdict on it, bound to the exact commit it judged.
Nothing merges until you click Ship. Overriding is allowed, and recorded.
There is nothing to host, no CI to rewire and no key to paste. Two clicks on github.com and the loop is running on the repositories you picked — and only those.
Sign in, then approve the App on GitHub. You choose the account or organisation it lands on.
Pick specific repositories — not “all” unless you mean it. You can change the list on GitHub whenever you like, and collabd follows it.
collabd proposes the work, plans it, writes it, opens the pull request and reviews it in a separate context. Two of the seven steps are yours — approving the plan, and pressing Ship — and nothing gets past them on collabd’s own judgement.
It reads the repository and proposes work worth doing — with the reason it matters now, and the files it expects to touch.
Why now · touched files · effort · nothing starts until you press Build this
It drafts the plan as numbered steps and proposes what “done” should mean. You edit both and approve — or send it back. Approving freezes that list onto the run.
Editable steps · the criteria are yours · frozen at approval, so the review is graded against your list and not its own
It writes the change on a branch of its own and runs its own tests as it goes. Never on your default branch.
collabd/run-… · a sandbox of its own · the step it is on, in words, while it runs
It opens an ordinary pull request. Your CI runs on it exactly as it would on anyone else’s, and your own review tools still apply.
An ordinary PR · your checks, your protections · nothing is merged by opening it
A separate reviewer — a different context, with nothing invested in the answer — reads the diff, runs its own tests, and grades each criterion you wrote.
A different context · its own suite, never your CI’s word · evidence per criterion, and “can’t confirm” is an answer it is allowed to give
One mark, bound to the exact commit it judged, published as a check on the pull request. If the branch moves, the verdict goes stale rather than quietly staying green.
One of three marks · no score, no percentage · the marks themselves are the next section
Nothing merges until you press it. Override a block if you mean to — it is allowed, and it is recorded either way.
Your finger on the button · overriding is audited · or send it back with a note
Request a fix sends the run back to step 3 with your note attached, and it comes round again. That is the part that makes it a loop rather than a pipeline.
No score, no percentage, no risk number. There is no fourth state — when the reviewer cannot reach a judgement you get the reason instead of a colour collabd has not earned.
Pick one to see what it looks like on a pull request.
The reviewer ships as its own App that never touches your code. Install it on one repository and it starts posting verdicts on every pull request your team opens — whoever or whatever wrote it. No agent, no branches, nothing to undo.
This is the consent screen, reproduced. Not a summary of it — every line GitHub will show you, and nothing it will not.
The agent. Pushes a branch and opens a pull request — never on your default branch, and never merged on its own judgement.
| What GitHub says | Scope |
|---|---|
| Read and write access to codewrite | contents |
| Read and write access to pull requestswrite | pull_requests |
| Read access to metadataMandatory on every GitHub App. Not a choice we made. | metadata |
The reviewer. Reads the diff and publishes one check. It cannot push a commit, open a pull request, or merge anything.
| What GitHub says | Scope |
|---|---|
| Read and write access to checkswriteThe verdict itself. This is the only thing it writes, anywhere. | checks |
| Read access to code | contents |
| Read access to pull requests | pull_requests |
| Read access to merge queues | merge_queues |
| Read access to metadataMandatory on every GitHub App. Not a choice we made. | metadata |
The line that holds whichever way the lists drift: every write permission the reviewer holds writes to that one check and nowhere else. The authoring App is the one that touches code, it only ever does so on its own branch, and nothing merges until a human clicks Ship — which is recorded, with a name on it.
Closed beta, with people already running more agents than they can read.