Bob with GitHub: move from a Slack request to a reviewable pull request

Matthew, founder of Bob · Published July 30, 2026

Short answer

Bob's purpose-built GitHub connection can search code, read repository files, list issues and pull requests, and inspect pull request diffs. It can also create issues and comments, create a branch, commit files, and open a pull request.

GitHub's REST API treats pull requests as the collaboration layer around proposed changes, with endpoints for listing, creating, reviewing, and merging them. Bob uses the parts required to prepare a reviewable change and open the pull request. He does not claim that the current purpose-built action set merges it.

Five useful Bob and GitHub workflows

1. Explain where a behavior lives

"Search the repository for the code that decides whether an invoice is overdue. Explain the path and cite the files."

Bob can search and read code through the connected user's repository access, then return a source-grounded explanation in Slack.

2. Review a pull request in context

"Read PR 842's diff, the linked Linear issue, and the incident note. Summarize the behavioral change and likely regression risks."

GitHub provides the code change; the connected project and incident systems provide why it exists.

3. Create a tracked issue

"Create a GitHub issue for this reproducible bug with the logs, expected result, and acceptance criteria from this thread."

Bob prepares the issue and asks before creating it.

4. Make a small code change

"Update the setup guide with the new environment variable, run the relevant checks, and open a pull request."

Bob can create a branch, commit files, and open a pull request. Repository rules and CI still decide whether the change is acceptable.

5. Deliver a weekly engineering brief

"Every Friday, summarize merged work, long-running pull requests, and release risks. Join GitHub with Linear and Cursor usage, but do not rank individuals."

The useful output is an operating brief, not a leaderboard built from weak activity proxies.

How the connection works

1. Ask Bob in Slack to connect GitHub.
2. Open the hosted OAuth flow and authorize the intended GitHub account.
3. Review organization approval and repository access.
4. Return to Slack and retry the repository request.

Bob's purpose-built GitHub path is personal. He acts with the access of the person who connected it, including any organization restrictions and repository permissions on that account.

Limits worth knowing

• No permission bypass. Bob cannot read or change a repository the connected user cannot access.
• No merge claim here. The current purpose-built actions stop at opening the pull request.
• Repository rules still apply. Branch protection, required reviews, tests, and CODEOWNERS remain authoritative.
• Writes ask by default. Issues, comments, branches, commits, and pull requests remain reviewable.

FAQ

What can Bob do with GitHub?

Bob can search and read code and pull request data, create issues and comments, create branches, commit files, and open pull requests.

Whose GitHub access does Bob use?

The person who connected GitHub. Bob's purpose-built connection is personal.

Does Bob ask before changing a repository?

Yes. Repository writes ask by default unless the user granted a matching standing policy.

Can Bob merge a pull request through this connection?

Not through the current purpose-built action set described here. Bob opens a pull request for normal review and merge.

Start with a read, then give Bob one small change

Ask Bob to explain a file or diff first. Once the repository and source are right, try one contained documentation or test change. Connect Linear, Jira, or Cursor when the engineering context lives elsewhere.