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