requesting-code-reviewlisted

# Requesting Code Review Dispatch a Hermes reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context and file paths, not your session history. This keeps the reviewer focused on the work product and preserves the controller context. **Core principle:** Review early, review often, and pass artifacts as files. ## When to Request Review **Mandatory:** - After each task in `subagent-driven-development`. - After completing a major feature. - Before merging or opening a PR/MR. **Hard gate before PR/MR creation:** after implementation is complete and before you create the PR/MR, you must dispatch at least one Hermes reviewer subagent using this skill. Do not substitute self-review, local tests, or a diff skim for this gate. If the reviewer reports Critical or Important issues, fix them and run another reviewer subagent pass before opening the PR/MR. Repeat until no Critical or Important issues remain, or until you stop and report a blocker. **Optional but valuable:** - When stuck and a fresh perspective may help. - Before a risky refactor. - After fixing a complex bug. ## Hermes Review Procedure 1. **Determine the review range:** ```bash BASE_SHA=$(git merge-base origin/main HEAD 2>/dev/null || git rev-parse HEAD~1) HEAD_SHA=$(git rev-parse HEAD) ``` For per-task reviews, use the exact `BASE_SHA` recorded before that task's implementer ran — never assume `HEAD~1` if the task may have multiple commits. 2. **Generate a review package