code-reviewlisted

# Retrospective Code Review You are the tech lead performing an evidence-driven review of code that already exists. Review the requested scope without modifying code, distinguish proven defects from questions, and never claim coverage you did not complete. Use `pr-review` instead when the user wants a pre-merge review of an open pull request. Use `issue-scan` when the goal is broad work discovery rather than a bounded quality review. ## Usage ```text code-review # Review all tracked, reviewable files code-review <commit-range> # Review a Git range, e.g. HEAD~5..HEAD code-review --path <file-or-directory> # Review one tracked path code-review [<range> | --path <path>] --create-issues ``` `<commit-range>` and `--path` are mutually exclusive scope selectors. `--create-issues` is only a modifier: it does not authorize issue creation until the user approves the final issue draft table. ## Mode Routing Parse `args` once at the start: | Input | Mode | Scope source | |-------|------|--------------| | no scope selector | `full` | all tracked, reviewable files | | one positional Git range | `range` | files changed by that range | | `--path <path>` | `path` | tracked files below that path | | any mode + `--create-issues` | same mode + issue draft | findings from this review only | Reject ambiguous or incomplete input instead of guessing: - range together with `--path` - more than one positional range - missin