Code Reviewer with Specialized Subagents

VerifiedCaution

Orchestrate specialized subagents to perform comprehensive code reviews on PRs or branches, generating a detailed markdown report with findings categorized by domain.

Sby Skills Guide Bot
DevelopmentAdvanced
406/2/2026
Claude Code
#code-review#git#subagent#orchestration

Recommended for

Our review

Orchestrates specialized subagents to perform a comprehensive code review and produce a Markdown report.

Strengths

  • Leverages multiple subagents with distinct expertise (Go, architecture, conventions, Bubble Tea, documentation).
  • Integrates with Git and GitHub to diff branches or pull requests.
  • Produces a structured report with prioritized recommendations (MUST, SHOULD, COULD).

Limitations

  • Requires the GitHub CLI (`gh`) for PR mode.
  • Focuses primarily on Go and Bubble Tea projects, less suitable for other languages.
  • Depends on the quality of the invoked subagents, which may not cover all aspects.
When to use it

Use this skill for a thorough, multi-domain code review before merging a branch or PR.

When not to use it

Avoid it for minor changes or when you need quick, informal feedback.

Security analysis

Caution
Quality score88/100

The skill orchestrates code review by running 'gh pr diff' and 'git diff' commands with user-provided arguments. Without input sanitization, a crafted PR number like '42; rm -rf /' could inject arbitrary commands. The operations are read-only and non-destructive in typical use, but the risk of injection warrants caution.

Findings
  • β€’The skill uses user-supplied arguments (e.g., --pr <number>) directly in shell commands without sanitization, which could allow command injection if the argument contains malicious shell metacharacters.
  • β€’The skill invokes external commands (gh, git) without validation of output or error handling, though these are read-only.

Examples

Review current branch changes
Review the changes on this branch compared to origin/main.
Review a specific PR with guidance
--pr 42 Focus on error handling and test coverage.

name: rocha-reviewer description: Perform code review using specialized subagents, producing a markdown report user-invocable: true argument-hint: [--pr <number>] [optional guidance]

Rocha Code Reviewer

You are a code review orchestrator. Your job is to coordinate specialized review subagents and produce a comprehensive markdown report.

Step 1: Parse Arguments

Parse $ARGUMENTS to determine the review mode:

  • PR mode: If --pr <number> is present, review the changes from that PR
  • Default mode: Review changes on the current branch compared to origin/main
  • Additional guidance: Any text after the flag (or all text if no flag) is guidance for reviewers

Step 2: Determine Changed Files

Run the appropriate git command to get changed files:

For PR mode:

gh pr diff <number> --name-only

For default mode (committed changes on branch):

git diff origin/main...HEAD --name-only

Filter to only relevant file types (.go, .md, etc.) and store the list.

Step 3: Gather Context

Before invoking subagents, gather context about what the changes are trying to accomplish:

  1. Run git log origin/main..HEAD --oneline to see commit messages
  2. Optionally run git diff origin/main..HEAD --stat to see scope of changes
  3. Summarize in 1-2 sentences what the task/feature is about

Step 4: Invoke Review Subagents in Parallel

Use the Task tool to spawn all four subagents simultaneously. Each subagent prompt MUST include:

  1. Task summary - What the changes are trying to accomplish
  2. Changed files - The list of files to review
  3. User guidance - Any additional focus areas from the user

Prompt template for each subagent:

## Context

**Task:** <1-2 sentence summary of what the changes accomplish>

**Changed files:**
- file1.go
- file2.go
- ...

**Additional guidance:** <user guidance or "None">

## Instructions

Review the changed files for your domain. Read each file and return findings using this format:

**πŸ”΄ [MUST] Title** (or 🟑 [SHOULD] or πŸ”΅ [COULD])

Location: `file:line`

Problem: Description

Fix: How to fix

If no issues found, say "No issues found."

Subagents to invoke:

  1. rocha-go-reviewer - Go idioms, best practices, error handling
  2. rocha-architecture-reviewer - Package structure, component boundaries
  3. rocha-convention-reviewer - Commits, naming, code style
  4. rocha-bubbletea-reviewer - TUI patterns, Bubble Tea idioms
  5. rocha-docs-reviewer - README, CLAUDE.md, code comments, inline docs

Step 5: Aggregate Results

Collect findings from all subagents and produce the final report:

Code Review Report

Branch: feature-branch | Compared to: origin/main | Files: 9

Go Review

🟑 [SHOULD] Unused error return value

Location: cmd/run.go:45

Problem: Error from session.Start() is ignored

Fix:

if err := session.Start(); err != nil { return err }

πŸ”΅ [COULD] Consider table-driven tests

Location: git/worktree_test.go:20-80

Problem: Multiple similar test cases with repeated setup

Fix: Refactor to table-driven tests for better maintainability

Architecture Review

🟑 [SHOULD] Component in wrong package

Location: cmd/helpers.go

Problem: Business logic mixed with CLI layer

Fix: Move ValidateSession() to operations/ package

Convention Review

πŸ”΄ [MUST] Missing conventional commit prefix

Location: Latest commit

Problem: Commit message "update session" lacks type prefix

Fix: Use format <type>: <description> e.g., fix: update session

Bubble Tea Review

πŸ”΅ [COULD] Consider using key.Matches

Location: ui/model.go:120

Problem: Direct key comparison instead of using key bindings

Fix: Use key.Matches(msg, m.keymap.Enter) for consistency

Documentation Review

🟑 [SHOULD] Outdated README section

Location: README.md:45-60

Problem: Installation section references old binary name

Fix: Update to reflect current installation method

Summary

| Metric | Count | |--------|-------| | Files reviewed | 9 | | πŸ”΄ MUST | 1 | | 🟑 SHOULD | 2 | | πŸ”΅ COULD | 2 |

Priority Items

  1. πŸ”΄ [MUST] Fix commit message format - Latest commit
  2. 🟑 [SHOULD] Handle ignored error - cmd/run.go:45
  3. 🟑 [SHOULD] Move business logic - cmd/helpers.go

Formatting Rules

Severity levels:

  • πŸ”΄ [MUST] - Must fix before merge (security, correctness, breaking changes)
  • 🟑 [SHOULD] - Should fix (code quality, maintainability)
  • πŸ”΅ [COULD] - Could improve (suggestions, minor enhancements)

Structure rules:

  • Bold severity with emoji, then Location/Problem/Fix on separate lines
  • Blank line between findings
  • Include a header line with branch info and file count
  • Use a table for the summary metrics

Notes

  • If a subagent returns no findings for its domain, include that section with "No issues found"
  • Findings must be actionable - include enough detail for another agent to implement the fix
  • Priority items should list the most important findings across all categories
  • Keep code examples short (1-3 lines) in the Fix section
Related skills