Wiki · Integrations
GitHub
An agent with repository access has the same rights you do. How to grant them sensibly and what to give it to do.
🐙
An agent with repository access is not “just a reader” — it has the same rights you do.
Give it a write token and it can push, delete branches and close pull requests.
Start read-only, in one repository, and add rights only as you actually need them.
What it takes
| Item | Purpose |
|---|---|
GitHub CLI gh | The agent does everything through it — PRs, issues, reviews, repos |
gh auth login | Interactively, or with a token (GH_TOKEN in the environment) |
| A running gateway | Without it neither scheduled jobs nor webhooks work |
The bundled github skill | A ready-made guide to working with gh |
Verify it works
gh auth status # who am I and what may I do
gh pr list --repo owner/repo --state open --limit 3
gh pr diff 42 --repo owner/repo # what the PR changes
If this passes, the agent has access and you can hand it work. If not, the error usually names the missing scope.
Reviewing a pull request
Review this pull request: read the diff and look for bugs, security problems
and poor code. Be specific — line numbers and quotes of the problematic code.
The agent fetches the diff, reads it and writes a structured review. If you want it done the same way every time, turn that into a skill (your own review rules) — then it does not have to guess what you care about.
Two ways to automate reviews
| Scheduled job (cron) | Webhook | |
|---|---|---|
| How it works | Every 2 hours the agent asks what is new | GitHub calls in as soon as a PR appears |
| Needs a public address | No — works behind a firewall | Yes (through a reverse proxy) |
| Delay | Up to the interval | Seconds |
| Best for | Small teams, personal repos | A company where speed matters |
Cron is the safer start: nothing is exposed to the internet and every PR still gets reviewed. Add a webhook when the delay starts to hurt (see the webhooks page).
What the agent can do in a repository
| Task | Example |
|---|---|
| Review and comment on PRs | A review with concrete findings, posted as a PR comment |
| Create a branch and commit | A fix that then goes through CI |
| Issues | Open, comment on, label, close |
| CI and checks | Read run results and find what failed |
| Releases and tags | Prepare a release (with a write token) |
Things to watch
| Situation | What to do |
|---|---|
The agent pushes straight to main | Enable branch protection and make it work through PRs only |
| A token in git or chat | Tokens belong in .env (or a password manager); revoke if leaked |
| The review is generic (“looks good”) | Write a skill with your rules and examples; without them the agent guesses what matters |
| It comments on every PR, even where it should not | Limit the job to specific repositories and labels |
| Missing permissions | gh auth status names the scope; fine-grained tokens need it added |
How we do it
| Habit | Why |
|---|---|
| Read-only token until writing is actually needed | Most work is reading and commenting |
Always a branch and a PR, never straight to main | Even when the agent can push, a human has the last word |
| A dedicated skill with review rules | The review is consistent day to day and does not miss what we care about |
| Results to Telegram, not e-mail | We see them immediately and they do not get buried |