agentleFS
Sign inStart free
ziggy42ziggy42/epsilon/.agents/skills/code-review/SKILL.md

code-review

Skill439 starsChanged 5 months agoApache-2.0View on GitHub

Use this skill when the user asks for a code review. It automates checks and analysis.

We split this skill into the rules it gives an agent

19 rules. 0 are common, 6 are distinctive, and 13 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.

  • 13

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check Branch: Run git branch --show-current.

    line 19
  2. Very specific:

    Check Remote: Run git fetch origin main.

    line 22
  3. Very specific:

    Run make build-all (covers Linux, Darwin, and Windows cross-compile, regardless of host OS).

    line 30
  4. Very specific:

    Run make fmt. If any files are modified, stop and report the error.

    line 35
  5. Very specific:

    Run make vet. If any issues are found, stop and report the error.

    line 38
  6. Very specific:

    Run make test to execute Go tests (unit + spec).

    line 40
  7. Very specific:

    Run make test-wasi to verify the WASI Preview 1 implementation.

    line 43
  8. Very specific:

    Compare Benchmarks: Run make bench-compare TARGET=.

    line 48
  9. Very specific:

    Detect New Dependencies: Run git diff origin/main..HEAD -- go.mod go.sum.

    line 59
  10. Very specific:

    If there are changes, stop and report that go mod tidy needs to be run.

    line 64
  11. Very specific:

    Report Changes: If there are any changes to go.mod or go.sum:

    line 66
  12. Distinctive:

    Ask the user to confirm the dependency changes are intentional.

    line 70
  13. Very specific:

    Find New Files: Run git diff --name-status origin/main..HEAD | grep '^A' to list all newly added files.

    line 74
  14. Very specific:

    Use the appropriate comment syntax for the file type (e.g., # for Python and YAML).

    line 97
  15. Very specific:

    Get the Diff: Run git diff origin/main..HEAD to see all changes.

    line 104
  16. Distinctive:

    Security & Sandboxing: Treat untrusted Wasm and host inputs as hostile.

    line 116
  17. Distinctive:

    Ensure README.md and other documentation is updated if new features, flags, or configuration options were added.

    line 143
  18. Distinctive:

    Ensure AGENTS.md is still accurate after the change: if the diff alters the project layout, build/test commands, conventions, or …

    line 145
  19. Distinctive:

    Compile Findings: Create a structured report with:

    line 160

“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

Overview

This skill provides a comprehensive code review process for the current branch. It verifies the code builds and passes tests across platforms, checks for performance regressions, and reviews the diff for bugs, improvements, and adherence to project standards.

Procedure

1. Preparation

  1. Check Branch: Run git branch --show-current. If the output is main, inform the user that the current branch is main and reviews on main are not supported yet.
  2. Check Remote: Run git fetch origin main. This ensures origin/main is up-to-date for accurate comparison.
  3. Get Branch Point: Determine the merge base with git merge-base origin/main HEAD. Store this for later use.

2. Build & Test Verification

  1. Build for All Platforms:
    • Run make build-all (covers Linux, Darwin, and Windows cross-compile, regardless of host OS).
    • Cleanup afterwards: make clean.
    • If any build fails, stop and report the error.
  2. Lint & Format:
    • Run make fmt. If any files are modified, stop and report the error.
    • Run make fmt-md. If any files are modified, stop and report the error (Markdown is not formatted).
    • Run make vet. If any issues are found, stop and report the error.
  3. Run All Tests:
    • Run make test to execute Go tests (unit + spec).
    • If tests fail, stop and report the errors.
  4. Run WASI Tests:
    • Run make test-wasi to verify the WASI Preview 1 implementation.
    • If WASI tests fail, stop and report the errors.

3. Performance Verification

  1. Compare Benchmarks: Run make bench-compare TARGET=. to compare performance against the main branch (the default base). NOTE: This can take several minutes as it runs the benchmark suite twice.
  2. Review Results: Present the benchmark results to the user. Flag any regressions where:
    • Time (ns/op) increased by more than 5%.
    • Memory (B/op) increased.
    • Allocations (allocs/op) increased.

4. Dependency Check

  1. Detect New Dependencies: Run git diff origin/main..HEAD -- go.mod go.sum.
  2. Verify Module Consistency:
    • Run go mod tidy.
    • Run git diff --name-only go.mod go.sum.
    • If there are changes, stop and report that go mod tidy needs to be run.
  3. Report Changes: If there are any changes to go.mod or go.sum:
    • CRITICAL: This project is pure Go with no CGo. New dependencies are strongly discouraged.
    • Report exactly what dependencies were added or modified.
    • Ask the user to confirm the dependency changes are intentional.

5. License Header Check

  1. Find New Files: Run git diff --name-status origin/main..HEAD | grep '^A' to list all newly added files.

  2. Check Headers: For each new source file (.go, .py, .yml, etc.), verify it contains the proper license header:

    // Copyright [Year] Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

    Use the appropriate comment syntax for the file type (e.g., # for Python and YAML).

  3. Report Missing Headers: List any files missing the license header.

6. Code Review

  1. Get the Diff: Run git diff origin/main..HEAD to see all changes.

  2. Review for Issues: Analyze the diff and check for:

    Bugs & Correctness:

    • Logic errors and edge cases.
    • Improper error handling (errors must be handled or propagated, never ignored).
    • Data races or concurrency issues.
    • Off-by-one errors.

    Security & Sandboxing: Treat untrusted Wasm and host inputs as hostile. The bullets below are a floor, not a ceiling — hunt for classes of flaw they don't name.

    • Validator is the boundary: the VM trusts it, so any skipped or weakened check there is exploitable.
    • Untrusted Wasm or invalid host inputs must never panic — failures surface as standard Go errors.
    • Sandbox escapes: untrusted code reaching host state it shouldn't see.

    Performance (especially in hot paths like the VM loop):

    • Unnecessary heap allocations.
    • Inefficient algorithms.
    • Missed opportunities to reuse buffers/slices.
    • Unnecessary copying of data.

    Simplicity & Readability:

    • Overly complex code that could be simplified.
    • Duplicate code that could be refactored.
    • Poor variable naming (names should be self-explanatory).
    • Unnecessary comments (code should be self-explanatory). Verify no "TODO", "FIXME", or placeholder comments were left behind.

    Documentation:

    • Ensure README.md and other documentation is updated if new features, flags, or configuration options were added.
    • Ensure AGENTS.md is still accurate after the change: if the diff alters the project layout, build/test commands, conventions, or constraints it documents, it must be updated to match.

    Modern Go Features:

    • Opportunities to use newer Go features (e.g., generics, improved slices package, range-over-int, etc.).
    • Deprecated patterns that should be updated.

    Project Standards:

    • Adherence to rules in AGENTS.md.
    • Consistent style with existing code.

  3. Compile Findings: Create a structured report with:

    • Critical Issues: Bugs, correctness problems, or security concerns that must be fixed.
    • Suggestions: Performance improvements, simplifications, or style enhancements.
    • Notes: Minor observations or questions.

7. Report

Present a summary to the user containing:

  1. ✅ or ❌ for each verification step (build, lint, tests, spec tests, WASI tests).
  2. Benchmark comparison results with any regressions highlighted.
  3. Dependency change report (if any).
  4. List of files missing license headers (if any).
  5. Code review findings organized by severity.
  6. An overall recommendation: Ready to Merge or Needs Changes.

Download now (ZIP)

  • Other versions194 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 2

    1. maka-agent/maka-agent★ 5.8k12% same
    2. apache/maka★ 5.8k12% same

    Wrote their own version · 192

    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/learn-claude-code★ 80ksame name
    7. shareAI-lab/analysis_claude_code★ 78ksame name
    8. vectorize-io/hindsight★ 57ksame name
    9. dbeaver/dbeaver★ 52ksame name
    10. roboflow/supervision★ 51ksame name

    182 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 repository4 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