Code Review Expert
Run a senior-style review on your current git diff before merge, with SOLID, architecture, dead-code, and security findings graded P0–P3.
Overview
Code Review Expert is an agent skill most often used in Ship (also Build) that performs structured senior-engineer review of current git changes with SOLID, architecture, removal candidates, and security risks graded P0–
Install
npx skills add https://github.com/sanyuan0704/sanyuan-skills --skill code-review-expertWhat is this skill?
- Preflight scopes changes via git status, diff --stat, and full git diff with optional ripgrep for contracts
- Findings use four severity levels P0–P3 with explicit merge-blocking rules for Critical and High
- Focus areas include SOLID violations, architecture boundaries, removal candidates, and security on auth/payments/data pa
- Handles empty diffs, staged-only review, and large diffs over 500 lines via file summary then module batches
- Defaults to review-only output unless the user explicitly asks to implement fixes
- 4 severity levels (P0–P3) with defined merge actions
- Large-diff workflow triggers when patch exceeds 500 lines
Adoption & trust: 2.7k installs on skills.sh; 3.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a pile of local git changes but no consistent way to catch security, correctness, and design issues before merge.
Who is it for?
Solo builders about to open or merge a PR who want SOLID, architecture, and security pass on the exact diff they have checked out.
Skip if: Greenfield generation with no git changes, or when you want the agent to silently rewrite code without a review-first pass.
When should I use this skill?
User wants expert review of current git changes with SOLID, security, and actionable improvements; output stays review-only unless implementation is requested.
What do I get? / Deliverables
You get a severity-ranked review mapped to merge decisions, with optional follow-up only if you explicitly request implementation.
- Structured review with P0–P3 severities
- Architecture and removal candidates
- Security-focused notes on critical paths
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the workflow centers on pre-merge git review and merge-blocking severity—where solo builders gate quality before release. Review subphase matches structured diff analysis, severity tables, and review-only default output rather than implementation.
Where it fits
After implementing an API change on a feature branch, run review on the diff before opening the PR.
Grade findings P0–P3 and decide what must block merge on payment-path edits.
Stress-test auth and data-write paths called out in the changed files.
Review a hotfix branch locally before fast-tracking deploy.
How it compares
Structured git-diff review with P0–P3 gates—not a generic ‘make this prettier’ linter pass.
Common Questions / FAQ
Who is code-review-expert for?
Indie and solo developers using agent-assisted coding who rely on git and want pre-merge quality checks aligned to senior review habits.
When should I use code-review-expert?
Use it in Ship before merging; also during Build when iterating on a feature branch; run it after finishing a slice of work when git diff --stat shows meaningful changes.
Is code-review-expert safe to install?
It expects read access to your repo via git and search tools—review the Security Audits panel on this page before enabling in sensitive codebases.
SKILL.md
READMESKILL.md - Code Review Expert
# Code Review Expert ## Overview Perform a structured review of the current git changes with focus on SOLID, architecture, removal candidates, and security risks. Default to review-only output unless the user asks to implement changes. ## Severity Levels | Level | Name | Description | Action | |-------|------|-------------|--------| | **P0** | Critical | Security vulnerability, data loss risk, correctness bug | Must block merge | | **P1** | High | Logic error, significant SOLID violation, performance regression | Should fix before merge | | **P2** | Medium | Code smell, maintainability concern, minor SOLID violation | Fix in this PR or create follow-up | | **P3** | Low | Style, naming, minor suggestion | Optional improvement | ## Workflow ### 1) Preflight context - Use `git status -sb`, `git diff --stat`, and `git diff` to scope changes. - If needed, use `rg` or `grep` to find related modules, usages, and contracts. - Identify entry points, ownership boundaries, and critical paths (auth, payments, data writes, network). **Edge cases:** - **No changes**: If `git diff` is empty, inform user and ask if they want to review staged changes or a specific commit range. - **Large diff (>500 lines)**: Summarize by file first, then review in batches by module/feature area. - **Mixed concerns**: Group findings by logical feature, not just file order. ### 2) SOLID + architecture smells - Load `references/solid-checklist.md` for specific prompts. - Look for: - **SRP**: Overloaded modules with unrelated responsibilities. - **OCP**: Frequent edits to add behavior instead of extension points. - **LSP**: Subclasses that break expectations or require type checks. - **ISP**: Wide interfaces with unused methods. - **DIP**: High-level logic tied to low-level implementations. - When you propose a refactor, explain *why* it improves cohesion/coupling and outline a minimal, safe split. - If refactor is non-trivial, propose an incremental plan instead of a large rewrite. ### 3) Removal candidates + iteration plan - Load `references/removal-plan.md` for template. - Identify code that is unused, redundant, or feature-flagged off. - Distinguish **safe delete now** vs **defer with plan**. - Provide a follow-up plan with concrete steps and checkpoints (tests/metrics). ### 4) Security and reliability scan - Load `references/security-checklist.md` for coverage. - Check for: - XSS, injection (SQL/NoSQL/command), SSRF, path traversal - AuthZ/AuthN gaps, missing tenancy checks - Secret leakage or API keys in logs/env/files - Rate limits, unbounded loops, CPU/memory hotspots - Unsafe deserialization, weak crypto, insecure defaults - **Race conditions**: concurrent access, check-then-act, TOCTOU, missing locks - Call out both **exploitability** and **impact**. ### 5) Code quality scan - Load `references/code-quality-checklist.md` for coverage. - Check for: - **Error handling**: swallowed exceptions, overly broad catch, missing error handling, async errors - **Performance**: N+1 queries, CPU-intensive ops in hot paths, missing cache, unbounded memory - **Boundary conditions**: null/undefined handling, empty collections, numeric boundaries, off-by-one - Flag issues that may cause silent failures or production incidents. ### 6) Output format Structure your review as follows: ```markdown ## Code Review Summary **Files reviewed**: X files, Y lines changed **Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT] --- ## Findings ### P0 - Critical (none or list) ### P1 - High 1. **[file:line]** Brief title - Description of issue - Suggested fix ### P2 - Medium 2. (continue numbering across sections) - ... ### P3 - Low ... --- ## Removal/Iteration Plan (if applicable) ## Additional Suggestions (optional improv