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.
2. Confirm the requested scope and any explicitly authorized live systems. Treat credentials, clusters, cloud projects, deployments, and releases outside that scope as unavailable.
3. Record the starting branch, HEAD, upstream, and git status --short. Distinguish staged, unstaged, and untracked paths; every pre-existing change is user-owned.
4. 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.
2. 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 only when temporary local file and Git-metadata changes are authorized, or run equivalent non-mutating checks; never reformat unrelated work. If the caller forbids even temporary state, skip that gate and report it as not checked. Verify the original index and worktree snapshot after cleanup.
3. Map the system: Inspect manifests, entry points, package boundaries, task definitions, hooks, workflows, deployment/release automation, user and agent documentation, generated files, and relevant runtime configuration. Read the review matrix for coverage and evidence expectations.
4. Route native checks: Use the repository's pinned mise run tasks and the applicable language stack skills. Use focused subtasks (mise run check, targeted check:*/test) only for iteration; use mise run all for the complete local candidate when safe and proportionate. Invoke the security-scan skill only when the request calls for a full security boundary beyond native checks.
5. Inspect live evidence read-only: Compare the exact HEAD SHA with CI checks, deployments, tags, releases, or runtime observations only when those systems are authorized and reachable. A historical or different-head green result is stale evidence.
6. Challenge each conclusion: Reproduce high-impact claims when safe, prefer repository or dependency source over assumptions, and separate an observed defect from a speculative risk.
7. Report, do not repair: Return ranked findings and ordered actions in the response. Never create an unsolicited report file or backlog item; compose with a backlog skill only when the user explicitly requests that mutation.