Watch Pr

---
description: Watch PR workflows, auto-fix failures, and push until all pass
allowed-tools: Read, Glob, Grep, Edit, Write, Bash, Agent, Skill
---

## Execution model — NON-BLOCKING

**This entire workflow MUST run in the background.** After Step 0 (identifying the PR), launch a **background Agent** (using the Agent tool with `run_in_background: true`) that performs Steps 1–6. This frees the user's conversation immediately — they can keep working while the agent watches CI.

When the background agent completes (either all green or stopped due to safety rails), its result will surface to the user automatically. If the agent needs user input (ambiguous fix, merge conflict, 4th failure), it will stop and the notification will alert the user.

---

You are watching a PR's GitHub Actions **workflow runs** until they all pass. If any workflow fails, you diagnose the failure, fix the code, and push — then continue watching. You stop only when every workflow run succeeds.

**Important**: You are ONLY watching GitHub Actions workflow runs (via `gh run list`), NOT third-party check suites like DeepSource, Greptile, Codecov, etc. Ignore those entirely.

## Step 0: Identify the PR

Determine the current branch and its associated PR:

gh pr view --json number,headRefName,url

If no PR exists for the current branch, stop and tell the user.

Store the PR number and branch name for use in later steps.

## Step 1: Wait for workflows to complete

Poll workflow runs for the current branch. Only look at the **latest push event** runs:

gh run list --branch --event push --limit 20 --json name,status,conclusion,databaseId,workflowName,headSha

Filter to runs matching the **latest commit SHA** on the branch (`git rev-parse HEAD`).

If any runs are still `in_progress`, `queued`, or `pending`, wait **60 seconds** and poll again. Use `sleep 60` between polls.

Continue polling until all workflow runs for the latest commit have a `completed` status.

## Step 2: Check conclusions

Once all runs are `completed`, check their `conclusion` fields:

- If **all conclusions are `success`** (or `skipped`/`neutral`): announce that all workflows passed, print the PR URL, and **stop**.
- If **any conclusion is `failure`**: proceed to Step 3.
- If conclusions are `cancelled` or `timed_out`: report this to the user and **stop** (these aren't code issues).

## Step 3: Diagnose the failure

For each failed run, fetch the failed logs:

gh run view --log-failed

Read the logs carefully. Identify:
1. Which workflow and job failed
2. The specific error message(s)
3. Which file(s) and line(s) are involved

If the logs are too large or unclear, also try:

gh run view --verbose

## Step 4: Fix the issue

Based on the diagnosis:

1. Read the relevant source files
2. Understand the context around the failure
3. Make the minimal fix necessary — do not refactor or clean up unrelated code
4. If the fix is ambiguous or risky (e.g., failing integration test that might be flaky, or a fix that could change behavior), **stop and ask the user** instead of guessing

## Step 5: Commit and push

Stage only the files you changed, commit with a clear message describing the fix, and push:

git add git commit -m "

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com" git push

If the push fails due to remote changes:

git pull --rebase git push

If there are merge conflicts, **stop and ask the user**.

## Step 6: Loop back

After pushing, go back to **Step 1** and wait for the new workflows to run on the fresh commit.

## Safety rails

- **Max 4 fix iterations.** If you've pushed fixes 3 times and workflows fail a 4th time, **alert the user** with a summary of all attempted fixes and their outcomes, then **stop and wait**. Do not continue until the user explicitly triggers `/watch-pr` again.
- **Never force-push.** Always use regular `git push`.
- **Never skip CI checks** (e.g., `[skip ci]` in commit messages).
- **If the same workflow fails twice with the same error after your fix**, stop and present the situation to the user rather than attempting the same fix again.