coder/xum/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: 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:

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:

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