New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

PR Babysitter

by openinterpreter in openinterpreter/openinterpreter

Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

Apache-2.0Auto-check passedDevelopment

Install PR Babysitter

skills CLI
$ npx skills add openinterpreter/openinterpreter --skill babysit-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install openinterpreter/openinterpreter babysit-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/openinterpreter/openinterpreter.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/babysit-pr .claude/skills/babysit-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
babysit-pr
GitHub stars
69k
Used in
3 other repos
Token cost
~4.2k tokens
SKILL.md length
2,388 words
Files
6 (incl. scripts, references)
Skills in repo
10
Repo updated
First seen
Licence
Apache-2.0

At a glance

Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

  • Works in 12 steps: When the user asks to… → Run the watcher script to snapshot… → Inspect the actions list in the JSON… → …
  • Keeping an eye on CI after opening a pull request
  • SKILL.md covers Objective, Inputs, Core Workflow and Commands, plus 9 more sections
  • Runs Python scripts from its folder; calls gh, python3 and git

What it does

Once a pull request exists, this skill keeps the agent on it. A watcher script snapshots review comments, check runs and mergeability, either once or continuously, and returns a list of suggested actions. The agent works through them until the PR is merged or closed, or until it needs your help with something like CI infrastructure, permissions or repeated flakes.

Failures caused by the branch get patched locally, committed and pushed; failures that look flaky or unrelated are rerun, up to three attempts. Actionable review feedback takes priority over reruns because a new commit restarts CI anyway. The agent does not reply to human reviewers on GitHub without your approval of the exact text, and a green, mergeable, review-clean PR is treated as a milestone rather than a reason to stop watching.

When your agent uses it

  • Keeping an eye on CI after opening a pull request
  • Working through review comments as they arrive
  • Diagnosing and retrying failing checks on a PR

Example prompts

  • “Watch PR 482 and fix anything CI complains about.”
  • “Babysit my open pull request until it's merged.”
  • “Check the failing jobs on this PR and tell me if they're flaky.”

Requirements

  • Access to the repository's pull requests and CI on GitHub

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. When the user asks to "monitor"/"watch"/"babysit" a PR, start with the watcher's continuous mode (--watch) unless you are intentionally…
  2. Run the watcher script to snapshot PR/review/CI state (or consume each streamed snapshot from --watch).
  3. Inspect the actions list in the JSON response.
  4. If diagnose_ci_failure is present, inspect failed run logs and classify the failure.
  5. If the failure is likely caused by the current branch, patch code locally, commit, and push. Do not patch random flaky tests, CI…
  6. If process_review_comment is present, inspect surfaced published review items and decide whether to address them.
  7. If a review item is actionable and correct, patch code locally, commit, push, and then resolve the associated review thread only when…
  8. Do not post replies to human-authored review comments/threads unless the user explicitly confirms the exact response. If a human review…
  9. If the failure is likely flaky/unrelated and retry_failed_checks is present, rerun failed jobs with --retry-failed-now.
  10. If both actionable review feedback and retry_failed_checks are present, prioritize review feedback first; a new commit will retrigger CI…
  11. On every loop, look for newly surfaced review feedback before acting on CI failures or mergeability state, then verify mergeability /…
  12. After any push or rerun action, immediately return to step 1 and continue polling on the updated SHA/state.

What it can do on your machine

Read from SKILL.md and the folder at commit cc054cf. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 2 files in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • gh
    • python3
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

PR Babysitter loads about 4.2k tokens when it runs, and up to ~5.6k if it reads all its reference files. Until then it costs about 131 tokens; SKILL.md has 2,388 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~131
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from openinterpreter/openinterpreter at commit cc054cf, republished under its Apache-2.0 licence (© openinterpreter). 2,388 words, ~4,215 tokens.

Download SKILL.mdSave it as .claude/skills/babysit-pr/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
babysit-pr
description
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep watching open PRs so fresh review feedback is surfaced promptly. Use when the user asks Codex to monitor a PR, watch CI, handle review comments, or keep an eye on failures and feedback on an open PR.

