code-review
Skill216 starsChanged 6 months agoMITView on GitHub
Structured code review focusing on correctness, security, and maintainability. Correctness before style. Every reviewer comment must be actionable.
We split this skill into the rules it gives an agent
9 rules. 0 are common, 9 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 184 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Before merging any pull request
- Distinctive: line 16
When reviewing AI-generated code
- Distinctive: line 17
When auditing existing code for quality
- Distinctive: line 23
Read the PR description fully — understand the intent before reading code.
- Distinctive: line 24
Check: Does the implementation match the stated intent?
- Distinctive: line 34
Do tests cover the happy path AND key failure paths?
- Distinctive: line 53
Every comment must be one of:
- Distinctive: line 54
Blocker: Must be fixed before merge
- Distinctive: line 58
Never leave vague comments like *"this doesn't look right"* without explaining why.
“Common” is measured: kept by at least 6 in 10 of the 184 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Overview
Code review is the last line of defense before code reaches production. This skill structures the review process to catch real issues — not just style preferences — and ensures every comment is actionable and proportionate.
When to Use
- Before merging any pull request
- When reviewing AI-generated code
- When auditing existing code for quality
Process
Step 1: Understand the Change
- Read the PR description fully — understand the intent before reading code.
- Check: Does the implementation match the stated intent?
- Identify the risk level: data mutation? auth changes? public API?
Verify: You understand what the PR is trying to accomplish.
Step 2: Correctness Review
- Does the code do what it claims to do?
- Are there off-by-one errors, null dereferences, or race conditions?
- Are all error cases handled?
- Do tests cover the happy path AND key failure paths?
Verify: You can trace the execution path for the primary use case and 2 failure cases.
Step 3: Security Review
- Apply security-hardening skill to any auth/input/data changes.
- Does this change open any OWASP Top 10 vulnerabilities?
- Are any secrets or PII handled correctly?
Step 4: Maintainability Review
- Will the next developer understand this code without the author present?
- Are functions doing one thing?
- Are names descriptive and accurate?
- Is complexity proportionate to the problem?
Step 5: Provide Actionable Feedback
- Every comment must be one of:
- Blocker: Must be fixed before merge
- Suggestion: Optional improvement
- Question: Needs clarification (not necessarily a problem)
- Blockers must be specific: "This SQL query is vulnerable to injection via
{username}— use parameterized queries." - Never leave vague comments like "this doesn't look right" without explaining why.
Common Rationalizations (and Rebuttals)
| Excuse | Rebuttal |
| "I'll review it quickly" | A rushed review is not a review. Take the time or ask someone who can. |
| "The tests pass so it's fine" | Tests prove the code works for tested inputs, not that it's secure or maintainable. |
| "I'll comment on style later" | Style comments without blocker separation waste everyone's time. Label them. |
Verification
- Correctness verified for primary and failure paths
- Security review applied to sensitive changes
- All comments labeled (blocker/suggestion/question)
- Tests reviewed for meaningful coverage
- No vague or unactionable comments
References
- security-hardening skill
- references/security-checklist.md
Other versions194 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 194
- mattpocock/skills★ 309ksame name
- TheAlgorithms/Python★ 226ksame name
- microsoft/vscode★ 194ksame name
- github/spec-kit★ 145ksame name
- ggml-org/llama.cpp★ 133ksame name
- shareAI-lab/learn-claude-code★ 80ksame name
- shareAI-lab/analysis_claude_code★ 78ksame name
- vectorize-io/hindsight★ 57ksame name
- dbeaver/dbeaver★ 52ksame name
- roboflow/supervision★ 51ksame name
184 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use add-new-model, azsdk-common-sdk-breaking-change and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
PydanticSkilladd-new-model
Add support for a newly-released language or image generation model in pydantic-ai (e.g. openai:gpt-5.6, anthropic:claude-sonnet-5, openai:gpt-image-2). Use when a provider ships a new model id and you need to wire literals, profile flags, adapters, and tests to recognize it. Handles SDK-lag, gateway list conventions, capability probing, and direct image-model geometry.
Also in 9 projects that use this
Microsoft AzureSkillazsdk-common-sdk-breaking-change
Detect and mitigate SDK Breaking changes for an SDK package which is generated from TypeSpec. WHEN: "Detect SDK breaking changes for a service", "Detect SDK breaking changes for an SDK package", "Detect and mitigate SDK breaking changes for a service", "Detect and mitigate SDK breaking changes for an SDK package". INVOKES: skill: azsdk-common-generate-sdk-locally; MCP tools: azure-sdk-mcp:azsdk_customized_code_update, azure-sdk-mcp:azsdk_package_detect_breaking_change.
Also in 4 projects that use this
ww-w-aiSkillbkend-auth
bkend.ai authentication guide. Signup, login, JWT tokens, sessions, role-based access control, and password management with bkend.ai BaaS. Triggers: bkend auth, bkend login, bkend signup, JWT, session, RBAC, password, bkend 인증, 로그인, 회원가입, bkend認証, ログイン, 新規登録, bkend认证, 登录, 注册, autenticacion bkend, authentification bkend, bkend-Auth Do NOT use for: data operations (use $bkend-data), file storage (use $bkend-storage).
Also in 4 projects that use this
ww-w-aiSkillbkend-cookbook
bkend.ai cookbook with step-by-step tutorials and example projects. Build a todo app, blog, e-commerce store, and more with bkend.ai BaaS. Triggers: bkend cookbook, bkend tutorial, bkend example, todo app, blog app, bkend 쿡북, bkend 튜토리얼, 예제 프로젝트, bkendクックブック, チュートリアル, bkend教程, 示例项目, tutorial bkend, tutoriel bkend, bkend-Tutorial, ricettario Do NOT use for: initial setup (use $bkend-quickstart), specific features (use $bkend-data/auth/storage).
Also in 4 projects that use this
dzhngSkillclose-spec
When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).
Also in 4 projects that use this
dzhngSkilldesign-with-images
Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.
Also in 4 projects that use this
- +5 more from ww-w-ai
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-qa-run-reviewSkill
- ai-output-validationSkill
- api-designSkill
- ci-cd-pipelinesSkill
- citruscoastaiSkill
- code-explanationSkill
- context-loadingSkill
- debugging-methodologySkill
- documentationSkill
- error-handlingSkill
- frontend-engineeringSkill
- git-workflowSkill
- goal-driven-executionSkill
- hallucination-preventionSkill
- idea-to-specSkill
- incremental-codingSkill
- integration-testingSkill
- meeting-notes-to-tasksSkill
- multi-agent-orchestrationSkill
- observabilitySkill
- performance-optimizationSkill
- production-deploymentSkill
- prompt-injection-defenseSkill
- rag-and-memorySkill
- refactoringSkill
- research-and-summarizeSkill
- security-hardeningSkill
- simplicity-firstSkill
- surgical-changesSkill
- task-decompositionSkill
- test-driven-developmentSkill
- think-before-codingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

