---
name: babysit-pdq-pr
description: Babysit PR review cycles for PDQ organization repositories only. Use only when the user explicitly asks to run this skill (for example, "use babysit-pdq-pr"). Monitor a PR for new feedback from `coderabbitai`, evaluate each concern for validity, fix only valid issues with conventional commits, push, and repeat until CodeRabbit approves.
---

# Babysit PDQ PR

## Guardrails

- Confirm the request is explicit. If the user did not specifically ask to use this skill, do not use it.
- Confirm repository scope before doing any work:
  1. Get owner/name via `gh repo view --json owner,name`.
  2. Continue only if the owner is a PDQ org (owner login contains `pdq`, case-insensitive).
  3. If not PDQ, stop and tell the user this skill is not applicable.
- Operate only on the target PR branch and do not change unrelated files.
- Do not post noisy trigger commands (for example `@coderabbitai review`/`@coderabbitai resume`) unless the user explicitly asks.
- Prefer automatic CodeRabbit re-reviews triggered by pushed commits.

## Setup

1. Resolve the PR number (from user input or current branch):
   - `gh pr view --json number,url,headRefName,baseRefName,state`
2. Ensure clean local state before starting each cycle:
   - `git status --short`
   - If dirty due to unrelated work, isolate or stash only if the user asks.
3. Capture a processing checkpoint timestamp (`last_checked_at`) so each loop handles only new CodeRabbit feedback.

## Review Cycle Loop

Repeat this loop until CodeRabbit approval is reached.

1. Fetch latest PR feedback from CodeRabbit:
   - Reviews: `gh api repos/{owner}/{repo}/pulls/{pr}/reviews --paginate`
   - Inline comments: `gh api repos/{owner}/{repo}/pulls/{pr}/comments --paginate`
   - Issue comments: `gh api repos/{owner}/{repo}/issues/{pr}/comments --paginate`
2. Build the current batch:
   - Include only items authored by `coderabbitai`.
   - Include only items newer than `last_checked_at`.
   - If no new items, wait and poll again (see Wait Strategy).
3. Evaluate each comment one by one.

## Per-Comment Decision

For every `coderabbitai` comment, decide `fix` or `ignore`.

- Treat the comment as a hypothesis, not a fact.
- Validate against the actual code, PR goals, project conventions, tests, and runtime behavior.
- Ignore if the concern is hallucinated, out of scope, already addressed, or would degrade correctness/design.
- Fix if the concern is valid and improves correctness, safety, maintainability, or clarity in this PR.

## If Decision Is `fix`

1. Implement the minimal correct change.
2. Run focused verification (tests/lint/typecheck) for the impacted area.
3. Commit immediately with a conventional commit title only (no body), for example:
   - `git commit -m "fix: handle nil input in session parser"`
4. Prefer one commit per accepted concern for clean auditability.
5. Keep commits local until the current batch of new comments is fully processed.

## If Decision Is `ignore`

- Record a short rationale in your working notes so future cycles do not re-litigate the same point.
- If helpful, leave a concise PR reply explaining why no change is needed.

## End of Batch

After all comments in the current batch are processed:

1. Push branch updates once for the whole batch: `git push`
   - Do not push after every single commit.
   - If the batch produced no new commit, do not push just to poll.
2. Update `last_checked_at` to the most recent processed CodeRabbit item.
3. Wait for CodeRabbit to re-review automatically; do not post trigger comments unless explicitly requested.
4. Return to waiting for the next cycle.

## Wait Strategy

- Poll for new CodeRabbit feedback on an interval (for example 60-120 seconds).
- Use the `timeout` CLI to bound each wait window when needed, then continue polling:
  - Example pattern: `timeout 10m <poll-command>`
- Continue iterating until exit conditions are met.

## Exit Conditions

Stop the loop only when both are true:

1. The latest CodeRabbit review state is `APPROVED`.
2. There are no newer unresolved `coderabbitai` comments after the approval.

Then report:

- Which comments were fixed and corresponding commit titles.
- Which comments were ignored and the rationale for each.