babysit-pr

Files (3)

• SKILL.md
• fetch-failed-logs.sh · scripts/
• pr-status.sh · scripts/

SKILL.md (first lines)

# Babysit PR

You are an autonomous PR agent. Your goal is to get the current branch's PR into a human-reviewable state by fixing CI failures and addressing automated review comments (Copilot and SonarCloud). Do not stop until either the PR is fully green with no unresolved bot review threads, or you hit a problem requiring human input.

## Assess PR Status

Run the status script to get a snapshot of CI checks and bot review threads:

```bash
${CLAUDE_SKILL_DIR}/scripts/pr-status.sh $ARGUMENTS
```

Fallback: `~/.claude/skills/babysit-pr/scripts/pr-status.sh $ARGUMENTS`

The script accepts an optional PR number argument. If `$ARGUMENTS` is empty, it auto-detects from the current branch.

Parse the JSON output and determine the current state:

- **All checks passed + no unresolved bot threads** → Skip to Final Check
- **Checks still pending/in-progress** → Start polling CI, but also immediately fix any Copilot or SonarCloud reviews that have already been posted — do not wait for CI to finish before addressing bot comments
- **Checks failed** → Go to Fix CI Failures
- **Checks passed but unresolved bot threads** → Go to Resolve SonarCloud / Resolve Copilot

## Poll CI

Use the `/loop` skill (a built-in Claude Code skill that runs a prompt on a recurring interval) to poll for CI completion. Invoke it as `/loop 5m` with the polling logic below. On each iteration, run `pr-status.sh` and check:

- If checks are still pending, report which checks are running and wait for the next iteration.
- If a check has failed, stop the loop and proceed to Fix CI Failures.
- If all checks have passed, stop the loop and proceed to Resolve SonarCloud / Resolve Copilot (if any unresolved threads remain).

**Stale review detection**: After each push, record the UTC time. The `pr-status.sh` output includes `copilot.latest_review_at` — only act on Copilot reviews where this timestamp is newer than your last push time. Copilot and SonarCloud re-analyze after each push, so acting on stale comments from a previous push wastes effort. If the review is current (posted after the latest push), address it immediately — do not wait for CI to finish first.

## Fix CI Failures

For each failed check from the status output:

### Fetch the logs

```bash
${CLAUDE_SKILL_DIR}/scripts/fetch-failed-logs.sh "<check-name>" "<check-link>"
```

Fallback: `~/.claude/skills/babysit-pr/scripts/fetch-failed-logs.sh`

### Triage: flaky vs stale branch vs real failure

Before attempting a fix, determine the failure type:

1. **Flaky test**: Compare the failing test against files changed in this PR (`git diff --name-only origin/master...HEAD`). If the failing test is unrelated to any changed file, it is likely flaky.
   - Retry the failed job:
     - **GitHub Actions**: Extract the run ID from the check `link` field (e.g., `runs/12345`) and run `gh run rerun <run-id> --failed`
     - **Buildkite**: Parse org, pipeline, and build number from the check `link` field (URL format: `buildkite.com/<org>/<pipeline>/builds/<build>`). Then fetch the build to get the failed job UUID:
       ```bash
       source ~/env.source
       # Get failed job ID from build
       JOB_ID=$(curl -sH "Authorization: Bearer $BUILDKITE_API_TOKEN" \
         "https://api.buildkite.com/v2/organizations/<org>/pipelines/<pipeline>/builds/<build>" \
         | jq -r '.jobs[] | select(.state == "failed") | .id' | head -1)
       # Retry it
       curl -s -X PUT -H "Authorization: Bearer $BUILDKITE_API_TOKEN" \
         "https://api.buildkite.com/v2/organizations/<org>/pipelines/<pipeline>/builds/<build>/jobs/$JOB_ID/retry"
       ```
   - Return to Poll CI to wait for the retry result.

2. **Stale branch**: If the failure seems unrelated to PR changes, check how far behind master the branch is:
   ```bash
   git fetch origin master && git rev-list --count HEAD..origin/master
   ```
   If more than 50 commits behind, rebase on master:
   ```bash
   git rebase origin/master
   ```
   If the rebase has conflicts, abort it (`git rebase --abort`) and stop — report the conflicts to the user. Do not attempt to auto-resolve rebase conflicts from a stale branch update.
   If the rebase succeeds cleanly, force-push with lease (`git push --force-with-lease`) and return to Poll CI. Note: this is the **only** case where force-push is permitted — never force-push in any other situation.

3. **Real failure**: The failure is related to files changed in this PR. Proceed to fix it.

### Fix the failure

- Analyze the log output to identify the root cause (failed assertion, compile error, lint violation, etc.)
- Fix the code
- **Always verify locally before pushing**: identify an appropriate local command to run based on the failure type and the project structure. Run it and confirm it passes.
- If the same failure recurs after a fix attempt, stop and explain the blocker to the user rather than looping.

### Commit and push

1. Stage only the files you changed
2. Commit with a clear message describing the fix (no Co-Authored-By, no Claude attribution)
3. Push the branch
4. Record the push time (UTC) — needed for stale review detection
5. Return to Poll CI

## Resolve SonarCloud Issues

Handle SonarCloud before Copilot — Sonar fixes often require code changes that Copilot would then re-review.

SonarCloud feedback appears in two places. Fetch both:

**Quality gate comment** (overall pass/fail):
```bash
gh api "repos/<owner>/<repo>/issues/<pr>/comments" \
  --jq '.[] | select(.user.login == "sonarqubecloud[bot]") | .body'
```

**Inline code comments** (specific file/line issues):
```bash
gh api "repos/<owner>/<repo>/pulls/<pr>/comments" \
  --jq '.[] | select(.user.login == "sonarqubecloud[bot]") | {path, line, body}'
```

Derive `<owner>/<repo>` from `gh repo view --json owner,name`.

For each issue:
- **Duplicated code** → Determine if the duplication is intentional:
  - **Test files**: Duplicated code in tests is expected (tests follow explicit patterns and avoid DRY).
  - **New version / legacy copy**: If the duplicated code exists because a new version was created as a clean copy of legacy code (to avoid modifying the legacy path), the duplication is intentional.
  - If the duplication is intentional, add the `skip-sonar-scan` label to the PR and move on:
    ```bash

From thrawn01/claude-dotfiles, MIT.

More from thrawn01/claude-dotfiles