Skip to content

chore(skills): drop Cursor Bugbot from the babysit review loop #7059

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
waleedlatif1 merged 1 commit into from
Aug 25, 2026
Merged

chore(skills): drop Cursor Bugbot from the babysit review loop #7059

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 6 additions & 9 deletions .agents/skills/babysit/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: babysit
description: Drive a PR to a clean review (Greptile 5/5, zero open threads) — ships if needed, keeps it mergeable against staging, triggers Greptile/Cursor Bugbot, fixes real findings, replies to and resolves every thread, and loops until clean
description: Drive a PR to a clean review (Greptile 5/5, zero open threads) — ships if needed, keeps it mergeable against staging, triggers Greptile, fixes real findings, replies to and resolves every thread, and loops until clean
---

# Babysit PRs
Expand Down Expand Up @@ -58,9 +58,9 @@ round. Always check both conditions freshly after every push.
2. **If the PR has a merge conflict**, merge `origin/staging`, resolve the conflicts, run the
usual pre-push checks, push, and go to step 8 to re-trigger review.

3. **If no review has run yet** (fresh PR, no Greptile/Cursor comments): they usually run
automatically on PR open — confirm via `gh pr checks <n>` (look for `Cursor Bugbot` /
`Greptile Review`) and wait for that first round before doing anything else.
3. **If no review has run yet** (fresh PR, no Greptile comments): Greptile usually runs
automatically on PR open — confirm via `gh pr checks <n>` (look for `Greptile Review`) and
wait for that first round before doing anything else.

4. **If a review round has landed and it isn't clean**: for every thread where
`isResolved: false`, triage the finding on its own merits — this is the part that requires
Expand Down Expand Up @@ -113,15 +113,13 @@ round. Always check both conditions freshly after every push.
rounds; checking sync only before the push (step 6) and never after is how a bad push or a
PR whose commit history quietly went stale between rounds goes unnoticed.

8. **Re-trigger review** by posting `@greptile` and `@cursor review` as **two separate PR
comments** — never combine them into one comment, each bot only responds to its own mention:
8. **Re-trigger review** by posting `@greptile` as its own PR comment:
```bash
gh pr comment <n> --body "@greptile"
gh pr comment <n> --body "@cursor review"
```

9. **Wait for the new round**, then go back to step 1. Pace the wait with `ScheduleWakeup` using
a fallback delay of ~250–300s (Greptile/Cursor typically take 1–3 minutes) — never busy-poll
a fallback delay of ~250–300s (Greptile typically takes 1–3 minutes) — never busy-poll
in a sleep loop. Pass the same `/loop babysit PR <n>` prompt on each wakeup so the loop
resumes correctly.

Expand All @@ -147,7 +145,6 @@ notification email.

## Hard rules

- Never post the two re-review mentions as a single combined comment.
- Never paste prod evidence into a reply without scrubbing it first (see above).
- Never resolve a thread without replying to it first.
- Never fix a finding with a hacky workaround — if the clean fix isn't obvious, find the sibling
Expand Down
Loading