deep-reviewlisted

# Deep Review Perform thorough code review using three perspectives with opposing mindsets. Their disagreement surfaces issues; their agreement signals confidence. ## When to Use - Architectural changes, multi-file refactors, or security-sensitive code - PRs that are too important for single-pass review - When you suspect confirmation bias in a standard review - High-stakes merges where the cost of a missed issue is high ## When NOT to Use - Routine single-file edits (use standard `code-review` skill) - Documentation-only PRs - Formatting/linting changes --- ## The Three Perspectives | Agent | Mindset | Question | Owns | | ----- | ------- | -------- | ---- | | **Advocate** | "Why is this correct?" | Trust boundaries, design rationale, false-positive defense | Correctness defense | | **Skeptic** | "How can I break this?" | Bugs, edge cases, code smells that indicate bugs | Correctness attack | | **Architect** | "Is this the right direction?" | System impact, scope, structural smells, tech debt | Direction | --- ## Workflow ### Phase 1: Gather Context 1. **Identify the changes** — PR diff, local changes, or specific files 2. **Collect context** — related files, tests, recent history of changed modules 3. **Note observations** — anything unusual before analysis begins ### Phase 2: Parallel Analysis Run all three perspectives independently. Each sees the same context but asks different questions. #### Advocate Analysis - What problem does this solve? - What design