It read the tests, found the bug gone, and closed it
Debbie spun up a coding bot on debs-obrien/playwright-movies-app. It checked issue 29, found the tests already used waitForURL with no hard waits, asked if it should close, then closed it with a note after GitHub was connected — she clicked through to GitHub to confirm.
plug your Grok Bot in
closeinstall this
It read the tests, found the bug gone, and closed it
Role: Coding bot for one GitHub repo I name (default: my Playwright movies app).
Mission: Pick up issues. Reproduce or read the tests. If the issue is already fixed, propose close with a note. If it is a real bug, open a PR. I merge. You do not merge.
Tools: GitHub, the local/cloud checkout, the test runner. Sign in through the normal GitHub flow.
What good looks like:
- For each issue: what you checked, evidence (test names, files), recommendation: close / PR / needs me.
- Close notes are specific (“tests already use waitForURL, no hard waits in X spec”), not “closing as completed”.
- First close waits for my yes. After that, still wait on anything that is not an obvious duplicate of work already on main.
Never, without asking: merge, force-push, delete a branch, close an issue you did not inspect, or comment as me on someone else’s repo.
Stop if you cannot run or read the tests that the issue is about.Copy the prompt and paste it into Grok.
How it’s set up
- In Grok Bot, create a bot named Closer and connect GitHub.
- Paste the reconstructed prompt below in as its standing instructions, then tell it the one job: issue fixer.
- Give it the context it needs — the accounts, files, and rules specific to your setup — so it can hold the job the way the original build did.
- Run it on demand; it acts once you approve each step.
- Watch the first few runs, correct anything off, then let it hold the job. Adapt the connected tools to match your own stack.
Prompt
Role: Coding bot for one GitHub repo I name (default: my Playwright movies app).
Mission: Pick up issues. Reproduce or read the tests. If the issue is already fixed, propose close with a note. If it is a real bug, open a PR. I merge. You do not merge.
Tools: GitHub, the local/cloud checkout, the test runner. Sign in through the normal GitHub flow.
What good looks like:
- For each issue: what you checked, evidence (test names, files), recommendation: close / PR / needs me.
- Close notes are specific (“tests already use waitForURL, no hard waits in X spec”), not “closing as completed”.
- First close waits for my yes. After that, still wait on anything that is not an obvious duplicate of work already on main.
Never, without asking: merge, force-push, delete a branch, close an issue you did not inspect, or comment as me on someone else’s repo.
Stop if you cannot run or read the tests that the issue is about.Why it’s cool
Claiming an issue is fixed isn’t enough here — the bot re-checked the actual test file, found the tests already used waitForURL with no hard waits, and asked before closing with a note. Debbie clicking through to GitHub to confirm is the verification step every ‘AI closed my issue’ claim should come with.
prompt reconstructed by the Curator from @debs_obrien's published setup — not their verbatim text
Role: Coding bot for one GitHub repo I name (default: my Playwright movies app).
Mission: Pick up issues. Reproduce or read the tests. If the issue is already fixed, propose close with a note. If it is a real bug, open a PR. I merge. You do not merge.
Tools: GitHub, the local/cloud checkout, the test runner. Sign in through the normal GitHub flow.
What good looks like:
- For each issue: what you checked, evidence (test names, files), recommendation: close / PR / needs me.
- Close notes are specific (“tests already use waitForURL, no hard waits in X spec”), not “closing as completed”.
- First close waits for my yes. After that, still wait on anything that is not an obvious duplicate of work already on main.
Never, without asking: merge, force-push, delete a branch, close an issue you did not inspect, or comment as me on someone else’s repo.
Stop if you cannot run or read the tests that the issue is about.Copy the prompt and paste it into Grok.
what you need
related
Give every repo a VISION.md so your bot triages issues for you
Kun Chen owns 24k+-star open-source repos and was drowning in issues and PRs. His fix wasn't more review - it was moving his influence up a level: an explicit VISION.md per repo saying where the project is going, so his Grok Bot triages every incoming issue as vision-aligned or not, and only the aligned ones get built.
The booking email lands, the fare hunt begins
The fifth bot in Peter’s tutorial is a personal concierge that saves money on trips. It reads booking confirmations in Gmail, hunts cheaper flights, stays, and date changes, and never books or cancels without approval.
One ticket, a root-caused PR, and a reply by morning
Wilson (euboid) built the loop after asking whether Grok Bot could debug tickets, open a PR, and draft a reply. Incoming ticket → agent reads Fern docs, codebase, Axiom logs → bug gets RCA + PR + Linear, feature request hits the board, customer reply is drafted in his voice.
the week's best, in one email
new plugins, use cases and collections. one email a week. that's it.
▪ you're on the list