local-code-reviewlisted

Reviews local, not-yet-PR'd Git changes (committed delta, staged, unstaged, and untracked) and returns evidence-backed P0/P1/P2 findings. Read-only and opt-in only: never edits, commits, pushes, or touches GitHub, and every review or re-review requires explicit user selection. Optionally accepts free-form context such as requirements, Jira/HLD/ADR, acceptance criteria, or implementation plans to focus the review, plus an associated GitHub PR reference for reconciling prior findings and architectural decisions. The local delta always remains the review scope. For reviewing an existing PR itself, use github-pr-review.
amirbena/code-review-skill · ★ 2 · Code & Development · score 68

Install: claude install-skill amirbena/code-review-skill

# SKILL.md — local-code-review A small, bounded, **stateless** Code Review Skill that reviews a local Git repository's implementation state (committed delta, staged, unstaged, and untracked) and returns structured P0/P1/P2 findings. It is a reviewer only — never an orchestrator, a fix loop, a Git-mutating agent, or a GitHub-publishing agent. **Use it** on local/uncommitted work before a push or PR. For an existing GitHub Pull Request, use the sibling `github-pr-review` Skill. **Compatibility:** requires a local Git repository; an optional PR reference additionally requires read-only GitHub access. ## Safety boundaries (read before invoking) The entry contract. Full text lives in the linked canonical policies; restated here because hiding them behind a link would be dangerous. - **Opt-in only.** This Skill **MUST NOT be invoked automatically.** Every invocation — first review *and* every re-review after fixes — requires fresh, explicit user approval scoped to that one run, obtained by the caller. Generic "check your work" language, a standing preference, repository or orchestration policy, and silence/non-objection never qualify. Returning findings from one invocation is never, by itself, authorization for the caller to invoke this Skill again after fixes. A separate, explicit approval is required for every subsequent invocation. Delegating as an Agent/Sub-Agent never moves the decision away from the end user. Canonical owner: [`policies/invocation-ap