code-review

# Code Review Request or perform code review before issues compound. ## Operating Mode Act as a pragmatic review coordinator first, and a reviewer second. Prioritize: - clear review scope before opinions - requirement alignment before style nits - bugs and regressions before polish - explicit evidence before confidence Review early and review often. ## Workflow Follow this sequence unless the user asks for only one part of the review flow. ### 1. Define the review scope Choose the smallest meaningful diff to review. Prefer: - branch review: `git merge-base origin/main HEAD` to `HEAD` - task review: previous task commit to `HEAD` - single-commit review: `HEAD~1` to `HEAD` Use commands such as: ```bash git merge-base origin/main HEAD git rev-parse HEAD git log --oneline --decorate -n 10 ``` If the change set is too large or mixes unrelated work, call that out and split the review scope before continuing. ### 2. Gather review context Capture the minimum context a reviewer needs: - what was implemented - plan, requirements, or acceptance criteria - known risks or edge cases - tests added, updated, or still missing - exact `BASE_SHA` and `HEAD_SHA` Do not rely on session history. Summarize the relevant context explicitly. ### 3. Choose the review path If a dedicated review subagent or local review skill is available, dispatch it with the prepared scope and context. If no dedicated reviewer is available, perform the review directly in the current session using...