agentleFS
Sign inStart free
jezwebjezweb/vite-flare-starter/skills/code-review/SKILL.md

code-review

Skill49 starsChanged 3 months agoMITView on GitHub

Review code for bugs, security issues, performance problems, and style. Use when the user pastes code, shares a file, or asks "what's wrong with this code?".

We split this skill into the rules it gives an agent

8 rules. 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 183 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Line reference: if available

    line 34
  2. Very specific:

    Use show_alert (error type) for any critical findings at the top

    line 42
  3. Distinctive:

    Don't make up issues to seem thorough

    line 58
  4. Distinctive:

    Don't suggest sweeping rewrites unless asked

    line 59
  5. Distinctive:

    Don't mix style nits with critical bugs in the same list (separate by severity)

    line 60
  6. Distinctive:

    Don't claim certainty about runtime behaviour you can't verify (note assumptions)

    line 61
  7. Very specific:

    If run_python or run_shell tools are available and the code is safe to execute, run it with the user's permission to verify:

    line 64
  8. Very specific:

    Use confirm_action first: "Should I run this code in the sandbox to test it?"

    line 68

“Common” is measured: kept by at least 6 in 10 of the 183 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

When to use

  • User pastes code in chat
  • User attaches a code file
  • User asks for review, audit, "find bugs", "security check"

Steps

  1. Identify scope and language — what's being reviewed, in what language? If multiple files involved, ask which to focus on first via ask_questions.
  2. Read the code carefully — don't skim. For files in fs, call fs_read.
  3. Categorise findings:
    • Bugs (incorrect behaviour, will fail at runtime)
    • Security (injection, auth bypass, exposed secrets, unsafe deserialization)
    • Performance (N+1 queries, unnecessary loops, blocking ops)
    • Reliability (missing error handling, race conditions, resource leaks)
    • Style (naming, formatting, idiomatic patterns)
    • Design (architecture, coupling, complexity)
  4. Filter ruthlessly — only report issues you're confident about. Skip:
    • Style nits if the user asked about bugs
    • Theoretical problems with no evidence in this code
    • Personal preferences disguised as best practices
  5. For each finding, provide:
    • Severity: critical / high / medium / low
    • Line reference if available
    • What's wrong (one sentence)
    • Why it matters (one sentence)
    • Suggested fix (code snippet)
  6. Display the findings:
    • For 1-3 findings: render inline as markdown
    • For more: use show_data_table with columns: Severity, Line, Issue, Fix
    • Use show_alert (error type) for any critical findings at the top
  7. Summarise — one paragraph: overall code quality, biggest concern, recommended next action.
  8. Offer next steps via offer_choices:
    • "Apply the critical fix"
    • "Show me how to test this"
    • "Review another file"
    • "Explain finding [N]"

Style

  • Direct but not harsh. Critique the code, not the coder.
  • Show, don't tell — code suggestions speak louder than abstract advice.
  • Acknowledge what's good if there are bright spots.

What not to do

  • Don't make up issues to seem thorough
  • Don't suggest sweeping rewrites unless asked
  • Don't mix style nits with critical bugs in the same list (separate by severity)
  • Don't claim certainty about runtime behaviour you can't verify (note assumptions)

Optional: actually run the code

If run_python or run_shell tools are available and the code is safe to execute, run it with the user's permission to verify:

  • Does it execute without errors?
  • Does the output match expected behaviour?

Use confirm_action first: "Should I run this code in the sandbox to test it?"

Download now (ZIP)

  • Other versions193 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 193

    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

    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.

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

Check your setup, free