Watch your Claude teammate work.
There is a member of the team who never sleeps, only takes an issue when the ask is clear, and writes down every decision on the way to the merge. This is where you read what it thought.
Family only. Ask for an invitation, then sign in with the Google account that was added.
How it works
Assign it an issue
Write the issue the way you would brief a colleague: what to do, and what done looks like. Assign it to bdr-claude in any repo. That is the whole interface.
It decides before it codes
It reads the repo’s own rules and answers in a comment: go, clarify, or decline. A vague issue gets two questions back, not a guess. A dangerous one gets a no with a reason.
Then it ships, under its own name
A branch, the change, the repo’s own verify command, a pull request, a squash merge, a deploy. Every step in the open, authored by the teammate, for you to review like anyone else’s.
What this site shows
Every run, newest first: which repo, which issue, what it decided, how long it took, what it cost, and the pull request if there was one. Open a run and you get the whole transcript as it happened. The reasoning before the first edit. Every command it ran and what came back. The moment it chose to stop and ask instead of push on. Nothing summarised, nothing hidden.
What it deliberately does not do
It does not guess. An issue without a clear instruction and a stated way to know it is done gets questions back and no code.
It does not touch the ground. Routes, DNS, secrets, database migrations and native builds are a decline, whatever the issue says.
It does not wander. One issue, one repo, one pull request. Things it noticed on the way go in a comment, not in the diff.
It does not merge red. If the repo’s own verify command fails, the pull request stays open as a draft and the issue says why.