typvtypv/nest-turbo-starter/.claude/skills/code-review/SKILL.md

code-review

Skill224 starsChanged 3 months agoMITView on GitHub

Review code quality, receive feedback with technical rigor, verify completion claims. Use before PRs, after implementing features, when claiming task completion. Includes scout-based edge case detection and native Task pipeline orchestration.

We split this skill into the rules it gives an agent

11 rules. 0 are common, 10 are distinctive, and 1 is very specific to this project.

0
Common
Most of the 184 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
If invoked with context (recent changes/PR), proceed with review.
line 13
Distinctive:
Verify before implementing.
line 28
Distinctive:
Pattern: READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
line 53
Distinctive:
No performative agreement: "You're absolutely right!", "Great point!"
line 56
Distinctive:
No implementation before verification
line 57
Distinctive:
When: After each task, major features, before merge
line 69
Distinctive:
When: After implementation, before requesting code-reviewer
line 81
Distinctive:
Re-review cycles: If fixes introduce new issues, create cycle-2 review task.
line 106
Distinctive:
Iron Law: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
line 112
Distinctive:
Task Pipeline: Create review tasks with dependencies → auto-unblock through chain
line 130
Distinctive:
Verify. Scout. Question. Then implement.
line 147

“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.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Code Review

Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.

Default (No Arguments)

If invoked with context (recent changes/PR), proceed with review. If invoked WITHOUT arguments, use AskUserQuestion to present available review operations:

Operation	Description
`(default)`	Review recent changes/PR
`codebase`	Full codebase scan & analysis
`codebase parallel`	Parallel multi-reviewer audit

Present as options via AskUserQuestion with header "Review Operation", question "What would you like to do?".

Core Principle

YAGNI, KISS, DRY always. Technical correctness over social comfort. Be honest, be brutal, straight to the point, and be concise.

Verify before implementing. Ask before assuming. Evidence before claims.

Practices

Practice	When	Reference
Receiving feedback	Unclear feedback, external reviewers, needs prioritization	`references/code-review-reception.md`
Requesting review	After tasks, before merge, stuck on problem	`references/requesting-code-review.md`
Verification gates	Before any completion claim, commit, PR	`references/verification-before-completion.md`
Edge case scouting	After implementation, before review	`references/edge-case-scouting.md`
Task-managed reviews	Multi-file features (3+ files), parallel reviewers, fix cycles	`references/task-management-reviews.md`

Quick Decision Tree

SITUATION?
│
├─ Received feedback → STOP if unclear, verify if external, implement if human partner
├─ Completed work → Scout edge cases → Request code-reviewer subagent
├─ Multi-file feature (3+ files) → Create review pipeline tasks (scout→review→fix→verify)
└─ About to claim status → RUN verification command FIRST

Receiving Feedback

Pattern: READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT

Rules:

No performative agreement: "You're absolutely right!", "Great point!"
No implementation before verification
Restate, ask questions, push back with reasoning, or just work
YAGNI check: grep for usage before implementing "proper" features

Source handling:

Human partner: Trusted - implement after understanding
External reviewers: Verify technically, check breakage, push back if wrong

Full protocol: references/code-review-reception.md

Requesting Review

When: After each task, major features, before merge

Process:

Scout edge cases first (see below)
Get SHAs: BASE_SHA=$(git rev-parse HEAD~1) and HEAD_SHA=$(git rev-parse HEAD)
Dispatch code-reviewer subagent with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
Fix Critical immediately, Important before proceeding

Full protocol: references/requesting-code-review.md

Edge Case Scouting

When: After implementation, before requesting code-reviewer

Process:

Invoke /scout with edge-case-focused prompt
Scout analyzes: affected files, data flows, error paths, boundary conditions
Review scout findings for potential issues
Address critical gaps before code review

Full protocol: references/edge-case-scouting.md

Task-Managed Review Pipeline

When: Multi-file features (3+ changed files), parallel code-reviewer scopes, review cycles with Critical fix iterations.

