comprehensive-review
Comprehensive Code Review (Codex + Gemini)
Overview
Run Codex and Gemini code reviews in parallel using the Task tool, then synthesize both results into a single consolidated report. This provides broader coverage by leveraging two independent AI models with different strengths.
Workflow
Step 1: Determine Review Scope
Ask the user what they want reviewed if not already clear:
| Scope | When to use | Codex | Gemini |
|---|---|---|---|
| Branch diff | Before opening or merging a PR | Yes | Yes |
| Uncommitted changes | During active development | Yes | Yes |
| Specific commit | Auditing a single changeset | Yes | Yes |
| Remote PR | Reviewing a GitHub Pull Request by number or URL | No | Yes |
| Custom | User provides specific review instructions | Yes | Yes |
Note: Remote PR scope is only supported by Gemini. When user selects PR, run Gemini review only and skip Codex.
Default to reviewing the current branch diff against main unless the user specifies otherwise.
Step 2: Run Both Reviews in Parallel
Launch two Task agents simultaneously in a single message. Both agents must run in the same message to ensure true parallelism.
- Agent 1: Activate the
codex-reviewskill and run it with the determined scope. - Agent 2: Activate the
gemini-reviewskill and run it with the same scope.
Pass the user's review scope (branch, uncommitted, commit SHA, PR number, custom focus) to both agents so they review the exact same changes.
Tell each agent to capture and return the full review output.
Step 3: Synthesize Results
Once both agents return, produce a single consolidated report using this structure:
Comprehensive Review
Quality: X/5 · Confidence: X/5 · Verdict:
Where:
- Quality (1-5): Combined quality assessment across both reviewers
- Confidence (1-5): How much the reviewers agree (5 = full consensus, 1 = major contradictions)
- Verdict: Approved / Approved with suggestions / Request Changes
Summary
3-5 sentence overview combining both reviewers' assessments. Note where they agree and disagree.
Changes Walkthrough
| File | Changes |
|---|---|
path/to/file.ts |
Brief description of what changed |
Findings
All issues merged, deduplicated, and sorted by severity. Each finding must follow this format:
[Category]
file/path.ts:LINE— Short title[Codex][Gemini][Both]Explanation of the issue and why it matters.
Suggested fix:
code suggestion here
Where:
- Category:
Bug,Security,Performance,Maintainability,Edge Case,Testing,Style - Source tag:
[Codex],[Gemini], or[Both]— indicates which reviewer(s) flagged it - Findings tagged
[Both]should appear first within their severity group (highest confidence) - If both flagged the same issue with different suggestions, present both and note the difference
If none: "No issues found by either reviewer."
Highlights
1-3 positive patterns that one or both reviewers called out, attributed by source.
Reviewer Agreement
| Metric | Details |
|---|---|
| Consensus | Issues both flagged independently (list count or summary) |
| Codex only | Findings unique to Codex |
| Gemini only | Findings unique to Gemini |
| Conflicts | Contradictory recommendations, if any (explain both perspectives) |
Verdict
Restate the verdict with a 1-2 sentence justification referencing the combined findings.
Include both full outputs here for reference, clearly labeled:
- Codex output: full text
- Gemini output: full text
Rules
- Always run both reviews in parallel using two Task agents in a single message — never sequentially
- Use the same review scope and options for both reviewers to ensure a fair comparison
- Deduplicate findings that both reviewers flagged — mark them as
[Both]with highest confidence and list first within their severity group - When reviewers contradict each other, present both perspectives and let the user decide
- Attribute every finding to its source (
[Codex],[Gemini], or[Both]) - If one CLI is not installed, warn the user and fall back to running only the available reviewer — do not fail entirely
- Sort findings by severity: Bug/Security first, then Performance/Maintainability/Edge Case/Testing, then Style
- The consolidated report should be shorter than both individual reports combined — synthesize, don't concatenate
- Always include raw reviewer outputs in a collapsible
<details>section at the end for transparency
More from trancong12102/agentskills
deps-dev
Look up the latest stable version of any open-source package across npm, PyPI, Go, Cargo, Maven, and NuGet. Use when the user asks 'what's the latest version of X', 'what version should I use', 'is X deprecated', 'how outdated is my package.json/requirements.txt/Cargo.toml', or needs version numbers for adding or updating dependencies. Also covers pinning versions, checking if packages are maintained, or comparing installed vs latest versions. Do NOT use for private/internal packages or for looking up documentation (use context7).
151council-review
Multi-perspective code review that synthesizes findings from multiple reviewers into a unified report. Use when the user asks to review code changes, audit a diff, check code quality, review a PR, review commits, or review uncommitted changes. Also covers 'code review', 'review my changes', 'check this before I merge', or wanting multiple perspectives on code. Do not use for documentation/markdown review or trivial single-line changes.
95oracle
Deep analysis and expert reasoning. Use when the user asks for 'oracle', 'second opinion', architecture analysis, elusive bug debugging, impact assessment, security reasoning, refactoring strategy, or trade-off evaluation — problems that benefit from deep, independent reasoning. Do not use for simple factual questions, code generation, code review (use council-review), or tasks needing file modifications.
93context7
Fetch up-to-date documentation for any open-source library or framework. Use when the user asks to look up docs, check an API, find code examples, or verify how a feature works — especially with a specific library name, version migration, or phrases like 'what's the current way to...' or 'the API might have changed'. Also covers setup and configuration docs. Do NOT use for general programming concepts, internal project code, or version lookups (use deps-dev).
86conventional-commit
Generates git commit messages following Conventional Commits 1.0.0 specification with semantic types (feat, fix, etc.), optional scope, and breaking change annotations. Use when committing code changes or creating commit messages.
58react-web-advanced
Web-specific React patterns for type-safe file-based routing, route-level data loading, server-side rendering, search param validation, code splitting, and list virtualization. Use when building React web apps with route loaders, SSR streaming, validated search params, lazy route splitting, or virtualizing large DOM lists. Do not use for React Native apps — use react-native-advanced instead.
45