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).