Use consensus review sparingly for high-risk changes such as auth, billing, database schema, tenant isolation, production deployment, or large cross-domain refactors.
When to Use
Auth or billing logic changes
Database schema migrations affecting production data
Multi-perspective review can be expensive under AI Credit billing. Prefer a single reviewer for normal PRs. Use consensus review only when the risk justifies the cost.
Review Perspectives
Each pass focuses on one concern:
Pass
Focus
Key Questions
Architecture
Structure, boundaries, coupling
Does this change respect module boundaries? Will it cause cascading changes?
Security
Auth, secrets, injection, OWASP
Are role checks preserved? Is user input validated?
Performance
Queries, caching, bundle size
Are there N+1 queries? Does this affect page load?
UX
User flow, error states, accessibility
Does the happy path work? Are error states handled?
How to Invoke
Review this PR from four perspectives: architecture, security, performance, and UX.
For each perspective, list findings with severity (critical/high/medium/low),
the affected file, and a specific recommendation. Dismiss style-only findings.
Output
Each reviewer should provide concrete findings with:
Severity: critical / high / medium / low
Evidence: specific code reference or line
Affected file: path to the file
Recommendation: specific fix, not vague advice
Dismiss style-only or subjective findings that do not affect correctness, security, or performance.
Raw content
Copy this into your project — e.g. .instructions.md, .agent.md, or SKILL.md
## Overview
Use consensus review sparingly for high-risk changes such as auth, billing, database schema, tenant isolation, production deployment, or large cross-domain refactors.
## When to Use
- Auth or billing logic changes
- Database schema migrations affecting production data
- Tenant isolation boundary changes
- Large refactors spanning 5+ files across domains
- Security-sensitive changes (CORS, CSP, secrets handling)
## Cost Warning
Multi-perspective review can be expensive under AI Credit billing. Prefer a single reviewer for normal PRs. Use consensus review only when the risk justifies the cost.
## Review Perspectives
Each pass focuses on one concern:
| Pass | Focus | Key Questions |
|------|-------|---------------|
| **Architecture** | Structure, boundaries, coupling | Does this change respect module boundaries? Will it cause cascading changes? |
| **Security** | Auth, secrets, injection, OWASP | Are role checks preserved? Is user input validated? |
| **Performance** | Queries, caching, bundle size | Are there N+1 queries? Does this affect page load? |
| **UX** | User flow, error states, accessibility | Does the happy path work? Are error states handled? |
## How to Invoke
```markdown
Review this PR from four perspectives: architecture, security, performance, and UX.
For each perspective, list findings with severity (critical/high/medium/low),
the affected file, and a specific recommendation. Dismiss style-only findings.
```
## Output
Each reviewer should provide concrete findings with:
- **Severity**: critical / high / medium / low
- **Evidence**: specific code reference or line
- **Affected file**: path to the file
- **Recommendation**: specific fix, not vague advice
Dismiss style-only or subjective findings that do not affect correctness, security, or performance.