Code Review
Review everyday PRs and diffs by classifying the change domain first, then checking the failure modes that domain actually has.
Overview
code-review is an agent skill most often used in Ship (also Build and Operate) that reviews diffs using a domain classifier so review depth matches algorithm, API, security, data, UI, or infrastructure risks.
Install
npx skills add https://github.com/hermeticormus/code-review-skills --skill code-reviewWhat is this skill?
- Review the diff and surrounding context, not the entire file—findings outside the diff only if newly reachable
- Six-domain classifier: algorithm, API/network, security, data, UI/frontend, infrastructure
- Per-domain review focus (complexity, OWASP, N+1, a11y, CI config failure modes)
- Explicitly scoped to everyday changes—not production-readiness (mars-skills) or hardening (vibe-proof-skills)
- Domain-first checklist instead of a single generic style pass
- 6 code domains in the classifier table
Adoption & trust: 1 installs on skills.sh; trending (+100% hot-view momentum).
What problem does it solve?
A generic AI review floods you with formatting comments and misses the one failure mode your API or data change actually introduces.
Who is it for?
Indie developers merging frequent small PRs who want structured, risk-aware review without running a full audit toolchain.
Skip if: Launch-day production readiness sign-off or dedicated security hardening—the skill points to mars-skills and vibe-proof-skills for those.
When should I use this skill?
When reviewing a change on an everyday diff or pull request; use mars-skills for production-readiness and vibe-proof-skills for security hardening.
What do I get? / Deliverables
You get domain-targeted review notes on the diff, with clear scope that everyday PR review is separate from production-readiness or full security hardening passes.
- Domain-labeled review findings scoped to the diff
- Risk-focused notes per algorithm/API/security/data/UI/infrastructure
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Pull request and diff review is the core Ship → review activity before merge and release. The skill is explicitly for reviewing a change on a diff, not full-repo production readiness or dedicated penetration testing.
Where it fits
Run review on a REST endpoint diff focusing on auth, validation, and error handling instead of CSS nits.
Classify an ORM migration diff under the data domain and check N+1 and consistency implications.
Review a minimal hotfix diff for whether it newly exposes an injection path in user input handling.
How it compares
Use for domain-scoped diff review on a PR, not as a replacement for automated test suites or dedicated security scanners.
Common Questions / FAQ
Who is code-review for?
Solo and small-team builders using AI agents to review GitHub-style diffs before merge when they cannot afford a human reviewer on every change.
When should I use code-review?
In Ship → review on every meaningful PR; in Build when validating integration diffs; in Operate → iterate when reviewing hotfix branches for regressions.
Is code-review safe to install?
Review skill source and permissions; use the Security Audits panel on this Prism page and avoid piping secrets into review prompts.
SKILL.md
READMESKILL.md - Code Review
# Code review Review the everyday diff or pull request by classifying the code's domain first, then applying the checklist for that domain. One generic pass over all code surfaces formatting nits and misses the failure mode that ships the incident. ## 1. Review the change, not the file Read the diff, not the whole file. Read enough surrounding context to judge correctness, no more. A finding outside the diff matters only if the change made it newly reachable or newly wrong. ## 2. Classify the code domain | Domain | Indicators | Review focus | |---|---|---| | Algorithm | Loops, recursion, data structures, sorting or searching | Complexity, edge cases, correctness | | API or network | HTTP, requests, endpoints, REST, GraphQL | Error handling, rate limiting, auth, validation | | Security | Auth, crypto, passwords, tokens, user input | OWASP top 10, injection, data exposure | | Data | SQL, ORM, database, queries, transactions | N+1, indexes, consistency, migrations | | UI or frontend | React, components, DOM, CSS, events | Accessibility, performance, state | | Infrastructure | Docker, K8s, CI/CD, configs, scripts | Security, idempotency, failure modes | A change can span domains. Apply each matching checklist; do not pick one silently. ## 3. Apply the matching focus checklist - Algorithm: correctness for all inputs, Big-O, edge cases (empty, single, max, duplicates), readability of the invariant. - API or network: error handling on timeout and 4xx/5xx, input validation before business logic, auth and authz, rate limiting and idempotent retries. - Security: input validation at the boundary, injection (SQL, command, XSS, template, deserialization), secret handling, server-side access control. - Data: N+1 queries, transaction atomicity and isolation, index usage at production row counts, backward-compatible migrations. - UI: accessibility, render performance, state correctness, effect cleanup and async races. - Infrastructure: least privilege, idempotent apply, partial-failure and rollback path, observability. ## 4. Assign severity to every finding - Critical (must fix): wrong output, data loss, security hole, broken contract. Blocks merge. - Improvement (should fix): correct but fragile, slow at scale, missing a newly reachable edge case. - Nitpick (optional): naming, style, clarity. A finding you cannot assign a severity to is not yet specific enough to report. ## 5. Structure the feedback ```text ## Summary [1-2 sentence overview of what the change does] ## Domain: [detected domain(s)] ## Critical (must fix) - [ ] [file:line] Description + concrete suggestion ## Improvements (should fix) - [ ] [file:line] Description + concrete suggestion ## Nitpicks (optional) - [ ] [file:line] Description ## What's correct - Observation the author got right ``` Every finding cites a location and proposes a direction, not just a complaint. --- See full content at https://github.com/HermeticOrmus/code-review-skills.