PR Babysitter

Objective

Babysit a PR persistently until one of these terminal outcomes occurs:

  • The PR is merged or closed.
  • A situation requires user help (for example CI infrastructure issues, repeated flaky failures after retry budget is exhausted, permission problems, or ambiguity that cannot be resolved safely).
  • Optional handoff milestone: the PR is currently green + mergeable + review-clean. Treat this as a progress state, not a watcher stop, so late-arriving review comments are still surfaced promptly while the PR remains open.

Do not stop merely because a single snapshot returns idle while checks are still pending.

Inputs

Accept any of the following:

  • No PR argument: infer the PR from the current branch (--pr auto)
  • PR number
  • PR URL

Core Workflow

  1. When the user asks to "monitor"/"watch"/"babysit" a PR, start with the watcher's continuous mode (--watch) unless you are intentionally doing a one-shot diagnostic snapshot.
  2. Run the watcher script to snapshot PR/review/CI state (or consume each streamed snapshot from --watch).
  3. Inspect the actions list in the JSON response.
  4. If diagnose_ci_failure is present, inspect failed run logs and classify the failure.
  5. If the failure is likely caused by the current branch, patch code locally, commit, and push. Do not patch random flaky tests, CI infrastructure, dependency outages, runner issues, or other failures that are unrelated to the branch.
  6. If process_review_comment is present, inspect surfaced published review items and decide whether to address them.
  7. If a review item is actionable and correct, patch code locally, commit, push, and then resolve the associated review thread only when allowed by the GitHub state mutation policy below.
  8. Do not post replies to human-authored review comments/threads unless the user explicitly confirms the exact response. If a human review item is non-actionable, already addressed, or not valid, surface the item and recommended response to the user instead of replying on GitHub.
  9. If the failure is likely flaky/unrelated and retry_failed_checks is present, rerun failed jobs with --retry-failed-now.
  10. If both actionable review feedback and retry_failed_checks are present, prioritize review feedback first; a new commit will retrigger CI, so avoid rerunning flaky checks on the old SHA unless you intentionally defer the review change.
  11. On every loop, look for newly surfaced review feedback before acting on CI failures or mergeability state, then verify mergeability / merge-conflict status (for example via gh pr view) alongside CI.
  12. After any push or rerun action, immediately return to step 1 and continue polling on the updated SHA/state.
  13. If you had been using --watch before pausing to patch/commit/push, relaunch --watch yourself in the same turn immediately after the push (do not wait for the user to re-invoke the skill).
  14. Repeat polling until stop_pr_closed appears or a user-help-required blocker is reached. A green + review-clean + mergeable PR is a progress milestone, not a reason to stop the watcher while the PR is still open.
  15. Maintain terminal/session ownership: while babysitting is active, keep consuming watcher output in the same turn; do not leave a detached --watch process running and then end the turn as if monitoring were complete.

Commands

One-shot snapshot
bash
python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --once
Continuous watch (JSONL)
bash
python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --watch
Trigger flaky retry cycle (only when watcher indicates)
bash
python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --retry-failed-now
Explicit PR target
bash
python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr <number-or-url> --once

CI Failure Classification

Use gh commands to inspect failed runs before deciding to rerun.

  • gh run view <run-id> --json jobs,name,workflowName,conclusion,status,url,headSha
  • gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs -X GET -f per_page=100
  • gh api repos/<owner>/<repo>/actions/jobs/<job-id>/logs > /tmp/codex-gh-job-<job-id>-logs.zip
  • gh run view <run-id> --log-failed as a fallback after the overall workflow run is complete

gh run view --log-failed is workflow-run scoped and may not expose failed-job logs until the overall run finishes. For faster diagnosis, poll the run's jobs first and, as soon as a specific job has failed, fetch that job's logs directly from the Actions job logs endpoint. The watcher includes a failed_jobs list with each failed job's job_id and logs_endpoint when GitHub exposes one.

Prefer treating failures as branch-related when failed-job logs point to changed code (compile/test/lint/typecheck/snapshots/static analysis in touched areas).

