agentleFS
matthullmatthull/my-skills/skills/technical/code-review/SKILL.md

code-review

Skill0 starsChanged 55 days agoMITView on GitHub

Structured code review with parallel specialist agents in separate subagent contexts. Uses /skill-discovery for domain-aware reviews. Each leg runs in its own fresh subagent for clean analysis.

We split this skill into the rules it gives an agent

13 rules. 0 are common, 6 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 184 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default behavior: Run ALL legs in parallel against current branch diff to default branch.

    line 27
  2. Very specific:

    To limit: Use --legs= with comma-separated leg names.

    line 28
  3. Very specific:

    If --branch or "branch" mentioned: git diff {default-branch}...{branch}

    line 40
  4. Very specific:

    If target is a path: git diff -- {path} or read files directly

    line 41
  5. Very specific:

    If no specific target: git diff {default-branch}...HEAD (current branch vs default)

    line 42
  6. Distinctive:

    If no changes found, report "No changes to review" and exit.

    line 47
  7. Distinctive:

    If your environment has a specialized code-review subagent type configured, use it for sharper, review-tuned analysis.

    line 62
  8. Distinctive:

    After all subagents return, synthesize into a unified report:

    line 75
  9. Distinctive:

    If no browser-testing binding is configured, note in the report that visual/browser QA was out of scope for this review and should be …

    line 125
  10. Very specific:

    Read resources/personal-skill.md if it exists — personal review preferences (e.g., preferred leg subset, notification routing).

    line 138
  11. Very specific:

    Read resources/domain-skill.md if it exists — project-specific review configuration (e.g., extra legs, project conventions to weight …

    line 139
  12. Distinctive:

    Check the project's CLAUDE.md / CLAUDE.local.md for environment-level capability bindings (especially browser-testing).

    line 140
  13. Very specific:

    Default --legs= subset for this project, if the full set is usually overkill

    line 150

“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 — Structured Multi-Leg Code Review

Parallel specialist review agents, each in a fresh subagent context with a narrow focus and concrete checklist. Adapts to the codebase via /skill-discovery — loads domain skills (ruby-on-rails, vue, api-integration, etc.) based on changed files to inject project-specific review criteria.

Usage

/code-review                                          # all legs, current branch diff to default branch
/code-review current branch diff to master             # explicit target description
/code-review --legs=security,wiring,test-quality       # specific legs only
/code-review --branch=feature-branch                   # explicit branch
/code-review src/components/                           # specific directory

Default behavior: Run ALL legs in parallel against current branch diff to default branch. To limit: Use --legs= with comma-separated leg names.

Process

Step 1: Determine Review Target

Parse $ARGUMENTS for:

  • Legs filter — value after --legs= (comma-separated list). If omitted, run ALL legs.
  • Branch — value after --branch= (diff against default branch)
  • Target — remaining args (file path, directory, or description like "current branch diff to master")

Get the diff:

  • If --branch or "branch" mentioned: git diff {default-branch}...{branch}
  • If target is a path: git diff -- {path} or read files directly
  • If no specific target: git diff {default-branch}...HEAD (current branch vs default)
  • Fallback: git diff (uncommitted changes)

Also gather: git diff --stat for file change summary, count of files/insertions/deletions.

If no changes found, report "No changes to review" and exit.

Step 2: Skill Discovery

Invoke /skill-discovery via the Skill tool. This scans the installed skill catalog, evaluates relevance to the changed files, and outputs reasoning. It handles:

  • Identifying which domain skills are relevant (ruby-on-rails, vue, unit-testing, etc.)
  • Loading those skills so their guidance is available in context
  • Outputting the reasoning for transparency

The loaded domain skill content becomes available for injection into leg prompts.

Step 3: Launch ALL Leg Subagents in Parallel

Every leg runs in its own separate subagent (via the Agent tool, run_in_background: true). Fresh context per leg ensures focused, independent analysis. The overhead is worth it for review quality.

If your environment has a specialized code-review subagent type configured, use it for sharper, review-tuned analysis. Otherwise use the general-purpose agent type — the leg prompt's narrow focus and checklist do most of the work regardless of agent type.

For each leg (all legs unless --legs= filter was provided), spawn an Agent with:

  1. Base preamble — from resources/leg-prompts.md (output format, file:line reference requirement)
  2. Leg-specific prompt — the "Look for" checklist and "Questions to answer" for that leg
  3. The full diff — each subagent gets the complete diff to analyze from its perspective
  4. Domain context — relevant project conventions from loaded skills and CLAUDE.md

Launch ALL legs in a single message with multiple Agent tool calls.

Step 4: Synthesize Findings

After all subagents return, synthesize into a unified report:

  1. Read all leg outputs
  2. Deduplicate — same issue found by multiple legs → merge into single entry, note all legs that found it
  3. Cross-reference confidence — issues found by 3+ legs → auto-promote to next severity
  4. Resolve conflicts — if legs disagree, flag as "Needs discussion" with both perspectives
  5. Prioritize — P0 (must fix) → P1 (should fix) → P2 (nice to fix)

Step 5: Output Report

@resources/synthesis-template.md


Review Legs

Each leg has a narrow focus, concrete "Look for" checklist, and judgment-forcing "Questions to answer." Full leg definitions are in resources/leg-prompts.md.

By default ALL legs run. Use --legs= to run a subset.

Analysis Legs

LegFocus
correctnessLogic errors, edge cases, race conditions, off-by-one
performanceN+1 queries, O(n^2), missing indexes, blocking in async
securityOWASP, injection, auth bypass, data exposure, mass assignment
eleganceAbstraction quality, coupling, SOLID, reinventing utilities
resilienceError handling, failure modes, partial failures, recovery
styleConvention compliance, naming, imports, comment quality
smellsLong methods (>50 lines), deep nesting (>3), DRY violations, god classes

Verification Legs

LegFocus
wiringDependencies added but not used, SDK added but old impl remains
commit-disciplineCommit quality, atomicity, message clarity
test-qualityWeak assertions, missing negative cases, flaky indicators

NOT Responsible For

These are separate skills with their own scope:

  • Spec compliance — /spec-check (per-requirement PASS/FAIL against spec)
  • QA classification — /qa-plan (classifying verification items by execution channel)
  • Handoff compliance — checking code against task handoff directives is a separate concern this skill does not cover
  • Browser verification — a companion skill using the browser-testing capability (visual QA in real browser)

This skill reviews code quality, correctness, and implementation patterns — not whether the implementation matches a spec or handoff.

If no browser-testing binding is configured, note in the report that visual/browser QA was out of scope for this review and should be requested separately.

Interoperates With

  • /skill-discovery (Step 2) — loads domain skills relevant to the changed files. If /skill-discovery is not installed, skip domain skill loading and proceed with the generic "Look for" checklists only; note in the report that no domain skills were loaded.
  • /spec-check, /qa-plan — complementary review skills with disjoint scope (see NOT Responsible For above). No shared configuration is required between them; each reads the same diff independently.
  • Browser-testing companion skill — if the environment binds the browser-testing capability, a companion skill can pick up visual QA where this skill's scope ends. The binding lives in CLAUDE.md / CLAUDE.local.md so any skill that needs it (this one included) resolves to the same tool.

Project and User Configuration

Load configuration in this order. When multiple sources define the same binding, the first one found wins — stop checking lower sources for that binding:

  1. Read resources/personal-skill.md if it exists — personal review preferences (e.g., preferred leg subset, notification routing).
  2. Read resources/domain-skill.md if it exists — project-specific review configuration (e.g., extra legs, project conventions to weight heavily).
  3. Check the project's CLAUDE.md / CLAUDE.local.md for environment-level capability bindings (especially browser-testing).
  4. For any capability still unbound, use the defaults specified in this skill (browser QA reported as out of scope; general-purpose agent type for legs).

Extension Points

domain-skill.md

Provide project-specific review configuration:

  • Additional or project-specific review legs beyond the standard set
  • Project conventions the elegance and style legs should weight heavily (beyond what /skill-discovery already loads)
  • Known false-positive patterns to deprioritize (e.g., a pattern that looks like a smell but is intentional in this codebase)
  • Default --legs= subset for this project, if the full set is usually overkill

personal-skill.md

Provide personal review preferences:

  • Preferred severity threshold for what gets surfaced (e.g., suppress P2s by default)
  • Notification routing for completed reviews, if any
  • Whether to auto-run /skill-discovery or skip it for speed

Download now (ZIP)

  • Other versions194 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 194

    1. mattpocock/skills★ 309ksame name
    2. TheAlgorithms/Python★ 226ksame name
    3. microsoft/vscode★ 194ksame name
    4. github/spec-kit★ 145ksame name
    5. ggml-org/llama.cpp★ 133ksame name
    6. shareAI-lab/analysis_claude_code★ 80ksame name
    7. shareAI-lab/learn-claude-code★ 80ksame name
    8. vectorize-io/hindsight★ 57ksame name
    9. dbeaver/dbeaver★ 52ksame name
    10. 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.
    • 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 repository43 other files it gives its agents.

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.