はじめに
最近、Pull Requestを作成してから、実際にレビューを依頼できるところになるまで、下手したら数時間かかることがあります。
自分の中で、これがスピードが上がらない理由の大きな1つになっていました。
原因は、Pull Requestを作成すると自動的に走る各AgentのレビューとGitHub Actionの対応でした。「レビュー・GitHub Actionsの結果が来る -> Claude Code にリンクを貼り付けて対応する -> Pushする -> 再度レビュー・GitHub Actionsの結果が来る...」の無限ループをやっていたからです。
これ、もっと自動化できるだろうな〜とは思ってClaude Codeにそんなシステムを作らせたりもしたのですが、意外とサクッとできなくて放置していました。
そんな中、最近Claude Codeに /loop が導入されて、ちょっと覗いてみると、"babysit a PR" とまさに私がやりたいことが、できそうでした。
Scheduled tasks let Claude re-run a prompt automatically on an interval. Use them to poll a deployment, babysit a PR, check back on a long-running build, or remind yourself to do something later in the session.
以下の内容は、Claude Code: Run prompts on a scheduleのページの内容をもとに、私が実際に作ったLoopのお話です。
TL;DR
- Claude Code の
/loopは、プロンプトやスラッシュコマンドを繰り返し実行させる仕組みです - 間隔を指定するモードと、AIが自分でタイミングを決める動的ペースモードがあります
- これを使って、PRのレビューコメントとCI失敗が片付くまで世話する自作スキル
babysit-prを作りました-
/loop /babysit-pr <PR URL>の1コマンドで回せるようになりました
-
そもそも /loop とは
/loop は、同じプロンプトを繰り返し実行させる ClaudeCode の機能です。
公式ドキュメントでは以下のような例が挙げられています
- デプロイの状況を定期的にチェックする
- Pull Requestのベビーシッターをする(進み具合を見守る)
- 時間のかかるビルドの完了を後から確認する
- セッション中に「後でこれをやる」と自分にリマインドを送る
「5分ごとにデプロイを見て」「コメントが尽きるまで対応して」みたいな繰り返し作業を任せられるようになります。
一旦はLoopではポーリングを基本とするのですが、Channelsという、Webhookのような仕組みもあるようです。
今回はサクッと作りたいので、とりあえずLoopを使います。
また、/goal と言って、定期的に実行するのでなく、特定の条件を達成するまで実行するものもあります。
今回やりたいのは、ちょっと待ってから再度確認作業をすることになるので、待つ作業を期間に設定できるLoopが良さそうです。
私はSkillと相性がいいかなと思っていて、特定のワークフローを定義したSkillを、Loopで回すことを想定しています。
Loopの開始方法
3パターンあります。
1. 間隔を指定して回す
/loop 5m check the deploy
- 先頭の
5mが間隔。30s,10m,1h,1d,every 2 hoursのように指定する - そのあとに繰り返したいプロンプトやスラッシュコマンドを置く
- 内部では cron 式に変換されて、セッションが開いている間だけ動く
2. 動的ペース(間隔なし)
/loop check the deploy
- 間隔を省くと、AIが状況を見て、毎回の実行時に、次の実行タイミングを毎回1分〜1時間の間で自分で決めてくれる
- CI完了やPRコメント追加みたいな「イベント待ち」と相性がいい
- イベントが起きたら即起動し、何もなければ長めのフォールバックで様子を見る、というように動作
3. 完全自動(メンテナンスプロンプト)
/loop
- プロンプトも間隔も、指定しないモード
- 会話の続き(未完のPR、失敗したCI、未対応のレビューコメント)を自動で前に進める「お守り」モード
- 離席中に作業を進めておきたいとき向け
-
loop.mdでデフォルトの動きを自分用にカスタマイズできる
ドキュメントのloop.mdでは以下のように、Pull Requestを見守るものが紹介されています。
Check the
release/nextPR. If CI is red, pull the failing job log, diagnose, and push a minimal fix. If new review comments have arrived, address each one and resolve the thread. If everything is green and quiet, say so in one line.
Loopの停止方法
-
Escを押下 - 7日経った (デフォルトでは7日経つとどんなLoopも自動的に停止されます)
実際に作ったスキル: babysit-pr
スキルはいつもmattpocock - write-a-skillを使って作っています。
/handle-reviews というレビューに対応するSkillがすでにあって、それを中で実行するようにしています。
私は常に確認しながら作業をしたいので、各ステップで確認を求めるように依頼しています。
---
name: babysit-pr
description: Babysit the current branch's PR or user specified PR until it's merge-ready by looping over review comments and CI failures. Handles bot reviews from Claude Code, Codex, and Copilot (Draft PRs included), diagnoses and fixes GitHub Actions failures (re-enqueues flakes), confirms each cycle with the user, and waits for re-reviews and CI runs via a Monitor. Use when the user wants to get a PR ready to merge, clear all review comments, fix CI until green, or says "babysit this PR".
---
# Babysit PR
Drives the current branch's PR to merge-ready by looping over two things until both are clean: unresolved review comments and failing CI.
## Quick start
- Detect the current branch's PR via the SCM CLI (for GitHub: `gh pr view --json number,isDraft,url`).
- If no PR exists, say so in one line and stop.
- Otherwise start the cycle loop below.
## Behavior (fixed)
- Reviewers in scope: Claude Code, Codex, Copilot. All of them.
- Draft PRs count. Claude Code reviews drafts too, so don't skip on draft status.
- Confirm before fixing. handle-reviews confirms review fixes; babysit confirms CI fixes and any push.
- Pacing is event-driven. Don't poll on a tight interval.
babysit-pr is the orchestrator. It owns the loop, CI, push, thread resolution, and pacing.
Review triage, user confirmation, and per-item commits belong to the `handle-reviews` skill. Don't reimplement them here.
1. Gather the current state of the PR:
- Whether any review thread is unresolved (a count is enough; `handle-reviews` fetches the details).
- CI status (for GitHub: `gh pr checks`).
- Whether the branch has fallen behind base.
2. If there are no unresolved comments, CI is green, and the branch is up to date:
- Wait one re-review/CI window (see Pacing) in case bots or runners are still working.
- Still clean after the wait, stop and report the PR is merge-ready.
3. Reviews: if any thread is unresolved, delegate to the `handle-reviews` skill, passing the PR URL.
- It owns triage, the user confirmation, and the per-item commits.
- Don't re-triage or re-confirm reviews here. That's double work and a double prompt.
4. CI: for each failure, pull the failing job's logs and diagnose.
- Flaky-shaped (timeout, runner died, transient network): re-enqueue the job.
- Real failure: reproduce, then present the fix plan and wait for approval. CI fixes are babysit's to confirm, not handle-reviews'.
5. After handle-reviews commits and any approved CI fixes land:
- Before pushing, check whether someone else pushed to the branch. If so, rebase, don't merge. If the branch is behind base, rebase onto base.
- Push. handle-reviews never pushes, so this is babysit's job.
- Resolve the review threads that were addressed. handle-reviews doesn't resolve them.
6. The bots re-review and CI re-runs. Go back to step 1.
## Pacing
- After a cycle, arm a Monitor with `persistent: true` watching the PR for new comments and CI completion.
- New comments or finished CI runs wake the loop immediately. Don't wait on a fixed timer.
- Set a long fallback wakeup (1200 to 1800 seconds) as a safety net only.
- On later cycles, call TaskList first and skip arming if a Monitor is already running.
## Stop conditions
- Reviews clean, CI green, branch up to date, and the re-review/CI wait turns up nothing new.
- The user declines a proposed fix and tells you to stop.
- A CI failure isn't flaky and isn't fixable without a decision the user needs to make. Report it and wait.
- Stop the Monitor (TaskStop) when the loop ends.
これを以下のようにLoopで回すと、全てのコメント・CIに対応するまで待機してくれます。
/loop /babysit-pr <PR URL>
おわりに
自作スキルと組み合わせると「PRを世話する」みたいな複数ステップの作業をまるごと任せられそうです。
まだ、作ったばかりなので、改善していけたらと思います。