Prefer treating failures as flaky/unrelated when logs show transient infra/external issues (timeouts, runner provisioning failures, registry/network outages, GitHub Actions infra errors).

Do not attempt to fix flaky/unrelated failures by changing tests, build scripts, CI configuration, dependency pins, or infrastructure-adjacent code unless the logs clearly connect the failure to the PR branch. For flaky/unrelated failures, rerun only when the watcher recommends retry_failed_checks; otherwise wait or stop for user help.

If classification is ambiguous, perform one manual diagnosis attempt before choosing rerun.

Read .codex/skills/babysit-pr/references/heuristics.md for a concise checklist.

Review Comment Handling

The watcher surfaces review items from:

  • PR issue comments
  • Inline review comments
  • Review submissions (COMMENT / APPROVED / CHANGES_REQUESTED)

Only act on published feedback. Ignore review submissions in GitHub's PENDING state and inline comments attached to those pending reviews. Do not mark pending review feedback as seen; it should be eligible to surface after the reviewer submits the review.

It intentionally surfaces Codex reviewer bot feedback (for example comments/reviews from chatgpt-codex-connector[bot]) in addition to human reviewer feedback. Most unrelated bot noise should still be ignored. For safety, the watcher only auto-surfaces trusted human review authors (for example repo OWNER/MEMBER/COLLABORATOR, plus the authenticated operator) and approved review bots such as Codex. On a fresh watcher state file, existing unaddressed published review feedback may be surfaced immediately (not only comments that arrive after monitoring starts). This is intentional so already-open review comments are not missed.

