# Repo Review > Use when a local worktree/index or immutable snapshot, range, pull request, release candidate, or verified package needs read-only review; own local commit-readiness and exact staging guidance or immutable severity-ranked findings. - **Type:** Skill - **Install:** `agentstack add skill-idaibin-skills-repo-review` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [idaibin](https://agentstack.voostack.com/s/idaibin) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [idaibin](https://github.com/idaibin) - **Source:** https://github.com/idaibin/skills/tree/main/skills/repo-review - **Website:** https://skills.sh/idaibin/skills ## Install ```sh agentstack add skill-idaibin-skills-repo-review ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Repository Review ## Overview Review repository changes without modifying files, Git, GitHub, or remote state. Select the review basis first, then apply the matching mode. Worktree mode owns dirty-tree classification and commit-readiness guidance; immutable modes own fixed-SHA P0-P3 review. All modes share contract tracing, structural completeness, specialist coordination, evidence quality, and read-only authority. ## Review Basis Select exactly one basis before conclusions: - **Worktree/index:** current tracked, untracked, staged, and unstaged state. - **Repository snapshot:** one tag, branch resolved to SHA, or commit. - **Commit range:** explicit immutable `base..head` SHAs. - **Pull request:** metadata plus complete changed-file evidence and resolved base/head SHAs. - **Release candidate:** immutable candidate revision plus release/config/CI evidence. - **Review package:** verified manifest, hashes, coverage, exclusions, and final marker. Do not mix evidence between bases. Current-worktree content is contamination when reviewing another SHA unless explicitly included in the basis. ## Workflow 1. Read effective repository guidance and record the requested review object, scope, output, and non-goals. 2. Fix the basis before conclusions: - for Worktree, run status, diff stat/name-status, and cached equivalents when staged content exists; - for immutable modes, resolve full SHAs or verify the package manifest and hashes. 3. Build the smallest complete read set from changed or explicitly owned paths. A `repo-map` artifact may guide navigation but is never review proof. 4. In Worktree mode, classify every changed file as `task-owned`, `related-existing`, `unrelated-existing`, `mixed-hunk`, or `unknown` before proposing commit groups. 5. Trace relevant interfaces through registrations, callers, types, data shaping, persistence, generated artifacts, runtime config, tests, docs, CI/deploy, and stale references. 6. Evaluate two independent axes: - **Standards:** repository guidance, architecture, correctness, security, performance, maintainability, and applicable domain conventions. - **Spec:** originating requirements, decisions, acceptance criteria, missing behavior, wrong behavior, and unrequested scope. If no trustworthy spec exists, mark Spec `Not verified`; do not infer one from the diff. 7. Keep the two evidence passes independent. They may run in parallel only when delegation is available, both scopes are read-only and fixed, and the coordinator can verify and integrate their results. 8. Select only applicable frontend, Rust, security, validation, and release profiles. Delegate bounded evidence to `audit-frontend`, `audit-rust`, or `audit-security`; retain scope, integration, deduplication, severity, and final report ownership. 9. Resolve documented path mismatches at the selected basis. If a path or parent is absent, ascend to the nearest existing ancestor and search only the relevant subtree; route repo-map edits to `repo-map`. 10. Reject speculative, unreachable, style-only, duplicate, or already-resolved findings. Consolidate both axes into P0-P3 findings from concrete impact and urgency while retaining each finding's axis. 11. Run only non-mutating repository checks needed for the selected basis and risk. 12. In Worktree mode, produce semantic commit groups and exact path- or hunk-level staging guidance for `repo-delivery`. In immutable modes, report merge/release implications without staging guidance. 13. Report exclusions, residual risks, failed checks, and every `Not found` or `Not verified` gap. ## Modes - **Worktree review:** dirty-tree ownership, mixed hunks, contract completeness, commit readiness, semantic groups, exact staging guidance, and commit messages. - **Snapshot review:** bounded review of one fixed repository revision. - **Range review:** `base..head` regressions, contracts, tests, docs, and structural lifecycle. - **Pull-request review:** complete PR evidence without posting comments unless separately authorized. - **Release review:** compatibility, migrations, generated artifacts, packaging, CI, deployment, rollback, and security-sensitive configuration. - **Review-package assessment:** package integrity and evidence coverage before findings. ## Do Not Use For - Repository mapping or repo-map maintenance; use `repo-map`. - Future implementation planning; use the host's built-in planning. - Business-domain modeling without a change basis; use `domain-modeling`. - Root-cause diagnosis of a concrete failure; use the host's built-in diagnosis under effective instructions. - A bounded security-only audit when the target surface is already known; use `audit-security`. - Implementing accepted fixes; use the matching `implement-*` skill. - Staging, commits, pushes, squash, cleanup, or other Git mutation; use `repo-delivery` after explicit authorization. - External ChatGPT sending or browser/client operation; use the matching operations skill. ## Hard Rules - Keep every review read-only. Do not edit, format, stage, unstage, commit, push, change refs, post comments, or create issues/PRs. - State the review basis and resolved SHAs before immutable conclusions; state complete status/index evidence before Worktree conclusions. - Never use current-worktree files to clear a finding at another SHA. - Inventory the full dirty tree even when Worktree scope is narrower, then preserve unrelated changes. - Mark mixed files `mixed-hunk`; never recommend whole-file staging unless every hunk belongs to the group. - Do not recommend `git add .`, `git add -A`, directory-wide adds, or broad wildcards unless explicitly approved. - Do not claim whole-repository, PR, release, or package coverage from partial evidence. - Do not report findings without reachable evidence and concrete impact. - Do not approve structural add/reuse/move/rename/delete work while manifests, exports, commands, tests, CI/deploy, docs, indexes, migrations, generated files, consumers, or stale references disagree. - Treat runtime, CI, deployment, external services, branch policy, and package completeness as `Not verified` unless directly evidenced. ## Output Contract Lead with mode, basis, scope, exclusions, and validation, then severity-ranked P0-P3 findings labeled `Standards`, `Spec`, or both. Every finding includes exact location, cited standard or requirement when available, evidence, impact, remediation, and verification. Include a concise Standards verdict and Spec Compliance verdict; mark missing specification evidence `Not verified`. For Worktree mode, also report ownership labels, staged-state risks, semantic commit groups, exact staging approach, validation status, and concise commit messages. For immutable modes, include resolved SHAs, cross-domain integration, merge/release implications, and `No actionable findings` for empty requested groups. Finish with final verdict, residual risk, and all `Not found` or `Not verified` items. ## References - See [references/usage.md](references/usage.md) for routing and mode examples. - See [references/worktree-checklist.md](references/worktree-checklist.md) for dirty-tree ownership and commit-readiness review. - See [references/checklist.md](references/checklist.md) for immutable basis, severity, and release review. - See [references/standards-and-spec.md](references/standards-and-spec.md) for independent Standards and Spec review axes. - See [references/worktree-examples.md](references/worktree-examples.md) for commit grouping examples. - See [references/eval-cases.md](references/eval-cases.md) for trigger, boundary, scenario, and quality evals. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [idaibin](https://github.com/idaibin) - **Source:** [idaibin/skills](https://github.com/idaibin/skills) - **License:** Apache-2.0 - **Homepage:** https://skills.sh/idaibin/skills Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-idaibin-skills-repo-review - Seller: https://agentstack.voostack.com/s/idaibin - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.