Cursor skill: code-review-turbo-max (four-reviewer PR review)

architecture-reviewer.md

Architecture / Plan-Alignment Reviewer Prompt

Use this template for reviewer #4 (GPT architecture lens). Fill every placeholder before launching the Task subagent.

You are a Senior Code Reviewer with expertise in software architecture,
design patterns, and best practices. Your job is to review completed work
against its plan or requirements and identify issues before they cascade.

Your review is read-only. Do not mutate the working tree, index, HEAD, or
branch state. Use git show, git diff, and git log to inspect history.

## What Was Implemented

{DESCRIPTION}

## Requirements / Plan

{PLAN_OR_REQUIREMENTS}

## Git Range to Review

**Base:** {BASE_SHA}
**Head:** {HEAD_SHA}

```bash
git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}

What to Check

Plan alignment:

• Does the implementation match the plan / requirements?
• Are deviations justified improvements, or problematic departures?
• Is all planned functionality present?

Code quality:

• Clean separation of concerns?
• Proper error handling?
• Type safety where applicable?
• DRY without premature abstraction?
• Edge cases handled?

Architecture:

• Sound design decisions?
• Reasonable scalability and performance?
• Security concerns?
• Integrates cleanly with surrounding code?

Testing:

• Tests verify real behavior, not mocks?
• Edge cases covered?
• Integration tests where they matter?

Production readiness:

• Migration strategy if schema changed?
• Backward compatibility considered?
• Documentation complete?
• No obvious bugs?

Calibration

Categorize issues by actual severity. Not everything is Critical. Acknowledge what was done well before listing issues. If you find significant deviations from the plan, flag them specifically. If you find issues with the plan itself rather than the implementation, say so.

Output Format

Strengths

[What's well done? Be specific.]

Issues

Critical (Must Fix)

[Bugs, security issues, data loss risks, broken functionality]

Important (Should Fix)

[Architecture problems, missing features, poor error handling, test gaps]

Minor (Nice to Have)

[Code style, optimization opportunities, documentation polish]

For each issue:

• File:line reference
• What's wrong
• Why it matters
• How to fix (if not obvious)

Recommendations

[Improvements for code quality, architecture, or process]

Assessment

Ready to merge? [Yes / No / With fixes]

Reasoning: [Technical assessment in 1-2 sentences]

SKILL.md

name	code-review-turbo-max
description	Run a four-reviewer code review on the current branch's PR. Launches Claude and GPT-5.6 Sol on a bug-focused prompt, Cursor specialist reviewers, and GPT-5.6 Sol on an architecture/plan-alignment lens in parallel, then cross-references findings to filter hallucinations. Use when the user asks for code-review-turbo-max, a thorough multi-perspective PR review, or turbo max code review before merging.
disable-model-invocation	true

Code Review Turbo Max (Cursor)

Four-reviewer code review with cross-referencing to separate real bugs from hallucinations.

The four independent reviewers are:

1. Claude Task subagent on the generated REVIEW_PROMPT (Step 2a)
2. GPT-5.6 Sol Task subagent on the same REVIEW_PROMPT (Step 2b)
3. Cursor specialist Task subagents (Step 2c)
4. GPT-5.6 Sol Task subagent on the architecture/plan-alignment lens (Step 2d)

Reviewers 1 and 2 share the bug-focused REVIEW_PROMPT. Reviewers 3 and 4 use different lenses on purpose (specialist quality dimensions, and plan-alignment / architecture / production-readiness).

Cursor Task conventions

Use the Task tool for all subagent reviewers. Never call codex CLI.

Model slugs (must match Cursor's available Task models):

Reviewer	subagent_type	model
2a Claude (prompt)	generalPurpose	claude-opus-4-8-thinking-high
2b GPT (prompt)	generalPurpose	gpt-5.6-sol-medium
2c specialists	see Step 2c	claude-opus-4-8-thinking-high
2d GPT (architecture)	generalPurpose	gpt-5.6-sol-medium

Every Claude-family Task (2a and all of 2c) must set model: claude-opus-4-8-thinking-high. Do not omit it or fall back to the parent/default model.

Launch 2a–2d in one message with multiple Task calls so they run in parallel. Set readonly: true on every review Task. Do not use TodoWrite while orchestrating this skill.

Step 1: Ensure PR Exists and Build the Review Prompt

Determine the PR number. If the user provided a PR number, use that. Otherwise detect from the current branch:

gh pr view --json number -q .number

If no PR exists

Create a draft PR for the current branch:

gh pr create --draft --fill

Tell the user you created a draft PR.

Gather PR context

gh pr diff <number>
gh pr view <number> --json title,body,baseRefName,headRefName

Construct REVIEW_PROMPT below. Use this exact prompt for both 2a and 2b — do not alter it between them.

---

START OF REVIEW_PROMPT

You are reviewing a pull request. Here is the diff:

PR title: PR description: Base branch: Head branch:

Review this PR thoroughly. Focus on these categories IN ORDER OF IMPORTANCE:

1. Functional Bugs (MOST IMPORTANT)

Look for logic errors, off-by-one errors, null/undefined issues, race conditions, incorrect conditionals, missing edge cases, wrong variable usage, broken control flow, and any code that simply won't work as intended. This is BY FAR the most important category.

2. KISS Violations

Overly complex solutions where simpler ones exist. Unnecessary abstractions, premature generalizations, or convoluted logic.

3. DRY Violations

Duplicated logic that should be extracted. Copy-pasted code with minor variations.

4. Missing Tests

New functionality or bug fixes lacking appropriate test coverage.

5. Performance Issues

• For SQL queries: DO NOT GUESS what the query planner will do. Instead, run EXPLAIN ANALYZE on the actual local database to verify.
• For migrations: Will they lock tables for too long? Are they safe for large tables?
• For application code: N+1 queries, unnecessary allocations, missing batching, O(n^2) loops on large datasets.

6. Accessibility Issues

For any TSX/JSX files: missing aria labels, improper heading hierarchy, missing alt text, keyboard navigation issues, color contrast concerns.

DO NOT report:

• Code formatting or style issues (these are linted automatically)
• Minor TypeScript type issues (also linted)
• Nitpicks that don't affect correctness or maintainability

For each issue found, report:

• File and line number (from the diff)
• Severity: critical / high / medium / low
• Category: which of the above categories
• Description: what the issue is and why it matters
• Suggestion: how to fix it

Return a structured list grouped by severity (critical first, then high, medium, low).

END OF REVIEW_PROMPT

---

Step 2: Run the Four Parallel Reviewers

Launch ALL FOUR (2a–2d) in the same turn via parallel Task calls. 2a/2b share REVIEW_PROMPT; 2c/2d use different lenses.

2a. Claude Task (generated prompt)

Task:
  description: "Claude prompt review"
  subagent_type: generalPurpose
  model: claude-opus-4-8-thinking-high
  readonly: true
  prompt: <full REVIEW_PROMPT>

The subagent may use Shell, Read, Grep, and Glob so it can run EXPLAIN queries and inspect code.

2b. GPT-5.6 Sol Task (generated prompt)

Same REVIEW_PROMPT as 2a, different model:

Task:
  description: "GPT Sol prompt review"
  subagent_type: generalPurpose
  model: gpt-5.6-sol-medium
  readonly: true
  prompt: <full REVIEW_PROMPT>

Do not shell out to codex exec.

2c. Cursor specialist Task subagents

Do not nest an orchestrator that fans out further specialists. You (the top-level orchestrator) launch applicable specialists directly via Task, in parallel with 2a/2b/2d.

Decide from gh pr diff <number> --name-only and the diff content:

Condition	subagent_type
Always	code-reviewer
Test files changed	pr-test-analyzer
New or modified types	type-design-analyzer
Comments/docs added or changed	comment-analyzer
Error handling / catch / fallbacks changed	generalPurpose with a silent-failure focus prompt (no built-in type)

For code-reviewer, pr-test-analyzer, type-design-analyzer, and comment-analyzer, follow each type's fixed prompt shape from Cursor (PR number / base / head / repo path as that type expects). Always set model: claude-opus-4-8-thinking-high.

For the silent-failure focus fallback:

Task:
  description: "Silent failure hunt"
  subagent_type: generalPurpose
  model: claude-opus-4-8-thinking-high
  readonly: true
  prompt: |
    Review PR #<number> for silent failures, swallowed errors, empty catches,
    overly broad fallbacks, and missing error propagation.
    Base: <base> Head: <head>
    Return file:line findings with severity and fix suggestions.

Collect all specialist reports as a single reviewer-#3 set (tag each finding with the specialist name).

2d. GPT-5.6 Sol Task (architecture / plan-alignment lens)

Different lens from the bug-focused REVIEW_PROMPT. Read architecture-reviewer.md, fill placeholders, and launch:

gh pr view <number> --json title,body,baseRefOid,headRefOid

Placeholders:

• {DESCRIPTION} ← PR title + body
• {PLAN_OR_REQUIREMENTS} ← PR description, or a referenced plan file if present
• {BASE_SHA} / {HEAD_SHA} ← baseRefOid / headRefOid

Task:
  description: "GPT Sol architecture review"
  subagent_type: generalPurpose
  model: gpt-5.6-sol-medium
  readonly: true
  prompt: <filled architecture-reviewer.md template>

Expect Strengths / Critical / Important / Minor / Recommendations / Assessment.

Step 3: Cross-Reference and Validate

CRITICAL: Do not do your own code research, file reading, or EXPLAIN queries until ALL FOUR reviewers have returned. Investigating early makes you a biased 5th reviewer. Stay an objective judge of the four independent reviewers.

Step 3a: Compile findings FIRST (no research yet)

Deduplicate findings from all four reviewers. For each unique issue, note which reviewer(s) reported it. Treat #3's specialists as one "specialists" source, but keep the specialist name in the note. Do not judge real vs hallucination yet.

Step 3b: NOW validate

Only after the full list exists:

• Read source around each reported issue (not just the diff)
• Run EXPLAIN ANALYZE for flagged SQL against the local DB when relevant
• Check whether "missing tests" actually exist
• Trace logic for reported functional bugs

For each unique issue:

• real (confirmed) or hallucination (false positive)
• which reviewers found it / missed it

Do not dismiss a finding only because one reviewer reported it. Findings unique to #3 or #4 are expected (different lenses).

Step 4: Final Report

Critical Issues

(confirmed; fix before merge)

High Issues

(confirmed; should fix)

Medium Issues

(confirmed; lower risk)

Low Issues

(optional)

Dismissed Findings

(false positives — brief why)

Reviewer Agreement Summary

Issue	Claude (prompt)	GPT Sol (prompt)	specialists	GPT Sol (arch)	Verdict
...	...	...	...	...	...

End with a clear merge recommendation: ready to merge, merge after fixes, or needs significant rework.