# Pr Review Pipeline > Chain the three PR passes on the PRs awaiting my review, in one go: build the comprehension brief (pr-brief), draw the flow when the mechanism is spread out (pr-flow), then leave a pending review (review-requested-prs) that reads both as context. Use when the user says "/pr-review-pipeline", "brief, flow et review", "prΓ©pare et review les PRs", or wants the three passes chained on one or several PRs. Pick this over review-requested-prs whenever the brief (and flow) must be built before the review; review-requested-prs alone is the review pass without that preparation. - Skill: `antsteyer/pr-review-pipeline` (Agent Skill) - Install (CLI): `npx skillmds@latest add antsteyer/pr-review-pipeline` - Raw SKILL.md: https://api.skillmd.com/api/skills/antsteyer/pr-review-pipeline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: antsteyer (https://skillmd.com/u/antsteyer) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/antsteyer/pr-review-pipeline --- # PR Review Pipeline Skill Goal: chain the three PR skills without me relaunching each one, **without a pause**: 1. `pr-brief` β€” the reading path (always); 2. `pr-flow` β€” the diagram (only when the PR calls for it, see Step 3); 3. `review-requested-prs` β€” the PENDING review, fed with the brief **and** the flow. This skill only orchestrates. Every rule of the three skills (read-only passes, named refs, no checkout, `πŸ€–` prefix, PENDING only, never submit) applies unchanged β€” read them from `~/.claude/skills//SKILL.md`, never paraphrase them from memory. `gh` is authenticated. Resolve my login once: `gh api user --jq .login` (`ME`). ## Arguments - A PR reference (URL, `/#`, or `#` / `` from inside a repo) β†’ that PR only, skip Step 1. Parse out `REPO` as `/` (never the bare repo name β€” `blocks.py report` builds the report path from it) and `N`; for `#` / ``, resolve it with `gh repo view --json nameWithOwner --jq .nameWithOwner`. - `dry-run` / `--dry-run` β†’ forwarded to the review pass only (brief and flow are read-only anyway). - `flow` β†’ force the flow for every PR; `no-flow` β†’ never draw it. State the PR list, the mode (live / dry-run) and the flow policy up front. ## Step 1 β€” Pick the PRs (once for all three passes) Apply Steps 1–3 of `review-requested-prs` (discovery with `review-requested:@me`, drafts dropped, repo then PR selection, default = all). The selection is made **once, here**: every pass below is invoked with an explicit PR reference, so none of them asks again. ## Step 2 β€” Snapshot the refs and worktrees before touching anything In each local clone involved (found as `pr-brief`, step 2 describes) **and** in `~/workspaces/agorize/agorize-core` (a companion branch may be fetched there), record: - the existing refs: `git for-each-ref --format='%(refname)' refs/pr-brief`; - the existing sibling worktrees the passes may create: `git worktree list --porcelain | grep -E '^worktree .*/(pr-brief|pr-review)-[^/]+$'`. The passes below share these refs and worktrees and are told to keep them; Step 5 removes only what is absent from this snapshot β€” a ref or worktree already there belongs to another session. ## Step 3 β€” One subagent per PR, three passes in sequence Several PRs β†’ one `general-purpose` subagent per PR, launched in a single message so they run concurrently. A single PR β†’ one subagent too: the diff dumps, excerpts and probes of three passes stay out of the main conversation, which only receives the report. **Never `isolation: "worktree"`** (it creates the worktree inside the repo). Give each subagent the PR (`/#`, URL), the mode, the flow policy and these instructions verbatim: > Run three passes on this PR, in order, without stopping between them. For each pass, invoke the > skill with the Skill tool, passing the PR URL plus the extra args given below; if the Skill tool > is unavailable, read `~/.claude/skills//SKILL.md` and apply it as written, single-PR path. > > **Pass 1 β€” `pr-brief`.** Args: ` β€” another pass follows: keep the refs/pr-brief refs`. > Note the report path (`python3 ~/.claude/skills/pr-brief/blocks.py report brief`) > and keep the builder `build_.py` importable. > > **Pass 2 β€” `pr-flow`, only when justified.** Policy `flow` β†’ always; `no-flow` β†’ never; > otherwise decide from the brief you just wrote. Draw the flow when the mechanism is spread: > a store shared by several components or views, an event relayed across several `$emit` levels, > route guards or redirections choosing the path, SSR vs client behaviour, a front + agorize-core > pair forming one flow, callbacks / jobs / services on a backend, **or state and a lifecycle split > across files that run in sequence** (config β†’ setup files β†’ workers, build steps, CI jobs, > middleware chains). A plain UI change, a rename, a one-hop change, mechanical edits repeated > across files β†’ no flow. Either way, write down the one-line reason. Args: ` β€” reuse the brief and > build_.py; another pass follows: keep the refs/pr-brief refs`. Note the report path > (`... report flow`). > > **Pass 3 β€” `review-requested-prs`, targeted-PR mode.** Args: ` [dry-run]` followed by: > `Context already built: read .json first` and, when a flow was drawn, > `and .json (its nodes, edges, facts and blocks are verified context)` β€” both only > if their `head_sha` equals the PR's current head, otherwise ignore them and rebuild the context. > `Do not delete the refs/pr-brief refs: the orchestrator cleans them up.` > > Report back β€” only this, never the diff or the excerpts you read: the brief path, the flow path > or the reason there is none, the companion agorize-core PR number if any, and the review outcome > (live: review id + state + comment count; dry-run: the full review β€” body and every inline > comment with `path`, `line`, `side`, `body`). A pass that fails does not silently stop the chain: a failed brief stops that PR (the flow and the review depend on it) and is reported; a failed flow is reported and the review still runs with the brief alone. ## Step 4 β€” Report One table: `Repo#PR | Brief | Flow | Review`, with the brief and flow file paths (or the reason there is no flow), then the review column as `review-requested-prs` Step 5 describes it (live: review id, `PENDING`, comment count, key points; dry-run: the rendered review per PR, below the table). Remind me that pending reviews stay visible only to me until I submit them on GitHub. ## Step 5 β€” Cleanup After every subagent has finished, in each clone snapshotted at Step 2: - delete the `refs/pr-brief/*` refs **absent from the snapshot** (`git update-ref -d …`); - remove the `pr-brief-*` / `pr-review-*` sibling worktrees **absent from the snapshot** (`git worktree remove --force …`, then `git worktree prune`) β€” never one that was already there; - confirm the working tree and current branch are exactly as they were. Keep the report JSON and HTML files. Publishing a review stays out of scope: if I later ask to submit one, follow Step 6 of `review-requested-prs`.