requesting-code-reviewlisted

# Code Review ## When to Request Review **Mandatory:** After completing a major feature; Before merging into main; After each task in parallel agent workflows. "Major feature" is not a judgment call to defer indefinitely — a pending diff spanning double-digit file counts, or bundling several otherwise-unrelated changes into one prospective commit, already meets the bar on size alone, regardless of how confident `tsc`/`eslint`/build/manual testing feel. Passing those checks is necessary, not sufficient — none of them substitute for this review. **Optional:** When stuck; Before refactoring; After fixing a complex bug. ## Requesting Review ### 1. Check for a git repository ```bash git rev-parse --is-inside-work-tree ``` If this fails (no `.git`, e.g. a scratch/test directory), skip to **1b — Degraded Review** below. Otherwise continue to **2 — Dispatch via Dylan Dog**. ### 1b. No Git Repository: Snapshot Review Dylan Dog's triage stage needs a diff to size and partition — without one there's nothing to triage, so **skip triage**. That doesn't mean giving up on a fresh, dedicated reviewer: dispatch `dylan-dog-hunter` directly, in **snapshot mode** — no {BASE_SHA}/{HEAD_SHA}, just the current contents of every file created or modified in this session (you already know this list from your own tool calls — don't guess). A dedicated subagent reviewing fresh, without the bias of having written the code itself, beats self-review even without a diff to work from. 1. List every file