Deep Review Mode
Provide an excellent code review by defaulting to parallelism.
You should use sub-agents to review the change from multiple angles (correctness, tests, consistency, UX, performance, safety). Each sub-agent should have a focused mandate and return actionable findings with file paths.
Step 0: Establish the review surface
Before reviewing, gather context:
- Identify the change scope:
git diff --name-only (or the file list the user provides).
- Skim the diff for intent and risk:
git diff.
- Note which layers are touched:
- UI (React/components/styles)
- Main process / backend services
- IPC boundary / shared types
- Tooling/scripts
- Docs
- Tests
If the change is large, split review by module and prioritize high-risk paths.
Spawn the right sub-agents (change-type aware)
Spawn 2–5 sub-agents depending on scope. Tailor them to the change.
Suggested sub-agent set
- Correctness & edge cases (always)
- Goal: find logic bugs, missing error handling, race conditions, broken invariants.
- Tests & verification (always)
- Goal: evaluate test coverage, propose missing tests, suggest commands to validate.
- Consistency & architecture (usually)
- Goal: ensure changes match existing patterns, abstractions, and boundaries.
- UX & accessibility (when UI changed)
- Goal: keyboard flows, a11y, visual consistency, empty/loading/error states.
- Performance & reliability (when hot paths / streaming / IO changed)
- Goal: latency, unnecessary work, blocking calls, memory growth, resilience.
- Docs & developer experience (when docs/scripts/public API changed)
- Goal: clarity, correctness, navigation updates, link integrity.
Synthesize into a single excellent review
When sub-agent results arrive, produce a consolidated review with:
- Summary (what changed + overall risk)
- Issues
- Questions (unknown intent; ask for clarification)
- Suggested validation plan (commands + manual checks)
Issues should have a severity in form of:
| Severity |
Description |
Example |
| P0 |
Change must not be merged until resolved |
Change would permanently break core workflows if merged. |
| P1 |
Change should not be merged |
New code will not work as expected due to severe bugs |
| P2 |
Consideration required before merging |
The change creates inconsistency / fragility |
| P3 |
Minor issue |
The change introduces a minor issue that may be addressed later |
| P4 |
Long-term issue |
The change raises concerns about long-term maintainability or may break under rare conditions |
Review rubric
Use this rubric to avoid blind spots:
- Correctness: invariants, edge cases, error handling, races
- Fitness: does it meet the user goal, and does it match product constraints?
- Tests: coverage of new logic, regression tests, deterministic behavior
- Consistency: patterns, naming, types, boundaries, IPC typing
- Maintainability: complexity, duplication, readability
- Performance: hot paths, streaming, excessive re-renders/IO
- Safety: secrets, path traversal, injection risks, filesystem safety
- DX: logs, error messages, debuggability
Anti-patterns
- Single-threaded review of a large change (spawn sub-agents).
- Vague feedback (“looks good”) without actionable items and file paths.
- Non-verifiable suggestions (always include a validation plan).
- Scope creep disguised as review (focus on minimal changes unless risk demands more).
1---2name: deep-review-23description: Sub-agent powered code reviews spanning correctness, tests, consistency, and fit4---56# Deep Review Mode78Provide an **excellent code review** by defaulting to **parallelism**.910You should use sub-agents to review the change from multiple angles (correctness, tests, consistency, UX, performance, safety). Each sub-agent should have a focused mandate and return actionable findings with file paths.1112## Step 0: Establish the review surface1314Before reviewing, gather context:1516- Identify the change scope: `git diff --name-only` (or the file list the user provides).17- Skim the diff for intent and risk: `git diff`.18- Note which layers are touched:19 - UI (React/components/styles)20 - Main process / backend services21 - IPC boundary / shared types22 - Tooling/scripts23 - Docs24 - Tests2526If the change is large, split review by module and prioritize **high-risk** paths.2728## Spawn the right sub-agents (change-type aware)2930Spawn **2–5** sub-agents depending on scope. Tailor them to the change.3132### Suggested sub-agent set3334- **Correctness & edge cases** (always)35 - Goal: find logic bugs, missing error handling, race conditions, broken invariants.36- **Tests & verification** (always)37 - Goal: evaluate test coverage, propose missing tests, suggest commands to validate.38- **Consistency & architecture** (usually)39 - Goal: ensure changes match existing patterns, abstractions, and boundaries.40- **UX & accessibility** (when UI changed)41 - Goal: keyboard flows, a11y, visual consistency, empty/loading/error states.42- **Performance & reliability** (when hot paths / streaming / IO changed)43 - Goal: latency, unnecessary work, blocking calls, memory growth, resilience.44- **Docs & developer experience** (when docs/scripts/public API changed)45 - Goal: clarity, correctness, navigation updates, link integrity.4647## Synthesize into a single excellent review4849When sub-agent results arrive, produce a consolidated review with:50511. **Summary** (what changed + overall risk)522. **Issues**533. **Questions** (unknown intent; ask for clarification)544. **Suggested validation plan** (commands + manual checks)5556Issues should have a severity in form of:5758| Severity | Description | Example |59| -------- | ---------------------------------------- | --------------------------------------------------------------------------------------------- |60| P0 | Change must not be merged until resolved | Change would permanently break core workflows if merged. |61| P1 | Change should not be merged | New code will not work as expected due to severe bugs |62| P2 | Consideration required before merging | The change creates inconsistency / fragility |63| P3 | Minor issue | The change introduces a minor issue that may be addressed later |64| P4 | Long-term issue | The change raises concerns about long-term maintainability or may break under rare conditions |6566### Review rubric6768Use this rubric to avoid blind spots:6970- **Correctness**: invariants, edge cases, error handling, races71- **Fitness**: does it meet the user goal, and does it match product constraints?72- **Tests**: coverage of new logic, regression tests, deterministic behavior73- **Consistency**: patterns, naming, types, boundaries, IPC typing74- **Maintainability**: complexity, duplication, readability75- **Performance**: hot paths, streaming, excessive re-renders/IO76- **Safety**: secrets, path traversal, injection risks, filesystem safety77- **DX**: logs, error messages, debuggability7879## Anti-patterns8081- **Single-threaded review** of a large change (spawn sub-agents).82- **Vague feedback** (“looks good”) without actionable items and file paths.83- **Non-verifiable suggestions** (always include a validation plan).84- **Scope creep** disguised as review (focus on minimal changes unless risk demands more).
