review

# Review The reviewer must be a fresh subagent that did not implement the change. Do not edit files or post comments. ## Scope Review the implementation target named by the user. It may be a file, diff, branch, commit, pull request, or other code change on GitHub. Use `/architecture-review` for a technical proposal that has not been implemented. If the user does not name a target, review the current repository's complete local change set: commits on the current branch relative to the repository's default branch, staged changes, unstaged changes, and untracked files. Use the repository and immediate surrounding code as context. If there are no local changes, say so instead of substituting a whole-repository audit. ## Standard Approve only when: - The change matches its source and behaves as required. - No known defect or unhandled risk could break the source or repository rules for security, data loss, compatibility, or operations. - No simpler design has been identified that delivers the same outcome and proof with less state, indirection, duplication, or operational work. Do not demand perfection or block on personal taste. Cite technical evidence or repository conventions. The verdict is independent agent evidence. It is not GitHub approval or a replacement for human review. ## Review order 1. **Set the frame.** Give the reviewer the task, acceptance criteria, repository rules, complete diff or pull request, and test evidence. Name the user or developer affected ...