PluginBench
Skill
Review
Audit score 70

babysit

thedotmack/claude-mem

Monitor pull requests until merge-ready, resolving comments and checks automatically.

What is babysit?

Babysit watches a PR through its review cycle, polling checks and comments until all issues are resolved and it's ready to merge. Use this when you need continuous monitoring of a PR's status, review threads, and CI checks without manual intervention between updates.

  • Poll PR checks at configurable intervals (default 30-60 seconds) until they pass
  • Track and resolve unresolved review threads using GitHub GraphQL API
  • Read new comments and verify actionable findings against actual code changes
  • Fix real issues in focused commits, run tests, and push updates
  • Distinguish between stale and active review threads before resolving
  • Stop only when checks pass, reviews are acceptable, and no actionable items remain

How to install babysit

npx skills add https://github.com/thedotmack/claude-mem --skill babysit
Prerequisites
  • GitHub CLI (gh) installed and authenticated
  • jq for JSON parsing of GitHub API responses
  • Access to the repository with PR number and base branch information
Claude Code
Cursor
Windsurf
Cline

How to use babysit

  1. 1.Identify the PR number, branch, and base branch
  2. 2.Run `gh pr view <number>` to check initial mergeability and review status
  3. 3.Poll checks at 30-60 second intervals using the provided GitHub CLI commands
  4. 4.Read new comments and review threads; verify bot findings against actual code
  5. 5.Fix any real issues in focused commits and push updates
  6. 6.Re-check PR status after each push until all checks pass and reviews are acceptable
  7. 7.Resolve stale review threads only after confirming the code addresses the comment
  8. 8.Stop when checks pass, review decision is acceptable, and no unresolved threads remain

Use cases

Good for
  • Monitor a long-running CI/CD pipeline while fixing issues in parallel
  • Ensure all review comments are addressed before merging a PR
  • Track a PR through multiple rounds of feedback and fixes
  • Verify generated files match their source before resolving related comments
  • Automate the final sweep of PR status before declaring it merge-ready
Who it's for
  • Developers managing their own PRs through review cycles
  • Teams automating PR validation and merge readiness checks
  • CI/CD pipeline monitors needing continuous PR oversight

babysit FAQ

How often should I poll for check updates?

The default is 30-60 seconds, but you can adjust based on your CI/CD speed. Ask the user if they prefer a different cadence.

Should I resolve review threads automatically?

No. Only resolve threads after verifying the code or generated artifact actually addresses the comment. Treat bot summaries as useful but verify against the actual code.

What if a review thread is marked outdated?

Confirm whether the thread is truly outdated or if the latest head still has the issue. Check the current code before deciding.

How do I know when to stop monitoring?

Stop when: checks are passing or intentionally skipped, review decision is acceptable, no actionable comments remain, and no unresolved review threads exist.

What should I report when done?

Report concrete evidence: latest commit SHA, check names and results, unresolved thread count, tests run, and any uncommitted local changes.

Full instructions (SKILL.md)

Source of truth, from thedotmack/claude-mem.


name: babysit description: Watch a pull request or review cycle until it is ready to merge. Use when asked to babysit, monitor, or keep checking PR comments, reviews, and CI until all actionable issues are resolved.

Babysit PR

Stay with the PR until it is actually clean. Do not stop after one check pass if comments or review threads are still unresolved.

Workflow

  1. Identify the PR number, branch, and base branch.
  2. Confirm the PR is not draft and inspect mergeability, checks, review decision, comments, and review threads.
  3. Watch pending checks until they finish. Poll at a practical interval, usually 30-60 seconds unless the user asks for a different cadence.
  4. Read new comments and unresolved review threads. Treat bot summaries as useful, but verify actionable findings against the code.
  5. Fix real issues in focused commits, run relevant tests/builds, push, and return to step 2.
  6. Resolve stale review threads only after verifying the code or generated artifact now addresses the comment.
  7. Stop only when checks are passing or intentionally skipped, review decision is acceptable, no actionable comments remain, and no unresolved review threads remain.

GitHub CLI Checks

Use gh pr view for the coarse status:

gh pr view <number> --json \
  number,state,isDraft,mergeable,mergeStateStatus,reviewDecision,headRefOid,statusCheckRollup,url

Resolve the repository owner/name before using GraphQL:

repo_json=$(gh repo view --json owner,name)
owner=$(jq -r '.owner.login // .owner.name' <<<"$repo_json")
repo=$(jq -r '.name' <<<"$repo_json")

Use GraphQL for unresolved review threads. Include pageInfo; omit cursor on the first page, then pass the previous endCursor with -f cursor="$cursor" while hasNextPage is true.

gh api graphql \
  -f query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}' \
  -f owner="$owner" -f repo="$repo" -F number=<number>

Use this loop when a PR may have many review threads:

thread_query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}'
cursor_args=()

while :; do
  page=$(gh api graphql -f query="$thread_query" -f owner="$owner" -f repo="$repo" -F number=<number> "${cursor_args[@]}")
  printf '%s\n' "$page" | jq -r '.data.repository.pullRequest.reviewThreads.nodes[]
    | select(.isResolved==false)
    | [.id,.path,(.line//""),(.isOutdated|tostring),(.comments.nodes[-1].author.login//""),(.comments.nodes[-1].body|gsub("\n";" ")|.[0:240])]
    | @tsv'

  jq -e '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' >/dev/null <<<"$page" || break
  cursor=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor' <<<"$page")
  cursor_args=(-f cursor="$cursor")
done

Filter unresolved threads with jq:

jq -r '.data.repository.pullRequest.reviewThreads.nodes[]
  | select(.isResolved==false)
  | [.id,.path,(.line//""),(.isOutdated|tostring),(.comments.nodes[-1].author.login//""),(.comments.nodes[-1].body|gsub("\n";" ")|.[0:240])]
  | @tsv'

Resolve a stale thread only when the fix is verified:

gh api graphql \
  -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{id,isResolved}}}' \
  -f threadId=<thread-id>

Operating Rules

  • Keep the watcher running while long checks are pending.
  • If a generated file is part of the distribution, verify the source and generated artifact agree before resolving comments.
  • If a bot reports an issue against stale code, confirm whether the thread is outdated or addressed in the latest head.
  • Before final reporting, do one fresh sweep of PR status, unresolved threads, recent comments, and local git status.
  • Report concrete evidence: latest commit SHA, check names and results, unresolved thread count, tests run, and any dirty local files left untouched.