When you agree with a comment and it is actionable:

  1. Patch code locally.
  2. Commit with codex: address PR review feedback (#<n>).
  3. Push to the PR head branch.
  4. After the push succeeds, resolve the associated GitHub review thread only when allowed by the GitHub state mutation policy below.
  5. Resume watching on the new SHA immediately (do not stop after reporting the push).
  6. If monitoring was running in --watch mode, restart --watch immediately after the push in the same turn; do not wait for the user to ask again.

Do not post replies to human-authored GitHub review comments/threads automatically. If you disagree with a human comment, believe it is non-actionable/already addressed, or need to answer a question, report the item to the user with a suggested response and wait for explicit confirmation before posting anything on GitHub. If the user approves a response, prefix it with [codex] so it is clear the response is automated and not from the human user. If the watcher later surfaces your own approved reply because the authenticated operator is treated as a trusted review author, treat that self-authored item as already handled and do not reply again. If a code review comment/thread is already marked as resolved in GitHub, treat it as non-actionable and safely ignore it unless new unresolved follow-up feedback appears.

GitHub State Mutation Policy

You can read any PR state you need for monitoring. Writes must comply with this policy.

You can push PRs to update the code under review or to force CI re-runs as described above.

You can resolve review comment threads from the human who requested babysitting or from the Codex review bot. When resolving, leave a comment prefixed with [from Codex]: and explain what changes you made and which commit includes them. Don't touch review threads if other humans other than the user who requested babysitting have participated.

Before making any changes, fetch the PR state yourself instead of relying on the PR watcher script's output.

Unless explicitly asked, do not:

  • comment on other humans' review threads, communicate with the user in chat instead
  • resolve review threads from humans other than the user
  • interact with humans other than the user
  • mark PRs as drafts or ready for review
  • close or reopen PRs

In general, never act on GitHub in ways that would make it hard to tell whether you or the user did something visible to other humans. When in doubt, ask the user for clarification in chat.

Git Safety Rules

  • Work only on the PR head branch.
  • Avoid destructive git commands.
  • Do not switch branches unless necessary to recover context.
  • Before editing, check for unrelated uncommitted changes. If present, stop and ask the user.
  • After each successful fix, commit and git push, then re-run the watcher.
  • If you interrupted a live --watch session to make the fix, restart --watch immediately after the push in the same turn.
  • Do not run multiple concurrent --watch processes for the same PR/state file; keep one watcher session active and reuse it until it stops or you intentionally restart it.
  • A push is not a terminal outcome; continue the monitoring loop unless a strict stop condition is met.

Commit message defaults:

  • codex: fix CI failure on PR #<n>
  • codex: address PR review feedback (#<n>)
Show full SKILL.md (956 more words)Show less

Monitoring Loop Pattern

Use this loop in a live Codex session:

  1. Run --once.
  2. Read actions.
  3. First check whether the PR is now merged or otherwise closed; if so, report that terminal state and stop polling immediately.
  4. Check CI summary, new review items, and mergeability/conflict status.
  5. Diagnose CI failures and classify branch-related vs flaky/unrelated. If the overall run is still pending but failed_jobs already includes a failed job, fetch that job's logs and diagnose immediately instead of waiting for the whole workflow run to finish. Patch only when the failure is branch-related.
  6. For each surfaced review item from another author, patch/commit/push if it is actionable, then resolve it only when allowed by the GitHub state mutation policy above. If it is non-actionable, already addressed, or requires a written answer, surface it to the user with a suggested response instead of posting automatically. If a later snapshot surfaces your own approved reply, treat it as informational and continue without responding again.
  7. Process actionable review comments before flaky reruns when both are present; if a review fix requires a commit, push it and skip rerunning failed checks on the old SHA.
  8. Retry failed checks only when retry_failed_checks is present and you are not about to replace the current SHA with a review/CI fix commit. Do not make code changes for unrelated flakes or infrastructure failures just to get CI green.
  9. If you pushed a commit, resolved an eligible review thread, or triggered a rerun, report the action briefly and continue polling (do not stop). If a human review comment needs a written GitHub response, stop and ask for confirmation before posting.
  10. After a review-fix push, proactively restart continuous monitoring (--watch) in the same turn unless a strict stop condition has already been reached.
  11. If everything is passing, mergeable, not blocked on required review approval, and there are no unaddressed review items, report that the PR is currently ready to merge but keep the watcher running so new review comments are surfaced quickly while the PR remains open.
  12. If blocked on a user-help-required issue (infra outage, exhausted flaky retries, unclear reviewer request, permissions), report the blocker and stop.
  13. Otherwise sleep according to the polling cadence below and repeat.

When the user explicitly asks to monitor/watch/babysit a PR, prefer --watch so polling continues autonomously in one command. Use repeated --once snapshots only for debugging, local testing, or when the user explicitly asks for a one-shot check. Do not stop to ask the user whether to continue polling; continue autonomously until a strict stop condition is met or the user explicitly interrupts. Do not hand control back to the user after a review-fix push just because a new SHA was created; restarting the watcher and re-entering the poll loop is part of the same babysitting task. If a --watch process is still running and no strict stop condition has been reached, the babysitting task is still in progress; keep streaming/consuming watcher output instead of ending the turn.

Polling Cadence

Keep review polling aggressive and continue monitoring even after CI turns green:

  • While CI is not green (pending/running/queued or failing): poll every 1 minute.
  • After CI turns green: keep polling at the base cadence while the PR remains open so newly posted review comments are surfaced promptly instead of waiting on a long green-state backoff.
  • Reset the cadence immediately whenever anything changes (new commit/SHA, check status changes, new review comments, mergeability changes, review decision changes).
  • If CI stops being green again (new commit, rerun, or regression): stay on the base polling cadence.
  • If any poll shows the PR is merged or otherwise closed: stop polling immediately and report the terminal state.

Stop Conditions (Strict)

Stop only when one of the following is true:

  • PR merged or closed (stop as soon as a poll/snapshot confirms this).
  • User intervention is required and Codex cannot safely proceed alone.

Keep polling when:

  • actions contains only idle but checks are still pending.
  • CI is still running/queued.
  • Review state is quiet but CI is not terminal.
  • CI is green but mergeability is unknown/pending.
  • CI is green and mergeable, but the PR is still open and you are waiting for possible new review comments or merge-conflict changes.
  • The PR is green but blocked on review approval (REVIEW_REQUIRED / similar); continue polling at the base cadence and surface any new review comments without asking for confirmation to keep watching.

Output Expectations

Provide concise progress updates while monitoring and a final summary that includes:

  • During long unchanged monitoring periods, avoid emitting a full update on every poll; summarize only status changes plus occasional heartbeat updates.

  • Treat push confirmations, intermediate CI snapshots, ready-to-merge snapshots, and review-action updates as progress updates only; do not emit the final summary or end the babysitting session unless a strict stop condition is met.

  • A user request to "monitor" is not satisfied by a couple of sample polls; remain in the loop until a strict stop condition or an explicit user interruption.

  • A review-fix commit + push is not a completion event; immediately resume live monitoring (--watch) in the same turn and continue reporting progress updates.

  • When CI first transitions to all green for the current SHA, emit a one-time celebratory progress update (do not repeat it on every green poll). Preferred style: 🚀 CI is all green! 33/33 passed. Still on watch for review approval.

  • Do not send the final summary while a watcher terminal is still running unless the watcher has emitted/confirmed a strict stop condition; otherwise continue with progress updates.

  • Final PR SHA

  • CI status summary

  • Mergeability / conflict status

  • Fixes pushed

  • Flaky retry cycles used

  • Remaining unresolved failures or review comments

References

  • Heuristics and decision tree: .codex/skills/babysit-pr/references/heuristics.md
  • GitHub CLI/API details used by the watcher: .codex/skills/babysit-pr/references/github-api-notes.md

© openinterpreter, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (scripts, references) in .codex/skills/babysit-pr of openinterpreter/openinterpreter.

  • SKILL.md
  • agents/openai.yaml
  • references/github-api-notes.md
  • references/heuristics.md
  • scripts/gh_pr_watch.py
  • scripts/test_gh_pr_watch.py

Open the folder on GitHubat commit cc054cf

Used in 3 other repositories

We found 3 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 3 other GitHub owners. This page covers the copy in openinterpreter/openinterpreter, which our catalogue first saw on October 7, 2026.

Compare with similar skills

PR Babysitter next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

PR Babysitter compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
PR Babysitter this skillopeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Renovate Actions PR Reviewbacknotprop/plannotator9.2k—~640Automated safety check: PassApache-2.0
ReviewdogAgentSecOps/SecOpsAgentKit2191 repos~3kAutomated safety check: PassCustom licence
Pull Request Babysitterthedotmack/claude-mem97k—~1.1kAutomated safety check: PassApache-2.0
GitHub Copilot PR Finishergithub/gh-aw5.3k—~3.8kAutomated safety check: WarnMIT
Reviewing Changesbitwarden/ios694—~1.1kAutomated safety check: PassGPL-3.0

Similar skills

  • Renovate Actions PR Review

    backnotprop/plannotator

    Reviews Renovate pull requests that bump GitHub Actions by checking pinned SHAs against upstream tags, scanning changelogs and confirming workflows stay compatible.

    9.2k GitHub stars~640 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Reviewdog

    AgentSecOps/SecOpsAgentKit

    Automated code review and security linting integration for CI/CD pipelines using reviewdog.

    219 GitHub starsUsed in 1 repo~3k tokens
    DevelopmentAuto-check passed

  • Pull Request Babysitter

    thedotmack/claude-mem

    Keeps watching a pull request, fixing real review and CI problems and resolving stale threads, until it is clean and ready to merge.

    97k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed

  • GitHub Copilot PR Finisher

    github/gh-aw

    Official

    Drives an open pull request to merge-ready from inside a GitHub Copilot cloud agent, resolving review threads and local checks concurrently, without merging or retriggering CI.

    5.3k GitHub stars~3.8k tokensUpdated today
    DevelopmentAuto-check: warnings

  • Reviewing Changes

    bitwarden/ios

    Official

    Performs comprehensive code reviews for Bitwarden iOS projects, verifying architecture compliance, style guidelines, compilation safety, test coverage, and security requirements.

    694 GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed

  • Diagnosing CI And Merge Bottlenecks

    PostHog/posthog-foss

    Official

    Diagnoses CI and pull-request pipeline health for a GitHub repo using the engineering analytics MCP tools — pull-requests (PR list with CI status), workflow-health (per-workflow CI trends), and…

    721 GitHub stars~3.7k tokensUpdated today
    DevelopmentAuto-check passed

More from openinterpreter/openinterpreter

All 10 skills in this repo

  • Update V8 Version

    openinterpreter/openinterpreter

    Bumps the pinned v8 and rusty_v8 versions in Codex, validates the release-candidate path with the v8-canary check, and traces failures to upstream build changes.

    69k GitHub starsUsed in 2 repos~845 tokens
    Auto-check passed

  • Pull Request Title and Body Writer

    openinterpreter/openinterpreter

    Rewrites the title and body of one or more pull requests with gh, leading with why the change was made, then what changed, and describing only the net result.

    69k GitHub starsUsed in 2 repos~1.1k tokens
    Auto-check passed

  • Remote Executor Integration Tests

    openinterpreter/openinterpreter

    Explains how to run agent integration tests against remote executors, using Docker for Linux or Wine for Windows, and how to opt tests in or skip them.

    69k GitHub starsUsed in 2 repos~842 tokens
    Auto-check passed

  • Rust Path Types

    openinterpreter/openinterpreter

    Rules for choosing Rust types for filesystem paths in new Codex code, covering protocol types, internal use and model tool arguments.

    69k GitHub starsUsed in 2 repos~605 tokens
    Auto-check passed

  • Codex TUI Testing

    openinterpreter/openinterpreter

    Guide for testing Codex TUI interactively

    69k GitHub starsUsed in 2 repos~133 tokens
    Auto-check passed

Works with

Categories

Questions about PR Babysitter

What does PR Babysitter do?

Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way. Once a pull request exists, this skill keeps the agent on it. A watcher script snapshots review comments, check runs and mergeability, either once or continuously, and returns a list of suggested actions.

When should I use PR Babysitter?

PR Babysitter fits situations like: keeping an eye on CI after opening a pull request; working through review comments as they arrive; diagnosing and retrying failing checks on a PR.

How do I install PR Babysitter in Claude Code?

Run `npx skills add openinterpreter/openinterpreter --skill babysit-pr -a claude-code`. Or copy the skill folder (.codex/skills/babysit-pr in openinterpreter/openinterpreter) into .claude/skills/babysit-pr in your project. Claude Code loads it when a task matches its description.

How do I install PR Babysitter in Codex?

Run `npx skills add openinterpreter/openinterpreter --skill babysit-pr -a codex`. Or copy the skill folder (.codex/skills/babysit-pr in openinterpreter/openinterpreter) into .agents/skills/babysit-pr in your project. Codex loads it when a task matches its description.

Can I use PR Babysitter in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add openinterpreter/openinterpreter --skill babysit-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/babysit-pr, .gemini/skills/babysit-pr, .github/skills/babysit-pr and .opencode/skills/babysit-pr in your project.

What does PR Babysitter need to run?

Going by SKILL.md and its folder, PR Babysitter needs Python for the scripts in its folder and the command-line tools its instructions call (gh, python3 and git). Our summary lists: Access to the repository's pull requests and CI on GitHub.

Does PR Babysitter access the network?

SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is PR Babysitter safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does PR Babysitter use?

PR Babysitter is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does PR Babysitter use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.4k tokens, read only when the agent opens those files.

What are the alternatives to PR Babysitter?

Skills that share tags, products or a category with PR Babysitter: Renovate Actions PR Review (backnotprop/plannotator, 9.2k stars), Reviewdog (AgentSecOps/SecOpsAgentKit, 219 stars), Pull Request Babysitter (thedotmack/claude-mem, 97k stars) and GitHub Copilot PR Finisher (github/gh-aw, 5.3k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains PR Babysitter?

openinterpreter (a GitHub organization) maintains it in openinterpreter/openinterpreter, which has 68,517 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on October 7, 2026.

Source: openinterpreter/openinterpreter on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.