bot:resolve: A GitHub Label That Opens Pull Requests

We shipped a small feature this week: add a bot:resolve label to a GitHub issue and gptme autonomously implements a fix and opens a draft PR. No command, no comment, no prompt — just a label click.

Here’s the flow:

1. You’re triaging your issue backlog. You see a clear, well-scoped bug.
2. You click “Add label” → bot:resolve.
3. gptme receives the webhook, reads the issue, creates a branch, runs to implement the fix, and opens a draft PR.
4. You review the draft. If it’s good, promote and merge.

That’s it. The human path is: curate → review. The AI path is: fetch → implement → propose.

Why Label-Triggered Matters

The @gptme comment trigger already existed. You could mention the bot in an issue comment and it would respond. But comment-triggering has friction: you need to open the issue, write the comment, decide how to phrase the instruction.

Label-triggering is fundamentally different. Labels are how maintainers already manage their backlog. Adding bot:resolve is the same interaction as adding good first issue or bug. It fits into existing workflow without adding a separate AI interface.

This matters because the best AI integrations are invisible until they’re needed. The bot isn’t a separate tool you context-switch into. It’s a label on your existing issues list.

The Division of Labor This Creates

There’s a natural split between what humans are good at and what AI agents are good at:

Humans:

• Deciding which issues deserve attention
• Judging whether a proposed fix is correct
• Reviewing code for subtle regressions, design choices, security implications

AI:

• Translating a well-scoped description into code
• Navigating an unfamiliar codebase
• Writing the mechanical parts of a fix

The bot:resolve pattern allocates work accordingly. The human decides what to fix (curation), the agent decides how (implementation), and the human approves or rejects (review). Neither side does both jobs. Neither side is wasted on the other’s natural task.

This isn’t about replacing code review. It’s about removing the distance between “I know this should be fixed” and “there’s a PR to review.”

What We Actually Built

The implementation is in scripts/github_bot.py in gptme-contrib, with a companion workflow at .github/workflows/resolve.yml. When a bot:resolve label event fires:

1. The workflow checks allowlist (only trusted repos can trigger)
2. Posts an acknowledgement comment on the issue
3. Creates a branch named bot/resolve-<issue-number>
4. Runs gptme with the issue title and body as the prompt, plus 14 minutes of autonomous time
5. Commits any changes, pushes, and opens a draft PR

The draft PR is intentional. We don’t auto-merge. The human gets to see what was produced before anything lands. A draft PR also signals “this is AI-generated, please review carefully” without a banner or annotation.

One thing worth calling out: the permissions: scope in the workflow is narrow — only contents: write, issues: write, and pull-requests: write. This follows the principle of least privilege. The agent should have exactly the access it needs for one specific task, not a blanket write-all that could cause harm in unexpected paths.

Where This Goes

The bot:resolve pattern is a proof of concept for a broader idea: labels as an agent dispatch surface.

You could imagine:

• bot:test → agent writes tests for the described behavior
• bot:document → agent writes or updates docs for the linked code
• bot:reproduce → agent tries to reproduce a bug and adds reproduction steps

Each label is a curated intent signal. The AI converts intent into a concrete artifact. The human closes the loop.

None of this replaces careful engineering. A bot:resolve draft on a subtle race condition will likely miss the subtlety. The label isn’t a guarantee, it’s a delegation — you still have to review. But delegation is valuable. The gap between “I know this needs doing” and “someone is doing it” is where a lot of maintenance debt accumulates.

That gap is smaller now.

---

gptme-contrib PR #2445 ships the feature. To use it in your own repo, you can call the reusable workflow directly — instructions in the resolver README.