Pipeline: scout → review → fix → verify (each a Task with dependency chain)

TaskCreate: "Scout edge cases"         → pending
TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
TaskCreate: "Fix critical issues"      → pending, blockedBy: [review]
TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]

Parallel reviews: Spawn scoped code-reviewer subagents for independent file groups (e.g., backend + frontend). Fix task blocks on all reviewers completing.

Re-review cycles: If fixes introduce new issues, create cycle-2 review task. Limit 3 cycles, escalate to user after.

Full protocol: references/task-management-reviews.md

Verification Gates

Iron Law: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

Gate: IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim

Requirements:

Tests pass: Output shows 0 failures
Build succeeds: Exit 0
Bug fixed: Original symptom passes
Requirements met: Checklist verified

Red Flags: "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports

Full protocol: references/verification-before-completion.md

Integration with Workflows

Subagent-Driven: Scout edge cases → Review after EACH task → Verify before next
Pull Requests: Scout → Verify tests → Code-reviewer review → Merge
Task Pipeline: Create review tasks with dependencies → auto-unblock through chain
Cook Handoff: Cook completes phase → review pipeline tasks → all complete → cook proceeds

Codebase Analysis Subcommands

Subcommand	Reference	Purpose
`/code-review codebase`	`references/codebase-scan-workflow.md`	Scan & analyze the codebase
`/code-review codebase parallel`	`references/parallel-review-workflow.md`	Ultrathink edge cases, then parallel verify

Bottom Line

Technical rigor over social performance
Scout edge cases before review
Task-manage reviews for multi-file features
Evidence before claims

Verify. Scout. Question. Then implement. Evidence. Then claim.

Download now (ZIP)

Other versions194 projects use a version of this.
Word for word · 0
None found.
Edited · 1
mrgoonie/claudekit-skills★ 2.2k15% same
Wrote their own version · 193
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
183 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.
- PydanticSkill
  add-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 AzureSkill
  azsdk-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-aiSkill
  bkend-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-aiSkill
  bkend-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
- dzhngSkill
  close-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
- dzhngSkill
  design-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 repository46 other files it gives its agents.
- .claude/skills/react-best-practices/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ai-multimodalSkill
- askSkill
- backend-developmentSkill
- brainstorm-featuresSkill
- brainstorm-technicalSkill
- chrome-devtoolsSkill
- context-engineeringSkill
- cookSkill
- databasesSkill
- debugSkill
- design-mockup-createSkill
- design-systemSkill
- devopsSkill
- docs-seekerSkill
- docsSkill
- fixSkill
- frontend-designSkill
- frontend-developmentSkill
- gitSkill
- journalSkill
- markdown-novel-viewerSkill
- mermaidjs-v11Skill
- mobile-developmentSkill
- plans-kanbanSkill
- planSkill
- previewSkill
- problem-solvingSkill
- project-managementSkill
- quality-gatesSkill
- react-best-practicesSkill
- repomixSkill
- researchSkill
- scoutSkill
- sequential-thinkingSkill
- skill-creatorSkill
- specsSkill
- teamSkill
- test-casesSkill
- testSkill
- ui-stylingSkill
- ui-ux-pro-maxSkill
- web-design-guidelinesSkill
- web-frameworksSkill
- web-testingSkill

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.

Check your setup, free

11 rules. 0 are common, 10 are distinctive, and 1 is very specific to this project.

Code Review

Default (No Arguments)

Core Principle

Practices

Quick Decision Tree

Receiving Feedback

Requesting Review

Edge Case Scouting

Task-Managed Review Pipeline

Verification Gates

Integration with Workflows

Codebase Analysis Subcommands

Bottom Line

Word for word · 0

Edited · 1

Wrote their own version · 193

add-new-model

azsdk-common-sdk-breaking-change

bkend-auth

bkend-cookbook

close-spec

design-with-images

Does it work?

No reviews yet

Your trail

Now do this for your own.