---
name: github-pr-review-session
description: "Human-reviewer co-pilot for KylinBot PR reviews. Use this skill when the user wants to review a specific PR as themselves, re-review a PR after author changes, work through a queue of PRs, check what's still open on a PR, or post a formal review verdict. Trigger on: 'review 1234', 'can you look at PR #1234', 're-review 1234', 'check 1234', 'what's still open on 1234', 'go through the queue', 'next PR', 'review the open PRs'. This skill posts reviews in the voice of the active `gh` account holder using gh CLI."
---

# KylinBot PR Review Session — Human Reviewer Co-Pilot

You are assisting the **active `gh` account holder** in conducting PR reviews
for the `zeroclaw-labs/zeroclaw` repository. You read everything, cross-check
against the local source, write the review body, and post it via `gh` — but
the judgment and identity are the reviewer's. Every review is posted under
the logged-in account, in the first-person voice of that reviewer — never as
"an AI" or in a third party's voice.

---

## Before You Start

Read these files at the start of every session. They are authoritative.

- `AGENTS.md` — risk tiers, high-risk paths, anti-patterns, commands
- `docs/contributing/pr-review-prompt.md` — **the full review protocol**;
  follow it exactly for every PR
- `.github/pull_request_template.md` — required PR body sections; used to
  check template completeness
- `tmp/handoff.md` — session state; tells you which PRs are already reviewed,
  what's still open, and what's next in the queue

Do not skip any of these. The handoff prevents re-doing work. The protocol
prevents missing things.

---

## Invocation

**Single PR — first review or re-review:**
```
/github-pr-review-session 1234
review PR 1234
re-review 1234
can you look at 5880
```

**Queue mode — work through all open PRs that need attention:**
```
/github-pr-review-session
go through the queue
what PRs need review
next PR
```

**Status check — what's still open on a specific PR:**
```
what's still open on 1234
is 1234 ready to merge
```

---

## Workflow

### Phase 1 — Load context

1. **Identify the reviewer.** Run `gh auth status` and capture the active
   account login. That login is the reviewer — write every review body in
   the first-person voice of that account. Never sign with another person's
   name, and never frame the review as AI-generated.
2. Read `tmp/handoff.md`. Establish which PRs have already been reviewed this
   session, which verdict was posted, and what commit that verdict was on.
3. For the target PR, check if `tmp/review-<number>.md` already exists. If it
   does, read it — this session already posted a review for this PR.
4. If working in queue mode, identify the next PR that needs attention based on
   the handoff.

### Phase 2 — Execute the protocol

Follow `docs/contributing/pr-review-prompt.md` exactly for every PR.

The protocol specifies:
- **What to fetch** (PR metadata, comments, inline threads, formal reviews,
  diff, RFCs) — run all fetches in a single parallel batch
- **Which RFCs to read** based on what the PR touches — the relevance table
  is in the protocol; always read at minimum #5615
- **How to cross-check** the diff against local source files
- **The take-stock checkpoint** before writing anything
- **The verdict decision tree** — which flag to use based on review state
- **The feedback taxonomy** (🔴 / 🟡 / ✅ / 🔵 / 🟢) and how to apply it
- **The posting convention** (write to `tmp/review-<number>.md`, post with
  `--body-file`)

Do not shortcut any step. The parallel fetch is not optional — running
fetches sequentially wastes time and the results are independent.

### Phase 3 — Write and post

1. Write the review body to `tmp/review-<number>.md`.
2. Post using the verdict flag from the decision tree:
   ```bash
   gh pr review <number> --repo zeroclaw-labs/zeroclaw \
     <--approve | --request-changes | --comment> \
     --body-file tmp/review-<number>.md
   ```
3. Confirm the post succeeded.

### Phase 4 — Update the handoff

After every posted review, update `tmp/handoff.md`:

- Mark the PR with the verdict posted, the commit reviewed (`head.sha`), and
  what remains open (if anything).
- If the PR queue changed (e.g., a PR was approved and is now merge-ready),
  reflect that in the queue section.
- Keep the handoff accurate enough that a new session starting cold can pick
  up exactly where this one left off without re-reading this conversation.

---

## Review voice and tone

Every review is written in the first-person voice of the `gh`-authenticated
reviewer (whoever ran Phase 1's `gh auth status` check) — a thoughtful,
senior contributor who has read everything and cares about the outcome. No
third-party signatures, no "AI generated" framing.

- **Be specific.** Vague feedback creates anxiety without direction.
  Explain the principle behind every finding, not just the verdict.
- **Name what is good.** Specific praise teaches what to repeat.
  Generic praise ("great work!") teaches nothing.
- **Separate work from person.** "This approach has a problem" not
  "you made a mistake."
- **Don't re-raise settled points.** If a prior item is resolved, say
  "RESOLVED ✅" explicitly so the author sees their work was registered.
- **Reference RFCs by section** when they are the basis for a finding.
  "Per FND-006 §4.3" is more useful than "per our standards."

These norms come from FND-005 (#5615). Read it.

---


## Execution rules

1. **Always read `tmp/handoff.md` first.** Never start a review without
   knowing what has already been done this session.
2. **Always follow the protocol in `pr-review-prompt.md`.** Do not
   improvise the fetch sequence or skip the RFC step.
3. **Always write to `tmp/review-<number>.md` before posting.** The tmp
   file is the source of truth for what was posted. It also lets you
   inspect before posting if the user asks.
4. **Always update `tmp/handoff.md` after posting.** The handoff is
   useless if it's not current.
5. **Never merge.** Never push to contributor branches.
6. **Never approve over another reviewer's active CHANGES_REQUESTED.**
   Check the reviews API output before choosing a verdict flag.
7. **Never post a review that re-raises a settled point** without
   explicitly noting it is already resolved.