# AI Diff Reviewer Apply Review > Read the most recent AI Diff Reviewer review from the current branch's open PR, present the findings in the same format as the parent skill's local review flow (verdict → findings table → per-finding body → recommendation), and — with explicit consent — walk the developer through each finding to apply, defer, or skip. Multi-provider aware — when the repo runs a matrix of legs (anthropic, cursor, codex, claude-code), attributes each finding to its self-reviewed provider label and surfaces cross-leg consensus. Anchors on the latest ai-pr-reviewer-marker tracking comment and filters minimized (collapsed / outdated) comments per the repo's documented PR-review workflow. Read-only by default; edits to source files require an explicit yes per finding, never commits, never pushes. Use when the developer says "what did the CI review say?", "read the review on this PR", "apply the AI review's fixes", "walk me through the findings", "which findings blocked the merge?", "show me only the critical findings", or "the bot - Skill: `dailybothq/ai-diff-reviewer-apply-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add dailybothq/ai-diff-reviewer-apply-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/dailybothq/ai-diff-reviewer-apply-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: dailybothq (https://skillmd.com/u/dailybothq) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dailybothq/ai-diff-reviewer-apply-review --- # AI Diff Reviewer — Apply Review (sub-skill) Companion to the [`ai-diff-reviewer`](../SKILL.md) skill. Where the parent **runs** the review locally and [`open-pr`](../open-pr/SKILL.md) **writes** the pull request, this sub-skill closes the loop: it **reads** the review the CI Action posted back on the PR, presents the findings in the same format the local review uses, and — with explicit consent — walks the developer through each finding to apply, defer, or skip. The design philosophy mirrors the family's: - **Parity of shape.** The output uses the same `verdict → findings table → per-finding body → notes → recommendation` structure the parent skill emits. A developer who has seen one of the two knows how to read the other. When the CI leg found *"SQL injection in `src/auth.ts:55`"*, the summary looks identical whether it was your local agent or CI that surfaced it. - **Read-only by default.** Fetching + presenting the review never writes anything. Only when the developer explicitly asks to *"walk through"* or *"apply the fixes"* does the sub-skill open source files, and each individual apply still requires a yes. - **Multi-provider aware.** This repo (and any consumer that opts into the 4-leg matrix) posts up to four independent reviews per PR, distinguished by `self-reviewed:` labels. The sub-skill reads all live legs, attributes each finding to its leg, and surfaces cross-leg consensus (*"agreed by 3/3 legs → strong signal; called by 1/3 → could be leg-specific"*). - **Never commits, never pushes.** Applied fixes stay unstaged in the working tree. Commit + push is the developer's judgment call, matching [`open-pr`](../open-pr/SKILL.md)'s trust boundary. The single source of truth for the workflow this sub-skill implements is [`docs/PR_REVIEW_WORKFLOW.md`](https://github.com/DailybotHQ/ai-diff-reviewer/blob/main/docs/PR_REVIEW_WORKFLOW.md). This sub-skill is that doc, executable. --- ## When it fires **Read + present the review (default flow) — triggers:** - "What did the CI review say?" - "Read the review on this PR" - "Show me the review findings" - "Did the bot approve or request changes?" - "Which findings blocked the merge?" - "The AI review just landed — summarize it" **Walkthrough mode (apply/defer/skip per finding) — triggers:** - "Apply the AI review's fixes" - "Walk me through the findings" - "Go through the review one finding at a time" - "Help me address the critical findings" - "Fix the review comments the bot left" **Scope filters — triggers:** - "Critical only" / "show me only the critical findings" - "Warnings only" / "info-level only" - "Just the ones from the `cursor` leg" (multi-leg attribution) - "The findings we all three legs agreed on" **Fall through** to a sibling skill when the developer: - Wants a **local review** on uncommitted changes → parent [`ai-diff-reviewer`](../SKILL.md) skill (default review flow). This sub-skill reads reviews that already exist on the PR; the parent produces a new one locally. - Wants to **install the CI action** → [`setup`](../setup/SKILL.md). - Wants to **customize the reviewer** → [`generate-extension`](../generate-extension/SKILL.md). - Wants to **author or refresh the PR body** → [`open-pr`](../open-pr/SKILL.md). - Wants to read **human** reviewer comments (not the bot's) → defer; this skill filters to bot artefacts by design. `gh pr view --comments` covers human threads. If the intent is ambiguous ("show me the review" on a repo where the Action posted 4 legs, or on a PR with both bot findings and human comments), ask ONE clarifying question before acting. --- ## Step 0 — Trust boundary This sub-skill's reads and writes are enumerated below. **Nothing else happens.** **Reads (always allowed, no consent needed):** - `git`: `git branch --show-current`, `git rev-parse HEAD`, `git status`, and `git show :` — the latter is Step 6b's **primary** pre-image source (used on every `apply`, not just the empty-`diffHunk` case) and is safe by construction: write-free, streamed to stdout, never touches the working tree, never creates or modifies a ref. Use it whenever the sub-skill needs SHA-pinned file content. - `gh`: `gh pr view` for PR metadata, `gh api graphql` for reviews + comments. **Not** `gh pr diff` — it always emits current tip vs base with no way to pin a historical SHA, so it can't be used for pre-image or freshness checks (Step 6b covers this in detail); if the sub-skill needs SHA-pinned file content, use `git show` instead. - Local files under the current git checkout, via `Read` / `Grep` / `Glob` — only for files a finding references. **Writes (only under the per-finding consent contract in Step 6):** - **Edit source files** — when the developer answers *"apply"* on a finding that has a `\`\`\`suggestion` block, the sub-skill reads the target file, replaces the exact lines the suggestion covers, and writes the file back. Never touches lines outside the suggestion's range. - **Create `.review/deferred.md`** (0-byte if empty, otherwise a single-line-per-deferral list) — only when the developer answers *"defer"* on any finding AND is prompted-and-agrees to persist. If the developer prefers ephemeral deferrals, the file is not created. - **Append `.review/deferred.md` to `.gitignore`** — only as a one-time follow-up the very first time `.review/deferred.md` is created in this repo, AND only when the developer accepts the separate consent prompt in Step 6c. Never modifies existing `.gitignore` rules; only appends one line (plus a labeled comment identifying this sub-skill as the source) after the existing content. **It does not:** - `git add`, `git commit`, `git push`, `git checkout`, or any history-rewriting operation. - Post replies, resolve conversations, dismiss reviews, approve, or request changes on the PR — the sub-skill is read-only against the GitHub PR-review surface. Replies to individual threads are a separate concern (a future `respond-to-review` sub-skill). - Call the LLM provider directly — it uses the coding agent that's already running you. - Fabricate suggestions, expand suggestion blocks beyond what the bot wrote, or reason about "what the bot probably meant" when a suggestion is absent. If a finding has no suggestion, *"apply"* is not offered; the developer implements the fix themselves. - Change any file outside the finding's `path:line` scope on *"apply"*. If a suggestion is malformed (e.g. the file no longer matches the expected context), the sub-skill refuses and surfaces the finding for manual application. If the coding agent has broader powers (e.g. can run arbitrary bash), those come from the harness, not this sub-skill. --- ## Step 1 — Detect context Establish the mode (present vs. walkthrough vs. refuse) before fetching anything from GitHub. ```bash # Current branch + head SHA HEAD_BRANCH="$(git branch --show-current)" HEAD_SHA="$(git rev-parse HEAD)" HEAD_SHORT="$(git rev-parse --short HEAD)" # Repo slug (owner/repo) REPO="$(gh repo view --json nameWithOwner --jq .nameWithOwner 2>/dev/null || echo '')" # PR for the current branch (if any) PR_JSON="$(gh pr view --json number,url,state,headRefOid,labels,isDraft 2>/dev/null || true)" PR_NUMBER="$(gh pr view --json number --jq '.number // empty' 2>/dev/null || true)" ``` `PR_NUMBER` is consumed by every subsequent `gh` / `gh api graphql` invocation (Steps 2b, 3, 7). Extracted via `gh pr view --json … --jq …` (not standalone `jq`) so the sub-skill's dependency set stays `git` + `gh` — the two bins already declared in `metadata.requires.anyBins`, matching sibling sub-skills. If the `gh pr view` call fails (no open PR on this branch), `PR_NUMBER` is empty and the mode table below routes to `refuse-soft`. Decide the mode from the state: | State | Mode | Skill behavior | |---|---|---| | On `main` / `master` / `develop` / `trunk` with no PR | **refuse** | Ask the developer to switch to a feature branch that has an open PR. | | Detached HEAD | **refuse** | Ask the developer to check out a branch first. | | `PR_JSON` empty (no PR for this branch) | **refuse-soft** | Point at [`open-pr`](../open-pr/SKILL.md): *"No open PR for ``. Open one first with the `open-pr` sub-skill, wait for CI to review, then re-run me."* | | `PR_JSON` state is CLOSED or MERGED | **warn** | The review artefacts still exist and are readable — offer to read anyway ("this PR is closed / merged; want the historical review or should I stop?"). Do not proceed silently. | | `PR_JSON` state is OPEN | **read** | Go to Step 2. | **On `gh` missing or unauthenticated:** surface the exact remediation (`brew install gh` or `gh auth login`) and stop. Do not attempt to scrape the PR page via a browser — the sub-skill is designed for `gh` + GraphQL and there is no fallback path. --- ## Step 2 — Fetch the review This is the mechanical heart of the sub-skill. The GraphQL query below is **adapted from** [`docs/PR_REVIEW_WORKFLOW.md`](https://github.com/DailybotHQ/ai-diff-reviewer/blob/main/docs/PR_REVIEW_WORKFLOW.md#ready-to-copy-graphql-query) — the selection set is extended (`createdAt`, `submittedAt`, `startLine` for multi-line-suggestion apply) but the **filter rules are the shared contract**: if the doc says *"skip `isMinimized == true`"*, this sub-skill does. If it says *"anchor on the most recent marker"*, this sub-skill does. Divergence in the selection set is allowed and expected as this sub-skill's needs evolve; divergence in the filter rules is a bug — fix the doc, then re-sync here. ### 2a. Identify the bot login The Action collapses prior artefacts belonging to the user its `github-token` authenticates as. For consumers using `secrets.GITHUB_TOKEN` (default), that's `github-actions[bot]`; for consumers using a PAT / automation account, it's the PAT owner's login. Hardcoding `github-actions[bot]` silently mis-filters every PAT consumer — Step 2c drops the real review author and Step 2d then fires the *"Missing (no marker found)"* branch even though a live review exists on the PR. Resolve the login in this order (first non-empty wins): 1. **`AIPRR_BOT_LOGIN` env var** — explicit override; always respected. 2. **The most recent non-minimized `` comment's `author.login`** — authoritative and self-configuring across `github-actions[bot]`, PATs, and automation accounts. Read it from the `comments` collection you already fetch in Step 2b; pick the newest comment whose body starts with ``. 3. **`gh api user --jq .login`** — a last-resort fallback only when no marker exists on the PR (a first-run install where CI hasn't posted anything yet). 4. **The literal string `github-actions[bot]`** — final default when even step 3 fails; a warning should be surfaced to the developer since this is almost always wrong for PAT consumers. The Step 2b query already returns the top-level `comments` nodes with `author.login`. To keep the sub-skill's runtime deps aligned with `metadata.requires.anyBins` (`git` + `gh` only — **no** standalone `jq`), issue a small dedicated `gh api graphql` call for the marker-author read, using `gh`'s built-in `--jq` filter to extract the login without shelling out to `jq`: ```bash BOT_LOGIN="${AIPRR_BOT_LOGIN:-}" if [ -z "$BOT_LOGIN" ]; then # Preferred: derive from the most recent non-minimized marker comment. # Uses gh's built-in --jq (no standalone jq dependency). BOT_LOGIN="$(gh api graphql \ -F owner="${REPO%%/*}" -F repo="${REPO##*/}" -F number="$PR_NUMBER" \ -f query=' query($owner: String!, $repo: String!, $number: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $number) { comments(first: 100) { nodes { body isMinimized createdAt author { login } } } } } }' \ --jq '[.data.repository.pullRequest.comments.nodes[] | select((.isMinimized | not) and (.body | startswith("")))] | sort_by(.createdAt) | reverse | .[0].author.login // empty' \ 2>/dev/null)" fi if [ -z "$BOT_LOGIN" ]; then # Fallback: current authenticated user (only accurate on first-run repos # where no marker exists yet). Warn the developer that this is a guess. BOT_LOGIN="$(gh api user --jq .login 2>/dev/null || echo 'github-actions[bot]')" fi ``` `gh api graphql --jq` runs the filter inside `gh` itself — it does not shell out to standalone `jq`, so this snippet stays inside the `git` + `gh`-only dep constraint declared in `metadata.requires`. Do NOT reintroduce a standalone `jq | ...` pipe here — the moment you do, the primary marker-author path breaks on vanilla macOS / minimal agents and the fallback (`gh api user`) mis-filters live reviews for every PAT / automation-account consumer. ### 2b. Run the GraphQL query ```bash gh api graphql -F owner="${REPO%%/*}" -F repo="${REPO##*/}" \ -F number="$PR_NUMBER" -f query=' query($owner: String!, $repo: String!, $number: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $number) { comments(first: 100) { nodes { id body isMinimized createdAt author { login } } } reviews(first: 100) { nodes { id body state isMinimized submittedAt author { login } commit { oid } comments(first: 100) { nodes { id body path line startLine diffHunk isMinimized } } } } } } }' ``` `startLine` is `null` for single-line inline comments and non-null for multi-line ones (e.g. a `\`\`\`suggestion\`\`\` block covering several lines). When you later need the apply range for Step 6b, derive it as `start = startLine or line`, `end = line` — the reviewer's `line` field is the range end for multi-line comments and the anchor for single-line ones. `originalLine` is the outdated-position field (diff-relative for reviews that no longer point at the current file state) and is **not** the multi-line-range start — do not use it here. **`line: null` is a distinct case.** GitHub returns `line: null` (and `startLine: null`) when the comment is anchored on a hunk that is no longer present in the diff — the review was posted, the developer force-pushed or rebased, and the anchor became orphaned. This shows up precisely on the stale-review paths Step 2d allows after acknowledgement. Because `[startLine or line, line]` would collapse to `[null, null]` and every downstream comparison would either crash or produce a bogus apply range, treat `line: null` as a **read-only** finding: - Include the finding in Step 4's presentation with a marker like `[⚠️ outdated anchor — apply disabled]`. - In Step 6a's walkthrough, present the body normally. - In Step 6's menu, **never offer `apply`** — only `defer`, `skip`, `discuss`, `stop`. Do not attempt to reconstruct a range from `originalLine` (it's diff-relative to a hunk that no longer exists; the numbers won't map cleanly onto today's file). - In Step 3a's consensus scoring, group `line: null` findings only with other `line: null` findings on the same `path` — the range- overlap predicate is undefined for null ranges. The `diffHunk` field carries the raw diff hunk the comment was anchored on (the `-`, `+`, and context lines around the anchor). It is used to render the surrounding patch when the developer needs context — that display belongs in **Step 4's presentation table** (next to the file/line) and/or **Step 6a's walkthrough banner** for the current finding, NOT in Step 5 (which is only the top-level routing menu: `done` / `walk through` / `critical only` / `warnings and up` / `filter by leg` / `cancel`). `diffHunk` also serves as an optional consistency check inside Step 6b — but it is **not** the primary source of the expected pre-image; that role belongs to `git show :` (see Step 6b for the full derivation). Note the GraphQL schema does **not** expose a `side` field on `PullRequestReviewComment` — side-of-diff lives on `PullRequestReviewThread.diffSide`. Step 6b sidesteps this by reading the reviewed-commit file content directly, which is independent of hunk sides. In practice this is safe because `findings_to_gh_inline_comments()` in `scripts/reviewer.py` posts anchors with `side: RIGHT` by default (the `"side": f.side or "RIGHT"` line inside that function is the authoritative reference — cite the function name, not a raw line number that will drift on the next edit), so `line` / `startLine` refer to post-image file positions that resolve cleanly via `git show`. A rare `side: LEFT` anchor (removed-line comment) will fail the `git show`-slice consistency check in Step 6b and route to `skip / discuss`. `BOT_LOGIN` is **not** a GraphQL variable — it's applied client-side in Step 2c's filter. GitHub's GraphQL API rejects unused declared variables (`variableNotUsed`), so declaring `$bot: String!` while only using it in a follow-up `jq` filter fails the query outright. Keep the login filter in Step 2c and the GraphQL selection set variable-free. ### 2c. Filter to live bot artefacts Two collections come back — `comments` (top-level, includes tracking markers) and `reviews` (with nested inline `comments`). Apply the mandatory rules from [`docs/PR_REVIEW_WORKFLOW.md` § Mandatory rules](https://github.com/DailybotHQ/ai-diff-reviewer/blob/main/docs/PR_REVIEW_WORKFLOW.md#mandatory-rules): 1. **Filter out `isMinimized == true`** at every level (top-level comments, review bodies, inline review comments). 2. **Filter authors** to `$BOT_LOGIN` only. 3. **Anchor on the latest `` comments** — plural when multiple legs ran. Each marker's body starts with the marker string; each carries the SHA its leg reviewed. **IAR note.** The marker may contain an HTML-comment `IterationState` JSON block and a short gen/round/policy annotation — ignore both when collecting findings (they are telemetry, not review comments). The inline comments you present are already post-IAR-dedup. If the developer expected a finding that appeared in a local review but not in CI, suggest applying `full-review-please` (the `iteration-escape-label`, one-shot full review with state preserved) or removing the `applied-label` then re-triggering for a full state reset — see [`docs/ITERATION_AWARENESS.md` § 8](https://github.com/DailybotHQ/ai-diff-reviewer/blob/main/docs/ITERATION_AWARENESS.md). Emit the filtered set to your working context as a list of `{leg_label, sha, review_body, inline_comments[]}` records. ### 2d. Anchor + freshness check Tracking markers are top-level **issue comments** — they have no `commit.oid`. The SHA source depends on the marker state (the H3 tells you which one: `_Working…_` vs. `✅ done` / `🚫 done` vs. `❌ failed`): - **Working markers** (`render_tracking_body_working()` in `scripts/reviewer.py`) — include a `Full SHA: \`\`` line in the body. Parse it. This is the in-flight case; a Working marker means the review is still running or its terminal transition failed. - **Done and failed markers** (`render_tracking_body_done()` / `render_tracking_body_failed()`) — do NOT render `Full SHA:`; they only carry the 7-char short SHA in the H3 (`AI review for \`<7chars>\``). Resolve the full SHA by joining the marker to its matching non-minimized review via the provider marker (both carry ``), then read the joined review's `commit.oid` — that is the **primary** SHA source for completed reviews (which is the common case). The 7-char prefix in the H3 is a useful cross-check but is ambiguous by itself. If the joined review is missing when the marker says `done` or `failed` (rare — the mid-flight transition raced), fall back to the 7-char H3 prefix and warn the developer that the review body could not be paired. Compare the resolved SHA against `HEAD_SHA`: | Marker SHA | HEAD SHA | Interpretation | |---|---|---| | Matches HEAD | Matches | Review is for the current commit — proceed normally. | | Matches HEAD's parent (marker == `HEAD~1`) | Matches | The developer has made **one commit locally** since the review; HEAD itself is a commit CI never saw. Warn: *"The review is for ``, but you've committed `` since then. Findings may already be resolved by your local commit; CI will re-review once you push. Continue anyway?"* — proceed only after ack. Pre-image checks in Step 6b will still refuse silently-clobbering an already-edited line. | | Older than HEAD's parent | New commits landed since the review | Warn: *"The review is for ``, but HEAD is ``. Reading anyway, but the findings may be stale — CI will likely re-review. Continue?"* | | Newer than HEAD | Local branch is behind origin | Warn: *"Origin has ``, your local HEAD is ``. Consider `git pull` before applying."* — proceed only after ack. | | Missing (no marker found) | — | CI hasn't run yet OR the label-gate is missing OR all matrix legs' secrets are unset. See [`docs/PR_REVIEW_WORKFLOW.md` § "I don't see any live review"](https://github.com/DailybotHQ/ai-diff-reviewer/blob/main/docs/PR_REVIEW_WORKFLOW.md#i-dont-see-any-live-review) for the diagnosis table. Stop; do not proceed with an empty review. | Only exact-HEAD is fully authoritative; every other row above (including `marker == HEAD~1`) requires an explicit developer acknowledgement before Step 4 presents findings or Step 6b applies anything. This closes the "silent green light" case where a single uncommitted-since-CI commit would otherwise be treated as authoritative. Never fabricate findings when the review is missing or stale. ### 2e. Extract per-finding severity GitHub inline review comments carry `body` only — `findings_to_gh_inline_comments()` in `scripts/reviewer.py` does **not** prefix severity into the comment body, so severity is **not** recoverable from the inline comment itself. The authoritative per-finding severity lives in the **review summary body's findings table**: ```markdown ### 2. Findings table | # | Severity | File | Summary | |---|------------|---------------------|----------------| | 1 | 🚨 critical | `src/auth.ts:55` | SQL injection… | | 2 | ⚠️ warning | `src/cache.ts:120` | Unbounded key… | ``` For each inline comment produced by the leg, join to the summary table by matching on `path:line`: 1. **Locate the findings table heading-agnostically.** Scan `review_body` for a Markdown table whose header row contains all of `Severity`, `File`, and `Summary` (case-insensitive, in any column order). The heading right above the table varies — `prompts/default.md` instructs models to emit it under `### 2. Findings table`, while the local review flow uses `## Findings`, and consumers with custom prompts may use anything — so anchoring on the header row (not the heading text) is the only reliable strategy. 2. Parse each row into `{severity, path, line, summary}`. The severity cell is `