--- name: review-pr-extensive description: Thorough multi-agent PR review with parallel specialized agents and confidence scoring for high-signal, low-false-positive feedback. disable-model-invocation: true argument-hint: "" --- Review the GitHub PR provided as argument: $ARGUMENTS This is a thorough, multi-agent code review that uses parallel specialized agents and confidence scoring to produce high-signal feedback with minimal false positives. ## Phase 1: Eligibility check Launch a Haiku agent to check whether this PR should be reviewed. Skip if the PR: - Is closed or merged - Is a draft - Is trivially simple (e.g. typo fix, version bump, auto-generated) - Already has a code review from you If skipped, explain why and stop. ## Phase 2: Gather context Run these in parallel: 1. **Haiku agent — CLAUDE.md discovery**: Find all relevant CLAUDE.md files: the root CLAUDE.md, plus any CLAUDE.md files in directories whose files the PR modifies. Return the file paths and their contents. 2. **Fetch PR metadata and diff**: Use `gh pr view` and `gh pr diff` to get the full PR context. 3. **Fetch file contents**: For every changed file, fetch the actual file content from the PR's head branch so that line numbers are accurate: ``` gh api repos/{owner}/{repo}/contents/{path}?ref={head_branch} --jq '.content' | base64 -d ``` This is critical — the `line` parameter in the GitHub API refers to the real line number in the new version of the file, NOT a position in the diff hunk. ## Phase 3: Parallel specialized review agents Launch these 5 agents in parallel. Each agent receives the PR diff, relevant file contents, and CLAUDE.md files. Each must return a list of issues, where each issue includes: file path, line number(s), description, reason it was flagged (category), and the agent's own initial confidence (0-100). Use **Sonnet** for Agents 1 and 5 (pattern-matching tasks), **Opus** for Agents 2, 3, and 4 (deeper reasoning). ### Agent 1 — CLAUDE.md compliance Audit the changes against all relevant CLAUDE.md files. Only flag issues that are specifically called out in CLAUDE.md. Ignore CLAUDE.md instructions that are about how Claude should write code (not applicable during review). If flagging an issue, quote the specific CLAUDE.md rule. ### Agent 2 — Bug and logic scan Read the changed files in full (not just the diff) and scan for: - Logic errors, off-by-one mistakes, incorrect conditionals - Data quality risks (wrong joins, missing filters, type mismatches) - Performance problems (N+1 queries, missing indexes, full table scans) - Edge cases and null handling Focus on real bugs. Ignore style, formatting, and minor nitpicks. Ignore anything a linter or type checker would catch. ### Agent 3 — Git history analysis Use `git log` and `git blame` on the modified files to understand: - What these files have historically done - Whether the PR contradicts established patterns - Whether similar changes were previously reverted or caused issues Only flag issues where historical context reveals a concrete risk. ### Agent 4 — Prior PR comment analysis Use `gh pr list --state merged --search` to find previous PRs that touched the same files. Check comments on those PRs for recurring feedback that may also apply here. Only flag if the same issue is clearly present. ### Agent 5 — Code comment and documentation compliance Read code comments, docstrings, and inline documentation in the modified files. Check whether: - The PR changes contradict guidance in existing code comments - New code is missing documentation that neighboring code has - TODO/FIXME items are being introduced without tracking For dbt/SQL projects specifically, also check against the Gemma Analytics SQL style guide rules in CLAUDE.md. ## Phase 4: Confidence scoring Collect all issues from Phase 3. For each issue, launch a parallel Haiku agent that independently evaluates it. The agent receives: the issue description, the relevant code context, and the CLAUDE.md files. It returns a confidence score using this rubric: - **0** — False positive. Does not stand up to scrutiny, or is a pre-existing issue. - **25** — Weak. Might be real but could easily be a false positive. If stylistic, not explicitly in CLAUDE.md. - **50** — Moderate. Verified as real but may be a nitpick or unlikely in practice. Not very important relative to the rest of the PR. - **75** — High. Double-checked and very likely a real issue that will be hit in practice. The existing approach in the PR is insufficient, or the issue is directly mentioned in CLAUDE.md. - **100** — Certain. Confirmed real issue that will happen frequently. Evidence directly confirms it. For issues flagged due to CLAUDE.md rules, the scoring agent must verify that CLAUDE.md actually calls out that issue specifically. If not, cap the score at 25. ### False positive exclusion list Scoring agents must treat the following as false positives (score 0) unless there is overwhelming evidence otherwise: - Pre-existing issues (not introduced by this PR) - Issues on lines the PR did not modify - Things a linter, type checker, or compiler would catch (imports, type errors, formatting) - Pedantic nitpicks that a senior engineer would not call out - General code quality issues (test coverage, security hygiene) unless explicitly required in CLAUDE.md - Issues called out in CLAUDE.md but explicitly silenced in code (e.g. lint ignore comments) - Changes in functionality that are likely intentional given the PR's purpose ## Phase 5: Filter and present Filter out all issues with a confidence score below **80**. If no issues survive filtering, report: "No high-confidence issues found. Checked for bugs, CLAUDE.md compliance, historical patterns, prior PR feedback, and code comment compliance." If issues survive, present a structured review summary to the user: For each issue: - **[Blocking]** or **[Non-Blocking]** prefix - Blocking: logic bugs, data correctness, performance issues, CLAUDE.md violations (score 75+) - Non-Blocking: style suggestions, documentation gaps, questions - **Category**: Logic | Style | Performance | Documentation | Question | Security | CLAUDE.md - **File and line**: exact file path and line number(s) - **Description**: what the issue is and why it matters - **Confidence**: the score (80-100) - **Source**: which agent found it and why (e.g. "CLAUDE.md says: ...", "git blame shows this was reverted in #123") ## Phase 6: Post comments (with confirmation) Ask the user if they want the comments posted to the PR. If confirmed, post each finding as an **individual inline comment** on the relevant diff line: ``` gh api repos/{owner}/{repo}/pulls/{number}/comments \ --method POST \ -f commit_id="" \ -f path="" \ -F line= \ -f body="" ``` Get the head commit SHA via: `gh pr view {number} --json commits --jq '.commits[-1].oid'` Post all comments in parallel for efficiency. ### Comment format Every inline comment MUST follow this format: ``` [Blocking] Category: description Source: ``` or: ``` [Non-Blocking] Category: description Source: ``` Do NOT include the confidence score in GitHub comments. Confidence scores are for local triage only (shown to the user in Phase 5) and should not appear in posted PR comments. ## Important notes - Always read the full file before commenting — don't review only the diff in isolation. - Use `gh` for all GitHub interactions, not web fetch. - Do NOT post comments without user confirmation. - Do not check build signal or attempt to build/typecheck. These run separately in CI. - When citing CLAUDE.md rules, quote the specific text. - For dbt/SQL projects, check against the Gemma Analytics SQL style guide rules in CLAUDE.md.