pr-autoloop

PR Autoloop

PR の作成後、人がポーリングを再開することなく、エージェントによる PR メンテナンスループを自動的に終端状態まで進めます。このスキルは Codex と Claude Code で共有されます。異なるのはブロックしない待機方式だけで、各エージェントのガイドで扱います（「エージェントごとの待機方式」を参照）。

これは目標ベースの停止条件を備えた、時間制限付きループです。一定間隔で外部システム（GitHub の PR 状態）をポーリングし、CI、レビュー、マージ可能性の状態が変化したら対応して、マージ、エスカレーション、タイムアウトのいずれかに達した場合にのみ停止します。汎用的な自律型コーディングループとして使用しないでください。これは、明確に定義された PR メンテナンスワークフローのためのものです。

pr-maintainer との関係

このスキルは自律ループ層です。ポリシーは定義しません。

• すべてのポリシー（ドラフトの条件、修正ルール、修正ループの上限（4）、日本語でのレビュー返信、設計上のエスカレーション、マージ条件、マージ後のワークツリーのクリーンアップ）は、pr-maintainer スキルと、存在する場合はリポジトリの PR メンテナンス ADR／ポリシーに従います。
• このスキルで定めるのは、終端状態に達するまでループを自動的に継続する方法の契約だけです。

ここに記載された内容が pr-maintainer と矛盾するように見える場合、ポリシーについては pr-maintainer を優先し、「ポーリングの間、人が対応するのを待って停止しない」ことについてのみ、このスキルを適用します。

使用するタイミング

次のいずれかに当てはまる場合は、すぐに使用してください。

• このエージェントが PR を作成したばかりの場合（gh pr create）。ワークフローの指示により作成したドラフトも含みます。
• ドラフトのエージェント PR がレビュー可能な状態になった場合（ユーザーによる手動の切り替えも含みます）。
• ユーザーが、エージェントの作成した PR について、CI、レビュー、修正、マージまで進める、または完了するよう求めた場合。

まず pr-maintainer の「ドラフトを残さない」という事後条件を適用し（レビュー可能な状態なら PR をレビュー可能にします）、その後ループに入ります。PR がレビュー可能な状態になったら、PR の URL を提示して停止しないでください。

Autoloop Contract (agent-agnostic)

Treat maintenance as a self-paced poll loop. One loop cycle:

1. Gather state with gh - all four checks are mandatory every cycle; never skip based on CI status:

   # (a) PR fields - isDraft, mergeStateStatus, reviewDecision, head SHA
   gh pr view "$PR" --repo "$REPO" \
     --json number,isDraft,headRefOid,mergeStateStatus,reviewDecision,statusCheckRollup,labels
   
   # (b) Check run statuses
   gh pr checks "$PR" --repo "$REPO" \
     --json name,state,bucket,link,startedAt,completedAt,workflow
   
   # (c) Bot reactions on the PR issue (Codex signals: +1=clean, eyes=in-progress)
   gh api --paginate "repos/$REPO/issues/$PR_NUM/reactions?per_page=100"
   
   # (d) Inline review comments - detect P1/P2 badge findings from Codex
   gh api --paginate "repos/$REPO/pulls/$PR_NUM/comments?per_page=100"
   

   $REPO is owner/repo (e.g. your-org/your-repo). mergeStateStatus=CLEAN means GitHub merge preconditions pass; it does not mean bot review is complete.

2. Classify the cycle into exactly one outcome:

   • continue - any of these: CI checks still running (step b has pending checks); no chatgpt-codex-connector[bot] reaction yet on the PR issue (step c is empty or only eyes); CI is green but Codex review/reaction has not posted yet → schedule the next cycle.

   • repair - any of these: CI checks failed (step b); Codex review state is COMMENTED and step d contains P1/P2 badge findings → fix in the PR worktree, validate, push, reply in Japanese per pr-maintainer, then continue (count the repair against the limit).

   • escalate - repair limit reached, recurring findings in the same boundary, or a forbidden change is required → open the design issue, comment in Japanese, stop.

   • merge - all of the following are true (verified from step 1 data above):

     1. CI: all required checks pass (step b - no failed or pending).
     2. Draft: isDraft == false (step a).
     3. Codex reaction: chatgpt-codex-connector[bot] has a +1 reaction on the PR issue (step c). eyes alone → continue, not merge.
     4. No blocking findings: step d has no unaddressed P1/P2 Codex comments.

     ⚠️ mergeStateStatus=CLEAN with reviewDecision="" alone does not satisfy this gate. → squash merge, clean up the worktree, stop.

   • timeout - total elapsed reached the polling window with no terminal result → comment in Japanese that CI/review did not complete in the window, stop.

3. If the outcome is continue, wait the poll interval and start the next cycle automatically.

The stop condition is not a prose judgment such as "the PR looks good". It is the conjunction of observable predicates gathered through gh: CI is green, the PR is not draft, the expected bot review artifact exists, no blocking findings remain, merge preconditions are clean, and the checked head SHA is still current.

Loop parameters

• Poll interval: about 3 minutes between cycles.
• Polling window: at most 20 minutes total (about 6-7 cycles).
• Keep loop count and the last checked head SHA in session memory; track repair count with a todo.
• Never let the loop idle waiting for a human to manually re-trigger the next poll. The whole point of this skill is that "continue" reschedules itself.

Per-Agent Wait Mechanism

The only agent-specific part is how you wait the poll interval without blocking your runtime. Do not hardcode a single mechanism here; follow your agent guide:

• Claude Code → ScheduleWakeup self-pacing; fallback bounded bash until loop; never sleep && <next>.
• Codex → inline session polling (no ScheduleWakeup). Keep the loop inside the active session and report the terminal state instead of relying on a platform routine to wake the agent later.

導入先の CLAUDE.md / AGENTS.md に wait 機構のセクション (例: "pr-autoloop 実装") があれば それを優先する。無ければ上のデフォルトに従い、どの機構を使ったか報告する。

Stop Conditions

Stop the loop (and report the final monitored state) on merge, escalate, or timeout. Do not merge on continue, and do not treat an empty review/comment set as a clean review (it means "review not completed yet" per pr-maintainer).

References

• pr-maintainer skill - policy this skill executes.
• The repository's PR maintenance ADR/policy doc, if one exists (for example under docs/decisions/).
• 導入先の CLAUDE.md / AGENTS.md - per-agent wait mechanism のプロジェクト上書き (任意)。