repository-review

# Repository Review Review the whole delivery system, preserve user work, and report only what the available evidence proves. A review-only request authorizes inspection and bounded validation, not fixes, issue creation, comments, deployment, publication, or runtime mutation. ## Authority and proof ceiling 1. Read the repository instructions and the stack, CI, security, or documentation skills needed by the requested dimensions. The full security-scan skill is not mandatory for a bounded review that excludes the security boundary. 1. Confirm the requested scope and any explicitly authorized live systems. Treat credentials, clusters, cloud projects, deployments, and releases outside that scope as unavailable. 1. Record the starting branch, `HEAD`, upstream, and `git status --short`. Distinguish staged, unstaged, and untracked paths; every pre-existing change is user-owned. 1. Never stash, reset, clean, reformat, stage, commit, push, comment, open issues, or otherwise mutate user or external state during a review. ## Review workflow 1. **Establish the candidate**: Decide whether the evidence concerns committed `HEAD`, the dirty working candidate, or both. Name that boundary in the report. 1. **Preserve the worktree**: Use read-only diffs first. Before any full gate, inspect the full gate's task definition and working-tree state. If it runs whole-tree write-formatters and unrelated or user changes are present, validate the exact candidate in an isolated temporary worktree o...