Code Reviewer
Run a structured agent-led review on local staged/unstaged diffs or a remote GitHub PR before merge, with optional preflight checks.
Overview
code-reviewer is an agent skill most often used in Ship (also Build) that reviews local git changes or remote PRs for correctness, maintainability, and project standards.
Install
npx skills add https://github.com/google-gemini/gemini-cli --skill code-reviewerWhat is this skill?
- Dual mode: remote PR by number/URL via gh pr checkout, or local git status and staged/unstaged diffs
- Preparation step runs npm run preflight on PRs to surface automated failures before human-style analysis
- In-depth analysis on correctness, maintainability, and project standards after context from PR description and comments
- Local review path optionally escalates to preflight when changes are substantial
- Three-phase workflow: determine review target, preparation, in-depth analysis
- Documented 3-step workflow: determine target, preparation, in-depth analysis
Adoption & trust: 7.1k installs on skills.sh; 105k GitHub stars; 1/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have unreviewed local diffs or an open PR and need a repeatable agent workflow that loads context, runs checks, and critiques the change set.
Who is it for?
Solo builders and tiny teams using GitHub PRs or local branches who want gh checkout, preflight, and structured analysis in one skill.
Skip if: Repos without git, teams that forbid shell/gh access in agents, or work that needs dedicated SAST penetration testing instead of code review.
When should I use this skill?
Use this skill to review code for local staged or working tree changes or remote Pull Requests by ID or URL.
What do I get? / Deliverables
You get a standards-focused review after target selection and optional preflight, ready to address before merge or further implementation.
- Structured review commentary on correctness and maintainability
- Context summary from PR description and existing comments
- Findings tied to project standards after optional preflight output
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Formal review gates quality before release, so Ship/review is the canonical shelf even when used mid-sprint. The workflow is explicitly code review—target selection, diff context, standards analysis—not security scanning alone or launch marketing.
Where it fits
Review a large feature branch diff for API correctness before opening a PR.
Checkout PR by URL, run npm run preflight, then analyze changes against project standards.
After preflight failures, triage whether issues are test regressions or logic bugs in the patch.
Re-review a hotfix branch locally with git diff before emergency deploy.
How it compares
Procedural PR and diff review ritual—not a linter MCP substitute or brainstorming/planning skill.
Common Questions / FAQ
Who is code-reviewer for?
code-reviewer is for developers using Gemini CLI or other agents who merge via GitHub PRs or frequent local commits and want guided review steps.
When should I use code-reviewer?
Use it in Ship before merging a PR or shipping a release candidate; also during Build when reviewing substantial staged changes or when asked to review PR #N or your local diff.
Is code-reviewer safe to install?
The skill instructs git, gh, and npm preflight execution—grant only the permissions you trust; review the Security Audits panel on this Prism page and sandbox agent shell access accordingly.
SKILL.md
READMESKILL.md - Code Reviewer
# Code Reviewer This skill guides the agent in conducting professional and thorough code reviews for both local development and remote Pull Requests. ## Workflow ### 1. Determine Review Target * **Remote PR**: If the user provides a PR number or URL (e.g., "Review PR #123"), target that remote PR. * **Local Changes**: If no specific PR is mentioned, or if the user asks to "review my changes", target the current local file system states (staged and unstaged changes). ### 2. Preparation #### For Remote PRs: 1. **Checkout**: Use the GitHub CLI to checkout the PR. ```bash gh pr checkout <PR_NUMBER> ``` 2. **Preflight**: Execute the project's standard verification suite to catch automated failures early. ```bash npm run preflight ``` 3. **Context**: Read the PR description and any existing comments to understand the goal and history. #### For Local Changes: 1. **Identify Changes**: * Check status: `git status` * Read diffs: `git diff` (working tree) and/or `git diff --staged` (staged). 2. **Preflight (Optional)**: If the changes are substantial, ask the user if they want to run `npm run preflight` before reviewing. ### 3. In-Depth Analysis Analyze the code changes based on the following pillars: * **Correctness**: Does the code achieve its stated purpose without bugs or logical errors? * **Maintainability**: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns. * **Readability**: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines? * **Efficiency**: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes? * **Security**: Are there any potential security vulnerabilities or insecure coding practices? * **Edge Cases and Error Handling**: Does the code appropriately handle edge cases and potential errors? * **Testability**: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness. ### 4. Provide Feedback #### Structure * **Summary**: A high-level overview of the review. * **Findings**: * **Critical**: Bugs, security issues, or breaking changes. * **Improvements**: Suggestions for better code quality or performance. * **Nitpicks**: Formatting or minor style issues (optional). * **Conclusion**: Clear recommendation (Approved / Request Changes). #### Tone * Be constructive, professional, and friendly. * Explain *why* a change is requested. * For approvals, acknowledge the specific value of the contribution. ### 5. Cleanup (Remote PRs only) * After the review, ask the user if they want to switch back to the default branch (e.g., `main` or `master`).