7.1 KiB
name, description, trigger, skip_when, sequence
| name | description | trigger | skip_when | sequence | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| requesting-code-review | Parallel code review dispatch - sends to 3 specialized reviewers (code, business-logic, security) simultaneously for comprehensive feedback. | - After completing major feature implementation - After completing task in subagent-driven-development - Before merge to main branch - After fixing complex bug | - Trivial change (<20 lines, no logic change) → verify manually - Still in development → finish implementation first - Already reviewed and no changes since → proceed |
|
Requesting Code Review
Dispatch all three reviewer subagents in parallel for fast, comprehensive feedback.
Core principle: Review early, review often. Parallel execution provides 3x faster feedback with comprehensive coverage.
Review Order (Parallel Execution)
Three specialized reviewers run in parallel for maximum speed:
1. ring-default:code-reviewer (Foundation)
- Focus: Architecture, design patterns, code quality, maintainability
- Model: Opus (required for comprehensive analysis)
- Reports: Code quality issues, architectural concerns
2. ring-default:business-logic-reviewer (Correctness)
- Focus: Domain correctness, business rules, edge cases, requirements
- Model: Opus (required for deep domain understanding)
- Reports: Business logic issues, requirement gaps
3. ring-default:security-reviewer (Safety)
- Focus: Vulnerabilities, authentication, input validation, OWASP risks
- Model: Opus (required for thorough security analysis)
- Reports: Security vulnerabilities, OWASP risks
Critical: All three reviewers run simultaneously in a single message with 3 Task tool calls. Each reviewer works independently and returns its report. After all complete, aggregate findings and handle by severity.
When to Request Review
Mandatory:
- After each task in subagent-driven development
- After completing major feature
Optional but valuable:
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
Which Reviewers to Use
Use all three reviewers (parallel) when:
- Implementing new features (comprehensive check)
- Before merge to main (final validation)
- After completing major milestone
Use subset when domain doesn't apply:
- Code-reviewer only: Documentation changes, config updates
- Code + Business (skip security): Internal scripts with no external input
- Code + Security (skip business): Infrastructure/DevOps changes
Default: Use all three in parallel. Only skip reviewers when you're certain their domain doesn't apply.
Two ways to run parallel reviews:
- Direct parallel dispatch: Launch 3 Task calls in single message (explicit control)
- /ring-default:codereview command: Command that provides workflow instructions for parallel review (convenience)
How to Request
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. Dispatch all three reviewers in parallel:
CRITICAL: Use a single message with 3 Task tool calls to launch all reviewers simultaneously.
# Single message with 3 parallel Task calls:
Task tool #1 (ring-default:code-reviewer):
model: "opus"
description: "Review code quality and architecture"
prompt: |
WHAT_WAS_IMPLEMENTED: [What you built]
PLAN_OR_REQUIREMENTS: [Requirements/plan reference]
BASE_SHA: [starting commit]
HEAD_SHA: [current commit]
DESCRIPTION: [brief summary]
Task tool #2 (ring-default:business-logic-reviewer):
model: "opus"
description: "Review business logic correctness"
prompt: |
[Same parameters as above]
Task tool #3 (ring-default:security-reviewer):
model: "opus"
description: "Review security vulnerabilities"
prompt: |
[Same parameters as above]
All three reviewers execute simultaneously. Wait for all to complete.
3. Aggregate findings from all three reviews:
Collect all issues by severity across all three reviewers:
- Critical issues: [List from all 3 reviewers]
- High issues: [List from all 3 reviewers]
- Medium issues: [List from all 3 reviewers]
- Low issues: [List from all 3 reviewers]
- Cosmetic/Nitpick issues: [List from all 3 reviewers]
4. Handle by severity:
Critical/High/Medium → Fix immediately:
- Dispatch fix subagent to address all Critical/High/Medium issues
- After fixes complete, re-run all 3 reviewers in parallel
- Repeat until no Critical/High/Medium issues remain
Low issues → Add TODO comments in code:
// TODO(review): [Issue description from reviewer]
// Reported by: [reviewer-name] on [date]
// Location: file:line
Cosmetic/Nitpick → Add FIXME comments in code:
// FIXME(nitpick): [Issue description from reviewer]
// Reported by: [reviewer-name] on [date]
// Location: file:line
Push back on incorrect feedback:
- If reviewer is wrong, provide reasoning and evidence
- Request clarification for ambiguous feedback
- Security concerns require extra scrutiny before dismissing
Integration with Workflows
Subagent-Driven Development:
- Review after EACH task using parallel dispatch (all 3 reviewers at once)
- Aggregate findings across all reviewers
- Fix Critical/High/Medium, add TODO/FIXME for Low/Cosmetic
- Move to next task only after all Critical/High/Medium resolved
Executing Plans:
- Review after each batch (3 tasks) using parallel dispatch
- Handle severity-based fixes before next batch
- Track Low/Cosmetic issues in code comments
Ad-Hoc Development:
- Review before merge using parallel dispatch (all three reviewers)
- Can use single reviewer if domain-specific (e.g., docs → code-reviewer only)
Red Flags
Never:
- Dispatch reviewers sequentially (wastes time - use parallel!)
- Proceed to next task with unfixed Critical/High/Medium issues
- Skip security review for "just refactoring" (may expose vulnerabilities)
- Skip code review because "code is simple"
- Forget to add TODO/FIXME comments for Low/Cosmetic issues
- Argue with valid technical/security feedback without evidence
Always:
- Launch all 3 reviewers in a single message (3 Task calls)
- Specify
model: "opus"for each reviewer - Wait for all reviewers to complete before aggregating
- Fix Critical/High/Medium immediately
- Add TODO comments for Low issues
- Add FIXME comments for Cosmetic/Nitpick issues
- Re-run all 3 reviewers after fixing Critical/High/Medium issues
If reviewer wrong:
- Push back with technical reasoning
- Show code/tests that prove it works
- Request clarification
- Security concerns require extra scrutiny before dismissing
Re-running Reviews After Fixes
After fixing Critical/High/Medium issues:
- Re-run all 3 reviewers in parallel (same as initial review)
- Don't cherry-pick which reviewers to re-run
- Parallel execution makes full re-review fast (~3-5 minutes total)
After adding TODO/FIXME comments:
- Commit with message noting review completion and tech debt tracking
- No need to re-run reviews for comment additions