| name | managing-reviewboard |
| description | Use when working with Reviewboard — review Board code review management
including review requests, diff management, review groups, and repository
configuration. Use when managing Review Board review workflows, configuring
review groups, and automating review request assignment.
|
| connection_type | reviewboard |
| preload | false |
Managing Review Board
Overview
Manage Review Board review workflows, including review request creation, diff management, reviewer group configuration, and review completion policies.
Key Capabilities
- Create and manage review requests with multi-revision diffs
- Configure review groups and default reviewer assignment
- Manage repository integrations and diff processing
- Set up review completion requirements
- Configure extensions for custom workflow automation
- Track review request status and turnaround metrics
Workflow
1 — Review Group Configuration
REVIEW GROUPS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Groups:
Name | Members | Default for Repository
────────────────────┼──────────────────┼───────────────────────
backend-review | @backend-devs | backend-service
frontend-review | @frontend-devs | web-app
security-review | @security-team | (all repositories)
platform-review | @platform-team | infrastructure
[ ] Mailing list per group: YES / NO
[ ] Visible to: everyone / members only
[ ] Invite-only: YES / NO
2 — Default Reviewers
DEFAULT REVIEWERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Repository-level defaults:
Repository: backend-service
Default people: @tech-lead
Default groups: backend-review
[ ] File pattern defaults:
Pattern: /security/**
Reviewer: security-review group
Pattern: /api/**
Reviewer: @api-owner
3 — Review Completion Policy
REVIEW COMPLETION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Ship It required from: ___ reviewers
[ ] All reviewers must respond: YES / NO
[ ] Ship It from group member counts for group: YES / NO
[ ] Allow submitter to close without Ship It: YES / NO
[ ] Require all open issues to be resolved: YES / NO
Common Operations
List Pending Reviews
Query open review requests awaiting action, filter by group or assignee.
Diff Comparison
Compare diff revisions within a review request to track changes between iterations.
Review Metrics
Track Ship It rates, review turnaround time, and reviewer participation.
Troubleshooting
| Issue | Cause | Fix |
|---|
| Default reviewer not added | Pattern mismatch | Verify file path patterns in default reviewer config |
| Diff upload fails | Repository not configured | Add repository with correct SCM tool and path |
| Email notifications missing | SMTP not configured | Check Review Board email settings |
| Review request stuck | Missing Ship It | Contact assigned reviewers or reassign |
Output Format
Present results as a structured report:
Managing Reviewboard Report
═══════════════════════════
Resources discovered: [count]
Resource Status Key Metric Issues
──────────────────────────────────────────────
[name] [ok/warn] [value] [findings]
Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]
Target ≤50 lines of output. Use tables for multi-resource comparisons.
Anti-Hallucination Rules
- NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
- NEVER fabricate metric names or dimensions — verify against the service documentation or
--help output.
- NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
- ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
- ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "I'll skip discovery and check known resources" | Always run Phase 1 discovery first | Resource names change, new resources appear — assumed names cause errors |
| "The user only asked for a quick check" | Follow the full discovery → analysis flow | Quick checks miss critical issues; structured analysis catches silent failures |
| "Default configuration is probably fine" | Audit configuration explicitly | Defaults often leave logging, security, and optimization features disabled |
| "Metrics aren't needed for this" | Always check relevant metrics when available | API/CLI responses show current state; metrics reveal trends and intermittent issues |
| "I don't have access to that" | Try the command and report the actual error | Assumed permission failures prevent useful investigation; actual errors are informative |
