Pull Requests

Buck interacts with pull requests in two ways: automatic code review when PRs are opened or updated, and ad-hoc responses when you comment @bucky.

Ownership & review flow

Bucky PRs follow Fetch’s PR guidelines for agentic workflows: the engineer who requested the work owns the PR and reviews it first.

1. Sessions open PRs as drafts, with a Requested by: line in the body
2. Buck assigns the requester to the PR and requests their review, using the GitHub username from their dashboard settings
3. Automatic code review runs during the draft phase, so Buck addresses its own findings before the requester looks
4. When the requester approves the draft, Buck flips it to ready-for-review — that’s the moment the PR opens up to the team (and CODEOWNERS review requests fire)

Note

If your GitHub username isn’t set, Buck can’t assign you or auto-flip the PR. Set it on the dashboard settings page, or tell bucky in Slack. Pressing Ready for review on GitHub always works as a manual fallback.

Automatic code review

When a PR is opened or updated, the bucky-code-review workflow runs automatically. It:

1. Reads the PR diff and understands the changes in context
2. Searches related code via Sourcegraph for broader understanding
3. Posts review comments with context-aware feedback
4. Catches bugs, suggests improvements, and flags potential issues

Note

Code review also runs on bucky’s own PRs — including while they are drafts — so findings are addressed before the requesting engineer reviews. Buck only ever comments; it never approves or requests changes, so human approvals are still required to merge.

Ad-hoc @bucky comments

Comment @bucky on a PR to ask questions or request changes:

@bucky can you explain what this change does to the error handling?

@bucky add unit tests for the new retry logic

PR comments with @bucky are handled by the agent service via GitHub App webhooks, the same way Slack and Jira mentions work.