Deep Review

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 using an explicit revision range (or the file list the user provides), for example BASE="$(git merge-base origin/main HEAD)" then git diff --name-only "${BASE}...HEAD".
• Skim the diff for intent and risk over the same range, for example git diff "${BASE}...HEAD".
• 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:

1. Summary (what changed + overall risk)
2. Issues
3. Questions (unknown intent; ask for clarification)
4. 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).