GitHub and GitLab
The pull request shows up on the issue it fixes.
Connect GitHub or GitLab and name the issue in a branch, a commit or a pull request. The issue shows that work with its review and CI state, and automations move its status when the work moves.
Type the key where you already write.
There is nothing to copy across and no button to press at the provider. Name the issue in one of three places and the work is linked to it.
A branch name
feat/ACME-10-inviter-on-landing
Create the branch the way you already do. Its first push links it to the issue.
A commit message
ACME-10: show the inviter’s name and avatar
Every pushed commit that names the key is listed on the issue, under the pull request it belongs to.
A pull request’s title or description
Closes ACME-10
A closing word such as Fixes, Closes or Resolves before the key marks the pull request as the one that closes the issue. Without one, it only mentions it.
A pull request that never named the issue can be linked by pasting its address, and any link can be removed.
ACME-10Invite landing shows the inviter
acme/web
Pull requests
#45Show who sent the invite on the landing page
OpenReview requestedCI passingCloses
Alex Lee · 4 commits · feat/ACME-10-inviter-on-landing
A hand-drawn view with fictional data. The panel lists pull requests with their commits inside them, then branches and commits that belong to none.
One badge says where the code is.
Every linked issue carries a badge that sums up its branches and pull requests, in the issue list and on board cards. Colour is kept for what needs a look: a failing check, requested changes, a revert.
- Development: Merged
- Development: CI failing
- Development: Changes requested
- Development: Approved
- Development: In review
- Development: Draft
- Development: Branch active
- Development: Reverted
Swimlane header overlaps count
Invite landing shows the inviter
Search by it.
The same search language reads pull requests, the badge, the repository and the branch, in the search bar, in saved views, in reports and for agents.
development: {CI failing}Issues whose pull request has a failing check
pull request: Open assignee: meYour issues with a pull request still open
repository: acme/web #UnresolvedOpen work linked to one repository
has: -development #ResolvedResolved issues nothing in git ever named
Let the merge move the issue.
An automation sets an issue’s status when something happens in git, when the last open subtask is resolved, or when an issue is marked as a duplicate. Each one belongs to a project, and a Project Admin turns it on; Close duplicates starts on.
What can fire a rule
- Branch created
- Commit pushed
- Pull request opened
- Pull request ready for review
- Pull request merged
- Pull request closed
- Revert merged
- All subtasks resolved
- Marked as a duplicate
Conditions narrow it: a status category, an issue type, a pull request that closes the issue, a merge into main, or every linked pull request merged.
Six templates; only Close duplicates starts switched on
Start work on branch
A new branch for an issue that has not started moves it to your first started status, such as In Progress.
Review on pull request
A pull request marked ready for review moves the issue to In Review, if your project has that status.
Close on merge
Merging the pull request that closes the issue, once all its pull requests are merged, moves it to your first done status, such as Fixed.
Reopen on revert
A merged revert moves a done issue to Reopened.
Resolve parent when subtasks are done
Resolving the last open subtask moves the parent to your first done status. No repository needed.
Close duplicates
An open issue marked as duplicating another moves to Duplicate, and the original stays open. On in every project from the start; switch it off if you prefer.
In the issue’s history
ACME-6 Project-scoped invite links · 9 Oct 2026, 3:00pm
Nothing Left Bot · Close on merge · Status: In Progress → Fixed, because acme/web#38 was merged by @jordan
ACME-8 Saved view count is stale · 5 Oct 2026, 9:10am
Nothing Left Bot · Reopen on revert · Status: Fixed → Reopened, because acme/web#40 was merged by @sam
Updated by still names the last person who changed the issue. Merge the pull request yourself and you are not notified about the change it caused.
One rule wins
Rules for the same trigger run top first. The first one that changes the issue ends it, so two rules never fight over one issue.
No chains
A change an automation makes never fires another rule. Resolve the last subtask by hand and the parent moves; let a merge resolve it and the parent stays.
A dry run first
Test a rule on one issue and read what it would do now, or why it would leave the issue alone. Nothing changes.
A run log
Every time a rule looked at an issue: what it changed, or why it did not. Kept for 90 days.
Ask your agent whether it merged.
The development tools call the same API as the web app, so an agent reads what the issue shows and changes only what your role allows. Titles and commit messages from the provider reach it marked as data, not instructions.
get_issue_developmentBranches, commits and pull requests for one issue, with review and CI.
link_pull_requestLink a pull request that never named the issue, by its address.
list_automationsThe project’s rules, in the order they run.
test_automationA dry run of one rule on one issue.
list_automation_runsWhat each rule did, and why it skipped.
Did ACME-12 merge? Is anything still open for it?
- get_issue_developmentissue: "ACME-12"
Yes. acme/web#42 Explain expired invite links was merged into main by Alex Lee on 8 Oct 2026, 4:36pm, approved and with CI passing. It closes ACME-12, which is Fixed. No other pull request or branch is open for it.
It reads your repositories. It never writes to them.
An Org Admin connects GitHub or GitLab once for the organisation, and a Project Admin links the repositories whose work belongs to the project. A project with no linked repository shows nothing about git at all.
Limits on the hosted beta
- Connected GitHub or GitLab accounts
- 2 per organisation
- Linked repositories
- 10 per project
- Automations
- 10 per project
Not built today
- Deployment status. Nothing reports which release or environment a change reached.
- Writing back to the provider. No comments on pull requests, no commit statuses, nothing pushed.
- Bitbucket. GitHub and GitLab only, including GitHub Enterprise and self-managed GitLab.
- A general rules engine. An automation sets a status, from a fixed list of git and subtask triggers.
Questions about GitHub and GitLab.
What it reads, what it changes and what it leaves alone. Short answers here, the rest in the manual.
Does it change anything in our repositories?
No. A connection only reads: it does not comment on pull requests, set commit statuses or push. Everything it learns comes from the provider’s webhooks and, when you first link a repository, the open pull requests and those updated in the last 90 days. Development in the manual
Which providers and hosts work?
GitHub through the GitHub App, or with a webhook you add yourself, and GitLab with a group or project access token. GitHub Enterprise and self-managed GitLab work at their own address. Bitbucket is not supported.
Do we have to turn automations on?
Yes. The templates are offered and never switched on for you, and a project with no linked repository shows nothing about git at all. Each automation belongs to a project, and Project Admins create and change them. Automations in the manual
How do we know an automation changed an issue?
The change is in the issue’s history from Nothing Left Bot, with the rule’s name and the cause: which pull request, merged by whom. The run log also records each time a rule left an issue alone, and why.
Whose name is on a commit or pull request?
A member’s, when the server can tell: their GitHub sign-in, a commit email they verified, or a login they claimed in their account settings. Otherwise the provider’s login shows, marked as not linked to a member.
What are the limits?
On the hosted beta, each organisation connects up to 2 GitHub or GitLab accounts, and each project links up to 10 repositories and keeps up to 10 automations. Limits and billing
Link one repository and watch an issue fill in.
Join the beta, connect GitHub or GitLab, link a repository to a project and push a branch named after an issue. Add Close on merge when you want the status to follow.