Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
{"required":[],"optional":[{"name":"unit_id","type":"string","description":"Task or subtask identifier (auto-generated if not provided)"},{"name":"base_sha","type":"string","description":"Git SHA before implementation (auto-detected via git merge-base HEAD main)"},{"name":"head_sha","type":"string","description":"Git SHA after implementation (auto-detected via git rev-parse HEAD)"},{"name":"implementation_summary","type":"string","description":"Summary of what was implemented (auto-generated from git log if not provided)"},{"name":"requirements","type":"string","description":"Requirements or acceptance criteria (reviewers will infer from code if not provided)"},{"name":"implementation_files","type":"array","items":"string","description":"List of files changed (auto-detected via git diff if not provided)"},{"name":"gate0_handoff","type":"object","description":"Full handoff from Gate 0 (only when called from ring:dev-cycle)"},{"name":"skip_reviewers","type":"array","items":"string","enum":"[Truncated]","description":"Reviewers to skip (use sparingly)"},{"name":"skip_preanalysis","type":"boolean","default":false,"description":"Skip pre-analysis pipeline for faster reviews (reviewers work without static analysis context)"},{"name":"preanalysis_timeout","type":"integer","default":300000,"description":"Timeout for pre-analysis pipeline in milliseconds (default: 5 minutes)"}]}
output_schema
{"format":"markdown","required_sections":[{"name":"Review Summary","pattern":"^## Review Summary","required":true},{"name":"Issues by Severity","pattern":"^## Issues by Severity","required":true},{"name":"Reviewer Verdicts","pattern":"^## Reviewer Verdicts","required":true},{"name":"CodeRabbit External Review","pattern":"^## CodeRabbit External Review","required":false},{"name":"Handoff to Next Gate","pattern":"^## Handoff to Next Gate","required":true}],"metrics":[{"name":"result","type":"enum","values":"[Truncated]"},{"name":"reviewers_passed","type":"string","description":"X/6 format"},{"name":"issues_critical","type":"integer"},{"name":"issues_high","type":"integer"},{"name":"issues_medium","type":"integer"},{"name":"issues_low","type":"integer"},{"name":"iterations","type":"integer"},{"name":"coderabbit_status","type":"enum","values":"[Truncated]"},{"name":"coderabbit_validation_mode","type":"enum","values":"[Truncated]","description":"Granularity of CodeRabbit validation"},{"name":"coderabbit_units_validated","type":"integer","description":"Number of units (subtasks or tasks) validated by CodeRabbit"},{"name":"coderabbit_units_passed","type":"integer","description":"Number of units that passed CodeRabbit validation"},{"name":"coderabbit_issues","type":"integer","description":"Total number of issues found by CodeRabbit across all units (0 if skipped)"}]}
examples
[{"name":"Feature review","input":{"unit_id":"task-001","base_sha":"abc123","head_sha":"def456","implementation_summary":"Added user authentication with JWT","requirements":"AC-1: User can login, AC-2: Invalid password returns error"},"expected_output":"## Review Summary\n**Status:** PASS\n**Reviewers:** 6/6 PASS\n\n## Issues by Severity\n| Severity | Count |\n|----------|-------|\n| Critical | 0 |\n| High | 0 |\n| Medium | 0 |\n| Low | 2 |\n\n## Reviewer Verdicts\n| Reviewer | Verdict |\n|----------|---------|\n| ring:code-reviewer | ✅ PASS |\n| ring:business-logic-reviewer | ✅ PASS |\n| ring:security-reviewer | ✅ PASS |\n| ring:test-reviewer | ✅ PASS |\n| ring:nil-safety-reviewer | ✅ PASS |\n| ring:consequences-reviewer | ✅ PASS |\n\n## Handoff to Next Gate\n- Ready for Gate 5: YES"}]
Code Review (Gate 4)
Overview
Dispatch all six reviewer subagents in parallel for fast, comprehensive feedback:
Step 1: Gather Context (Auto-Detect if Not Provided)
This skill supports TWO modes:
1. WITH INPUTS: Called by any skill/user that provides structured inputs (unit_id, base_sha, etc.)
2. STANDALONE: Called directly without inputs - auto-detects everything from git
FOR EACH INPUT, check if provided OR auto-detect:
1. unit_id:
IF provided → use it
ELSE → generate: "review-" + timestamp (e.g., "review-20241222-143052")
2. base_sha:
IF provided → use it
ELSE → Execute: git merge-base HEAD main
IF git fails → Execute: git rev-parse HEAD~10 (fallback to last 10 commits)
3. head_sha:
IF provided → use it
ELSE → Execute: git rev-parse HEAD
4. implementation_files:
IF provided → use it
ELSE → Execute: git diff --name-only [base_sha] [head_sha]
5. implementation_summary:
IF provided → use it
ELSE → Execute: git log --oneline [base_sha]..[head_sha]
Format as: "Changes: [list of commit messages]"
6. requirements:
IF provided → use it
ELSE → Set to: "Infer requirements from code changes and commit messages"
(Reviewers will analyze code to understand intent)
AFTER AUTO-DETECTION, display context:
┌─────────────────────────────────────────────────────────────────┐
│ 📋 CODE REVIEW CONTEXT │
├─────────────────────────────────────────────────────────────────┤
│ Unit ID: [unit_id] │
│ Base SHA: [base_sha] │
│ Head SHA: [head_sha] │
│ Files Changed: [count] files │
│ Commits: [count] commits │
│ │
│ Dispatching 6 reviewers in parallel... │
└─────────────────────────────────────────────────────────────────┘
Ce SKILL.md est tres volumineux, SkillsMP affiche donc ici seulement la premiere section.Voir sur GitHub
MANDATORY: Run static analysis, AST extraction, and call graph analysis BEFORE dispatching reviewers. This provides critical context that significantly improves review quality.
Skip Override: The skip_preanalysis parameter allows bypassing this step ONLY when explicitly requested by the user. This is NOT recommended.
Step 2.5.1: Install and Run Mithril
# ⚠️ SYNC NOTE: This Mithril install logic is also in default/commands/codereview.md (Step 0).
# If you change the install pattern or CLI flags, update both locations.
# Check if mithril is available
if ! command -v mithril &> /dev/null; then
echo "mithril not found. Installing..."
if command -v go &> /dev/null; then
go install github.com/lerianstudio/mithril@latest
GOPATH_DIR="$(go env GOPATH)"
[[ -n "$GOPATH_DIR" ]] && export PATH="$PATH:$GOPATH_DIR/bin"
else
echo "Go is required to install mithril. Install Go from https://go.dev/dl/"
echo "DEGRADED MODE: Proceeding without pre-analysis"
fi
fi
# Run pre-analysis pipeline
if command -v mithril &> /dev/null; then
if [[ -z "$BASE_SHA" || -z "$HEAD_SHA" ]]; then
echo "WARNING: BASE_SHA or HEAD_SHA not set"
echo "DEGRADED MODE: Proceeding without pre-analysis"
elif mithril --base="$BASE_SHA" --head="$HEAD_SHA" --output=docs/codereview --verbose; then
echo "Pre-analysis pipeline completed successfully"
else
echo "WARNING: Pre-analysis pipeline failed"
echo "DEGRADED MODE: Proceeding without pre-analysis"
fi
else
echo "WARNING: mithril not available"
echo "DEGRADED MODE: Reviewers will proceed WITHOUT static analysis context."
fi
Timeout: Use preanalysis_timeout input (default 5 minutes)
On success: Set preanalysis_state.success = true
On failure: Display warning, set preanalysis_state.success = false, continue to Step 3
⛔ CRITICAL: All 6 reviewers MUST be dispatched in a SINGLE message with 6 Task calls.
# Task 1: Code Reviewer
Task:
subagent_type: "ring:code-reviewer"
description: "Code review for [unit_id]"
prompt: |
## Code Review Request
**Unit ID:** [unit_id]
**Base SHA:** [base_sha]
**Head SHA:** [head_sha]
## What Was Implemented
[implementation_summary]
## Requirements
[requirements]
## Files Changed
[implementation_files or "Use git diff"]
## Pre-Analysis Context
**Static Analysis Results:**
The following findings were automatically extracted by the pre-analysis pipeline.
Use these to INFORM your review, not REPLACE your analysis.
---
[IF preanalysis_state.context["ring:code-reviewer"] exists AND is not empty:]
[INSERT the content of preanalysis_state.context["ring:code-reviewer"]]
[ELSE:]
_No pre-analysis context available. Perform standard review based on git diff._
---
## Your Focus
- Architecture and design patterns
- Code quality and maintainability
- Naming conventions
- Error handling patterns
- Performance concerns
## Required Output
### VERDICT: PASS / FAIL
### Issues Found
| Severity | Description | File:Line | Recommendation |
|----------|-------------|-----------|----------------|
| [CRITICAL/HIGH/MEDIUM/LOW/COSMETIC] | [issue] | [location] | [fix] |
### What Was Done Well
[positive observations]
# Task 2: Business Logic Reviewer
Task:
subagent_type: "ring:business-logic-reviewer"
description: "Business logic review for [unit_id]"
prompt: |
## Business Logic Review Request
**Unit ID:** [unit_id]
**Base SHA:** [base_sha]
**Head SHA:** [head_sha]
## What Was Implemented
[implementation_summary]
## Requirements
[requirements]
## Pre-Analysis Context
**Static Analysis Results:**
The following findings were automatically extracted by the pre-analysis pipeline.
Use these to INFORM your review, not REPLACE your analysis.
---
[IF preanalysis_state.context["ring:business-logic-reviewer"] exists AND is not empty:]
[INSERT the content of preanalysis_state.context["ring:business-logic-reviewer"]]
[ELSE:]
_No pre-analysis context available. Perform standard review based on git diff._
---
## Your Focus
- Domain correctness
- Business rules implementation
- Edge cases handling
- Requirements coverage
- Data validation
## Required Output
### VERDICT: PASS / FAIL
### Issues Found
| Severity | Description | File:Line | Recommendation |
|----------|-------------|-----------|----------------|
| [CRITICAL/HIGH/MEDIUM/LOW/COSMETIC] | [issue] | [location] | [fix] |
### Requirements Traceability
| Requirement | Status | Evidence |
|-------------|--------|----------|
| [req] | ✅/❌ | [file:line] |
# Task 3: Security Reviewer
Task:
subagent_type: "ring:security-reviewer"
description: "Security review for [unit_id]"
prompt: |
## Security Review Request
**Unit ID:** [unit_id]
**Base SHA:** [base_sha]
**Head SHA:** [head_sha]
## What Was Implemented
[implementation_summary]
## Requirements
[requirements]
## Pre-Analysis Context
**Static Analysis Results:**
The following findings were automatically extracted by the pre-analysis pipeline.
Use these to INFORM your review, not REPLACE your analysis.
---
[IF preanalysis_state.context["ring:security-reviewer"] exists AND is not empty:]
[INSERT the content of preanalysis_state.context["ring:security-reviewer"]]
[ELSE:]
_No pre-analysis context available. Perform standard review based on git diff._
---
## Your Focus
- Authentication and authorization
- Input validation
- SQL injection, XSS, CSRF
- Sensitive data handling
- OWASP Top 10 risks
## Required Output
### VERDICT: PASS / FAIL
### Issues Found
| Severity | Description | File:Line | OWASP Category | Recommendation |
|----------|-------------|-----------|----------------|----------------|
| [CRITICAL/HIGH/MEDIUM/LOW] | [issue] | [location] | [A01-A10] | [fix] |
### Security Checklist
| Check | Status |
|-------|--------|
| Input validation | ✅/❌ |
| Auth checks | ✅/❌ |
| No hardcoded secrets | ✅/❌ |
# Task 4: Test Reviewer
Task:
subagent_type: "ring:test-reviewer"
description: "Test quality review for [unit_id]"
prompt: |
## Test Quality Review Request
**Unit ID:** [unit_id]
**Base SHA:** [base_sha]
**Head SHA:** [head_sha]
## What Was Implemented
[implementation_summary]
## Requirements
[requirements]
## Pre-Analysis Context
**Static Analysis Results:**
The following findings were automatically extracted by the pre-analysis pipeline.
Use these to INFORM your review, not REPLACE your analysis.
---
[IF preanalysis_state.context["ring:test-reviewer"] exists AND is not empty:]
[INSERT the content of preanalysis_state.context["ring:test-reviewer"]]
[ELSE:]
_No pre-analysis context available. Perform standard review based on git diff._
---
## Your Focus
- Test coverage for business logic
- Edge case testing (empty, null, boundary)
- Error path coverage
- Test independence and isolation
- Assertion quality (not just "no error")
- Test anti-patterns (testing mock behavior)
## Required Output
### VERDICT: PASS / FAIL
### Issues Found
| Severity | Description | File:Line | Recommendation |
|----------|-------------|-----------|----------------|
| [CRITICAL/HIGH/MEDIUM/LOW] | [issue] | [location] | [fix] |
### Test Coverage Analysis
| Test Type | Count | Coverage |
|-----------|-------|----------|
| Unit | [N] | [areas] |
| Integration | [N] | [areas] |
| E2E | [N] | [areas] |
# Task 5: Nil-Safety Reviewer
Task:
subagent_type: "ring:nil-safety-reviewer"
description: "Nil/null safety review for [unit_id]"
prompt: |
## Nil-Safety Review Request
**Unit ID:** [unit_id]
**Base SHA:** [base_sha]
**Head SHA:** [head_sha]
**Languages:** [Go|TypeScript|both - detect from files]
## What Was Implemented
[implementation_summary]
## Requirements
[requirements]
## Pre-Analysis Context
**Static Analysis Results:**
The following findings were automatically extracted by the pre-analysis pipeline.
Use these to INFORM your review, not REPLACE your analysis.
---
[IF preanalysis_state.context["ring:nil-safety-reviewer"] exists AND is not empty:]
[INSERT the content of preanalysis_state.context["ring:nil-safety-reviewer"]]
[ELSE:]
_No pre-analysis context available. Perform standard review based on git diff._
---
## Your Focus
- Nil/null pointer risks in changed code
- Missing nil guards before dereference
- Map access without ok check (Go)
- Type assertions without ok check (Go)
- Optional chaining misuse (TypeScript)
- Error-then-use patterns
## Required Output
### VERDICT: PASS / FAIL
### Issues Found
| Severity | Description | File:Line | Recommendation |
|----------|-------------|-----------|----------------|
| [CRITICAL/HIGH/MEDIUM/LOW] | [issue] | [location] | [fix] |
### Nil Risk Trace
[For each risk: Source → Propagation → Dereference point]
# Task 6: Consequences Reviewer
Task:
subagent_type: "ring:consequences-reviewer"
description: "Consequences review for [unit_id]"
prompt: |
## Consequences Review Request
**Unit ID:** [unit_id]
**Base SHA:** [base_sha]
**Head SHA:** [head_sha]
## What Was Implemented
[implementation_summary]
## Requirements
[requirements]
## Pre-Analysis Context
**Static Analysis Results:**
The following findings were automatically extracted by the pre-analysis pipeline.
Use these to INFORM your review, not REPLACE your analysis.
---
[IF preanalysis_state.context["ring:consequences-reviewer"] exists AND is not empty:]
[INSERT the content of preanalysis_state.context["ring:consequences-reviewer"]]
[ELSE:]
_No pre-analysis context available. Perform standard review based on git diff._
---
## Your Focus
- Caller chain impact analysis
- Consumer contract integrity
- Shared state and configuration consequences
- Type and interface propagation
- Error handling chain consequences
- Database/schema ripple effects
## Required Output
### VERDICT: PASS / FAIL
### Issues Found
| Severity | Description | File:Line | Recommendation |
|----------|-------------|-----------|----------------|
| [CRITICAL/HIGH/MEDIUM/LOW] | [issue] | [location] | [fix] |
### Impact Trace Analysis
[For each changed symbol: callers found, consumers found, impact status]
Step 4: Wait for All Reviewers and Parse Output
Wait for all 6 Task calls to complete.
For each reviewer:
1. Extract VERDICT (PASS/FAIL)
2. Extract Issues Found table
3. Categorize issues by severity
review_state.reviewers.code_reviewer = {
verdict: [PASS/FAIL],
issues: [parsed issues]
}
// ... same for other reviewers
Aggregate all issues by severity:
review_state.aggregated_issues.critical = [all critical from all reviewers]
review_state.aggregated_issues.high = [all high from all reviewers]
// ... etc
Step 5: Handle Results by Severity
Count blocking issues:
blocking_count = critical.length + high.length + medium.length
IF blocking_count == 0:
→ All reviewers PASS
→ Proceed to Step 8 (Success)
IF blocking_count > 0:
→ review_state.iterations += 1
→ IF iterations >= max_iterations: Go to Step 9 (Escalate)
→ Go to Step 6 (Dispatch Fixes)
Step 6: Dispatch Fixes to Implementation Agent
⛔ CRITICAL: You are an ORCHESTRATOR. You CANNOT edit source files directly.You MUST dispatch the implementation agent to fix ALL review issues.
Applies to: Step 6 (Fix dispatch after Ring reviewers) & Step 7.5.3 (Fix dispatch after CodeRabbit)
Step 7: Re-Run All Reviewers After Fixes
After fixes committed:
1. Get new HEAD_SHA
2. Go back to Step 3 (dispatch all 6 reviewers again)
⛔ CRITICAL: Always re-run ALL 6 reviewers after fixes.
Do NOT cherry-pick reviewers.
⛔ NEW APPROACH: CodeRabbit validates EACH subtask/task as it completes, accumulating findings to a file.
CodeRabbit Integration Overview
┌─────────────────────────────────────────────────────────────────┐
│ CODERABBIT PER-UNIT VALIDATION FLOW │
├─────────────────────────────────────────────────────────────────┤
│ │
│ DURING REVIEW (after each subtask/task Ring reviewers pass): │
│ 1. Run CodeRabbit for that unit's files │
│ 2. Append findings to .coderabbit-findings.md │
│ 3. Continue to next unit │
│ │
│ BEFORE COMMIT (Step 8): │
│ 1. Display accumulated .coderabbit-findings.md │
│ 2. User decides: fix issues OR acknowledge and proceed │
│ │
│ BENEFITS: │
│ • Catches issues close to when code was written │
│ • Smaller scope = faster reviews (7-30 min per unit) │
│ • Issues isolated to specific units, easier to fix │
│ • Accumulated file provides audit trail │
│ │
└─────────────────────────────────────────────────────────────────┘
Rate Limits (Official - per developer per repository per hour)
Limit Type
Value
Notes
Files reviewed
200 files/hour
Per review
Reviews
3 back-to-back, then 4/hour
7 reviews possible in first hour
Conversations
25 back-to-back, then 50/hour
For follow-up questions
⏱️ TIMING: Each CodeRabbit review takes 7-30+ minutes depending on scope.
Run in background and check periodically for completion.
Common Commands Reference
CodeRabbit Installation Check:
which coderabbit || which cr
Used in Step 7.5.1 and after installation to verify CLI availability.
⚠️ PREREQUISITES & ENVIRONMENT REQUIREMENTS
Before attempting Step 7.5, verify your environment supports the required operations:
Requirement
Local Dev
CI/CD
Containerized
Remote/SSH
curl | sh install
✅ Yes
⚠️ May require elevated permissions
❌ Often blocked
⚠️ Depends on config
Browser auth (coderabbit auth login)
✅ Yes
❌ No browser
❌ No browser
❌ No browser
Write to $HOME/.coderabbit/
✅ Yes
⚠️ Ephemeral
⚠️ Ephemeral
✅ Usually
Internet access to cli.coderabbit.ai
✅ Yes
⚠️ Check firewall
⚠️ Check firewall
⚠️ Check firewall
⛔ HARD STOP CONDITIONS - Skip Step 7.5 if ANY apply:
Running in containerized environment without persistent storage
CI/CD pipeline without pre-installed CodeRabbit CLI
Non-interactive environment (no TTY for browser auth)
Network restrictions blocking cli.coderabbit.ai
Read-only filesystem
Environment-Specific Guidance
Local Development (RECOMMENDED)
Standard flow works: curl | sh install + browser authentication.
CI/CD Pipelines
Option A: Pre-install in CI image
# Add to your CI Dockerfile
RUN curl -fsSL https://cli.coderabbit.ai/install.sh | sh
Option B: Use API token authentication (headless)
# Set token via environment variable (add to CI secrets)
export CODERABBIT_API_TOKEN="your-api-token"
coderabbit auth login --token "$CODERABBIT_API_TOKEN"
Option C: Skip CodeRabbit in CI, run locally
# In CI config, set env var to auto-skip
export SKIP_CODERABBIT_REVIEW=true
Containerized/Docker Environments
# Option 1: Mount credentials from host
docker run -v ~/.coderabbit:/root/.coderabbit ...
# Option 2: Pass token as env var
docker run -e CODERABBIT_API_TOKEN="..." ...
# Option 3: Pre-bake into image (not recommended for tokens)
Non-Interactive/Headless Authentication
# Generate API token at: https://app.coderabbit.ai/settings/api-tokens
# Then authenticate without browser:
coderabbit auth login --token "cr_xxxxxxxxxxxxx"
Step 7.5 Flow Logic
┌─────────────────────────────────────────────────────────────────┐
│ ✅ ALL 3 RING REVIEWERS PASSED │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Checking CodeRabbit CLI availability... │
│ │
│ CodeRabbit provides additional AI-powered code review that │
│ catches race conditions, memory leaks, security vulnerabilities,│
│ and edge cases that may complement Ring reviewers. │
│ │
└─────────────────────────────────────────────────────────────────┘
⛔ HARD GATE: CodeRabbit Execution Rules (NON-NEGOTIABLE)
Scenario
Rule
Action
Installed & authenticated
MANDATORY - CANNOT skip
Run CodeRabbit review, no prompt
Not installed
MUST ask user about installation
Present installation option
User declines installation
Optional - can proceed
Skip and continue to Step 8
Why this distinction:
If CodeRabbit IS installed → User has committed to using it → MUST run
If CodeRabbit is NOT installed → User choice to add it → MUST ask, but can decline
FLOW:
1. Run CodeRabbit Installation Check
2. IF installed AND authenticated → Run CodeRabbit (MANDATORY, NO prompt, CANNOT skip)
3. IF installed BUT NOT authenticated → Guide authentication (REQUIRED before proceeding)
4. IF NOT installed → MUST ask user about installation (REQUIRED prompt)
5. IF user declines installation → Skip CodeRabbit, proceed to Step 8 (only valid skip path)
Anti-Rationalization for CodeRabbit Execution
Rationalization
Why It's WRONG
Required Action
"CodeRabbit is optional, I'll skip it"
If installed, it's MANDATORY. Optional only means installation is optional.
Run CodeRabbit if installed
"Ring reviewers passed, that's enough"
Different tools catch different issues. CodeRabbit complements Ring.
Run CodeRabbit if installed
"User didn't ask for CodeRabbit"
User installed it. Installation = consent to mandatory execution.
Run CodeRabbit if installed
"Takes too long, skip this time"
Time is irrelevant. Installed = mandatory.
Run CodeRabbit if installed
"I'll just proceed without asking about install"
MUST ask every user if they want to install. No silent skips.
IF INSTALLED AND AUTHENTICATED → MANDATORY EXECUTION (CANNOT SKIP):
┌─────────────────────────────────────────────────────────────────┐
│ ✅ CodeRabbit CLI detected - MANDATORY EXECUTION │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CodeRabbit CLI is installed and authenticated. │
│ │
│ ⛔ CodeRabbit review is MANDATORY when installed. │
│ This step CANNOT be skipped. Proceeding automatically... │
│ │
└─────────────────────────────────────────────────────────────────┘
→ Proceed directly to Step 7.5.2 (Run CodeRabbit Review) - NO user prompt, NO skip option
IF NOT INSTALLED → MUST ASK USER (REQUIRED PROMPT):
⛔ You MUST present this prompt to the user. Silent skips are FORBIDDEN.
┌─────────────────────────────────────────────────────────────────┐
│ ⚠️ CodeRabbit CLI not found - INSTALLATION PROMPT REQUIRED │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CodeRabbit CLI is not installed on your system. │
│ │
│ CodeRabbit provides additional AI-powered review that catches: │
│ • Race conditions and concurrency issues │
│ • Memory leaks and resource management │
│ • Security vulnerabilities │
│ • Edge cases missed by other reviewers │
│ │
│ ⛔ You MUST choose one of the following options: │
│ │
│ (a) Yes, install CodeRabbit CLI (I'll guide you) │
│ (b) No, skip CodeRabbit and proceed to Gate 5 │
│ │
│ ⚠️ ENVIRONMENT CHECK: │
│ • Interactive terminal with browser? → Standard install │
│ • CI/headless? → Requires API token auth │
│ • Container? → See Environment-Specific Guidance above │
│ │
└─────────────────────────────────────────────────────────────────┘
If user selects (a) Yes, install:
→ Proceed to Installation Flow below
If user selects (b) No, skip:
→ Record: "CodeRabbit review: SKIPPED (not installed, user declined installation)"
→ Proceed to Step 8 (Success Output)
→ This is the ONLY valid path to skip CodeRabbit
Step 7.5.1a: CodeRabbit Installation Flow
┌─────────────────────────────────────────────────────────────────┐
│ 📦 INSTALLING CODERABBIT CLI │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ⚠️ ENVIRONMENT CHECK FIRST: │
│ │
│ This installation requires: │
│ • curl command available │
│ • Write access to $HOME or /usr/local/bin │
│ • Internet access to cli.coderabbit.ai │
│ • Non-containerized environment (or persistent storage) │
│ │
│ If in CI/container, see "Environment-Specific Guidance" above. │
│ │
└─────────────────────────────────────────────────────────────────┘
# Step 2a: Authenticate with CodeRabbit (opens browser)
# ⚠️ Requires: GUI environment with default browser
coderabbit auth login
If user selects (b) API token:
# Step 2b: Authenticate with API token (headless)
# Get your token from: https://app.coderabbit.ai/settings/api-tokens
coderabbit auth login --token "cr_xxxxxxxxxxxxx"
┌─────────────────────────────────────────────────────────────────┐
│ ❌ CodeRabbit CLI installation failed │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Error: [error message from curl/sh] │
│ │
│ Troubleshooting: │
│ • Check internet connection │
│ • Try manual install: https://docs.coderabbit.ai/cli/overview │
│ • macOS/Linux only (Windows not supported yet) │
│ │
│ Would you like to: │
│ (a) Retry installation │
│ (b) Skip CodeRabbit and proceed to Gate 5 │
│ │
└─────────────────────────────────────────────────────────────────┘
Step 7.5.2: Run CodeRabbit Review
⛔ GRANULAR VALIDATION: CodeRabbit MUST validate at the most granular level available.
DETERMINE VALIDATION SCOPE:
1. Check if current work has subtasks (from gate0_handoff or implementation context)
2. IF subtasks exist → Validate EACH SUBTASK separately
3. IF no subtasks → Validate the TASK as a whole
WHY GRANULAR VALIDATION:
- Subtask-level validation catches issues early
- Easier to pinpoint which subtask introduced problems
- Prevents "works for task A, breaks task B" scenarios
- Enables incremental fixes without re-running entire review
Step 7.5.2a: Determine Validation Scope
validation_scope = {
mode: null, // "subtask" or "task"
units: [], // list of {id, files, commits} to validate
current_index: 0
}
IF gate0_handoff.subtasks exists AND gate0_handoff.subtasks.length > 0:
→ validation_scope.mode = "subtask"
→ FOR EACH subtask in gate0_handoff.subtasks:
→ Get files changed by this subtask (from commits or file mapping)
→ Add to validation_scope.units: {
id: subtask.id,
name: subtask.name,
files: [files touched by this subtask],
base_sha: [sha before subtask],
head_sha: [sha after subtask]
}
Display:
┌─────────────────────────────────────────────────────────────────┐
│ 📋 CODERABBIT VALIDATION MODE: SUBTASK-LEVEL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Detected [N] subtasks. Will validate each separately: │
│ │
│ 1. [subtask-1-id]: [subtask-1-name] │
│ Files: [file1.go, file2.go] │
│ │
│ 2. [subtask-2-id]: [subtask-2-name] │
│ Files: [file3.go, file4.go] │
│ │
│ ... (up to N subtasks) │
│ │
└─────────────────────────────────────────────────────────────────┘
ELSE:
→ validation_scope.mode = "task"
→ Add single unit: {
id: unit_id,
name: implementation_summary,
files: implementation_files,
base_sha: base_sha,
head_sha: head_sha
}
Display:
┌─────────────────────────────────────────────────────────────────┐
│ 📋 CODERABBIT VALIDATION MODE: TASK-LEVEL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ No subtasks detected. Validating entire task: │
│ │
│ Task: [unit_id] │
│ Files: [N] files changed │
│ │
└─────────────────────────────────────────────────────────────────┘
Step 7.5.2b: Run CodeRabbit for Each Validation Unit
coderabbit_results = {
overall_status: "PASS", // PASS only if ALL units pass
units: []
}
FOR EACH unit IN validation_scope.units:
Display:
┌─────────────────────────────────────────────────────────────────┐
│ 🔍 VALIDATING: [unit.id] ([current]/[total]) │
├─────────────────────────────────────────────────────────────────┤
│ Name: [unit.name] │
│ Files: [unit.files.join(", ")] │
└─────────────────────────────────────────────────────────────────┘
# Run CodeRabbit review
# ⏱️ TIMING: 7-30+ minutes per review. Run in background if possible.
# Compare against base branch
coderabbit --prompt-only --type uncommitted --base [base_branch]
# Compare against specific commit on current branch
coderabbit --prompt-only --type uncommitted --base-commit [unit.base_sha]
# The command is synchronous - it completes when output is returned
Parse output and record:
unit_result = {
id: unit.id,
status: "PASS" | "ISSUES_FOUND",
issues: {
critical: [list],
high: [list],
medium: [list],
low: [list]
}
}
coderabbit_results.units.push(unit_result)
IF unit_result.issues.critical.length > 0 OR unit_result.issues.high.length > 0:
→ coderabbit_results.overall_status = "ISSUES_FOUND"
─────────────────────────────────────────────────────────────────
⛔ MANDATORY: APPEND FINDINGS TO .coderabbit-findings.md
─────────────────────────────────────────────────────────────────
After EACH unit validation, append results to findings file:
IF .coderabbit-findings.md does NOT exist:
→ Create file with header (see "Findings File Format" below)
APPEND to .coderabbit-findings.md:
⛔ BEFORE generating success output, MUST display accumulated CodeRabbit findings.
Step 8.1: Display Accumulated CodeRabbit Findings
IF .coderabbit-findings.md exists:
┌─────────────────────────────────────────────────────────────────┐
│ 📋 CODERABBIT FINDINGS - ACCUMULATED DURING REVIEW │
├─────────────────────────────────────────────────────────────────┤
│ │
│ The following issues were identified by CodeRabbit during the │
│ review process. Review before proceeding to commit. │
│ │
└─────────────────────────────────────────────────────────────────┘
→ Display contents of .coderabbit-findings.md
→ Show summary table:
┌─────────────────────────────────────────────────────────────────┐
│ 📊 CODERABBIT FINDINGS SUMMARY │
├─────────────────────────────────────────────────────────────────┤
│ │
│ | Severity | Count | Status | │
│ |----------|-------|--------| │
│ | Critical | [N] | [pending/fixed] | │
│ | High | [N] | [pending/fixed] | │
│ | Medium | [N] | [pending/fixed] | │
│ | Low | [N] | [pending/fixed] | │
│ │
│ Total Issues: [N] | Fixed: [N] | Pending: [N] │
│ │
└─────────────────────────────────────────────────────────────────┘
→ Ask user:
┌─────────────────────────────────────────────────────────────────┐
│ ❓ ACTION REQUIRED │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [N] CodeRabbit issues are pending. What would you like to do? │
│ │
│ (a) Fix all pending issues now (dispatch implementation agent)│
│ (b) Review and fix issues one-by-one (interactive mode) │
│ (c) Acknowledge and proceed to commit (issues documented) │
│ │
│ Note: Choosing (c) will include findings file in commit for │
│ tracking. Issues remain documented for future fixing. │
│ │
└─────────────────────────────────────────────────────────────────┘
IF user selects (a) Fix all issues:
→ Dispatch implementation agent with ALL pending issues from findings file
→ After fixes, update .coderabbit-findings.md (mark issues as FIXED)
→ Re-run CodeRabbit validation for affected files
→ Loop back to Step 8.1 to display updated findings
IF user selects (b) Interactive mode (one-by-one):
→ Go to Step 8.1.1 (Interactive Issue Review)
IF user selects (c) Acknowledge and proceed:
→ Record: "CodeRabbit issues acknowledged by user"
→ Include .coderabbit-findings.md in commit (for audit trail)
→ Proceed to Step 8.2 (Success Output)
─────────────────────────────────────────────────────────────────
Step 8.1.1: Interactive Issue Review (One-by-One)
─────────────────────────────────────────────────────────────────
issues_to_fix = []
issues_to_skip = []
FOR EACH issue IN pending_issues (ordered by severity: CRITICAL → HIGH → MEDIUM → LOW):
Display:
┌─────────────────────────────────────────────────────────────────┐
│ 🔍 ISSUE [current]/[total] - [SEVERITY] │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Unit: [unit.id] - [unit.name] │
│ File: [file:line] │
│ │
│ Description: │
│ [issue description] │
│ │
│ Code Context: │
│ [code snippet around the issue] │
│ │
│ Why it matters: │
│ [explanation of impact] │
│ │
│ Recommendation: │
│ [suggested fix] │
│ │
├─────────────────────────────────────────────────────────────────┤
│ What would you like to do with this issue? │
│ │
│ (f) Fix this issue │
│ (s) Skip this issue (acknowledge) │
│ (a) Fix ALL remaining issues │
│ (k) Skip ALL remaining issues │
│ │
└─────────────────────────────────────────────────────────────────┘
IF user selects (f) Fix:
→ Add to issues_to_fix list
→ Continue to next issue
IF user selects (s) Skip:
→ Add to issues_to_skip list
→ Continue to next issue
IF user selects (a) Fix ALL remaining:
→ Add current + all remaining to issues_to_fix list
→ Break loop
IF user selects (k) Skip ALL remaining:
→ Add current + all remaining to issues_to_skip list
→ Break loop
AFTER loop completes:
Display summary:
┌─────────────────────────────────────────────────────────────────┐
│ 📋 INTERACTIVE REVIEW COMPLETE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Issues to fix: [N] │
│ [list of issues selected for fixing] │
│ │
│ Issues to skip: [N] │
│ [list of issues selected to skip] │
│ │
│ Proceed with this selection? (y/n) │
│ │
└─────────────────────────────────────────────────────────────────┘
IF user confirms (y):
IF issues_to_fix.length > 0:
→ Dispatch implementation agent with ONLY issues_to_fix
→ After fixes, update .coderabbit-findings.md:
- Mark fixed issues as FIXED
- Mark skipped issues as ACKNOWLEDGED
→ Re-run CodeRabbit validation for affected files
→ Loop back to Step 8.1
ELSE:
→ All issues skipped/acknowledged
→ Proceed to Step 8.2 (Success Output)
IF user cancels (n):
→ Return to Step 8.1 main prompt
ELSE (no findings file exists):
→ CodeRabbit was skipped or found no issues
→ Proceed directly to Step 8.2 (Success Output)
Step 8.1.5: Visual Review Report
MANDATORY: Generate a visual HTML report before presenting the review summary.
Invokes Skill("ring:visual-explainer") to produce a self-contained HTML page showing review results visually. This complements the markdown output with an interactive browser view.
Read the code-diff template first: Read default/skills/visual-explainer/templates/code-diff.html to absorb the patterns before generating.
Generate the HTML report with these sections:
1. Review Dashboard
Overall status (PASS/FAIL) with large status indicator
VISUAL REPORT: Generate the same visual HTML report as Step 8.1.5, but with FAIL status prominently displayed. The report highlights unresolved issues in red, shows which reviewers still have FAIL verdicts, and includes the full iteration history. Save to docs/codereview/review-report-{unit_id}.html and open in browser.
Generate skill output:
## Review Summary
**Status:** FAIL
**Unit ID:** [unit_id]
**Iterations:** [max_iterations] (MAX REACHED)
## Issues by Severity
| Severity | Count |
|----------|-------|
| Critical | [count] |
| High | [count] |
| Medium | [count] |
## Unresolved Issues
[list all Critical/High/Medium still open]
## Reviewer Verdicts
| Reviewer | Verdict |
|----------|---------|
| ring:code-reviewer | [PASS/FAIL] |
| ring:business-logic-reviewer | [PASS/FAIL] |
| ring:security-reviewer | [PASS/FAIL] |
## Handoff to Next Gate
- Review status: FAILED
- Unresolved blocking issues: [count]
- Ready for Gate 5: NO
- **Action Required:** User must manually resolve issues
⛔ ESCALATION: Max iterations (3) reached. Blocking issues remain.
Blocker Criteria
STOP and report if:
Decision Type
Blocker Condition
Required Action
Missing git context
Cannot determine base_sha or head_sha
STOP and request valid git context
No files changed
git diff returns empty between refs
STOP and verify implementation exists
Max iterations exceeded
3 fix iterations completed but issues remain
STOP and escalate to user for manual resolution
Pre-analysis pipeline fails
Mithril installation fails or execution returns error
Report and proceed in DEGRADED MODE
All reviewers fail to dispatch
Task tool unavailable or errors
STOP and report infrastructure issue
Cannot Be Overridden
The following requirements CANNOT be waived:
MUST dispatch ALL 6 reviewers in parallel (not sequential, not partial)
CANNOT edit source files directly - MUST dispatch implementation agent for fixes
MUST re-run ALL 6 reviewers after any fix (no cherry-picking reviewers)
CANNOT skip CodeRabbit if installed and authenticated
MUST fix Critical, High, and Medium severity issues before Gate 5