Agent skill

Code Review

by ranfdev in ranfdev/DistroShelf

A skill your agent uses when performing a code review of changes, a diff, a commit, or a merge request in this project.

GPL-3.0Auto-check passedDevelopment

Install Code Review

skills CLI
$ npx skills add ranfdev/DistroShelf --skill code-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ranfdev/DistroShelf code-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ranfdev/DistroShelf.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/code-review .claude/skills/code-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
code-review
GitHub stars
327
Token cost
~1.1k tokens
SKILL.md length
602 words
Files
6
Skills in repo
4
Repo updated
First seen
Licence
GPL-3.0

At a glance

A skill your agent uses when performing a code review of changes, a diff, a commit, or a merge request in this project.

  • Works in 4 steps: Read every file in criteria/ (relative… → Evaluate the code under review against… → Report findings as review comments. → …
  • Performing a code review of changes
  • SKILL.md covers Be critical and Future improvements
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Code Review is an agent skill from ranfdev/DistroShelf. Use when performing a code review of changes, a diff, a commit, or a merge request in this project. Defines the review procedure and the criteria (in criteria/) the code must be evaluated against.

Its SKILL.md is about 1.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 6 other files (for example `criteria/error-handling.md`, `criteria/fakers.md` and `criteria/gobject-conventions.md`).

It sits in Development, covering Code review. The repository describes itself as: gtk4 client for https://distrobox.it. The licence is GPL-3.0.

When your agent uses it

  • Performing a code review of changes
  • A merge request in this project

Example prompts

  • “/code-review”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Read every file in criteria/ (relative to this skill's directory).
  2. Evaluate the code under review against each criterion.
  3. Report findings as review comments.
  4. Record future improvements in .opencode/state/future-improvements.md (see "Future improvements" below).

What it can do on your machine

Read from SKILL.md and the folder at commit 1b85cb0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Code Review loads about 1.1k tokens when it runs. Until then it costs about 52 tokens; SKILL.md has 602 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~52
When it runs · the whole SKILL.md, loaded when a task matches
~1.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ranfdev/DistroShelf at commit 1b85cb0, republished under its GPL-3.0 licence (© ranfdev). 602 words, ~1,133 tokens.

Download SKILL.mdSave it as .claude/skills/code-review/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
code-review
description
Use when performing a code review of changes, a diff, a commit, or a merge request in this project. Defines the review procedure and the criteria (in criteria/) the code must be evaluated against.

Code Review

You MUST:

  1. Read every file in criteria/ (relative to this skill's directory).
  2. Evaluate the code under review against each criterion.
  3. Report findings as review comments.
  4. Record future improvements in .opencode/state/future-improvements.md (see "Future improvements" below).

Each review comment MUST include the location (file:line), a description of the issue, and this set of scores:

  • Confidence: how confident the issue actually exists (0%-100%)
  • Priority: P1 (highest) to P5 (lowest), denoting how important it is to fix the issue. P1 = must fix (bugs, data loss, crashes), P2 = should fix before merge, P3 = worth fixing, P4 = minor improvement, P5 = nitpick.

Present the comments sorted by priority (P1 first), then by confidence, highest first.

Be critical

Review with a skeptical, adversarial mindset — assume the code has problems and hunt for them. Do NOT settle for a surface-level pass:

  • Trace the actual data and control flow of the changed code; do not just read it line by line. Follow the code paths into callers and callees outside the diff when needed.
  • Actively look for: race conditions, unhandled error paths, incorrect edge cases (empty lists, None/null, unicode, concurrency), leaked resources, broken invariants, regressions in behavior the old code had.
  • Question the design, not just the implementation: is this change necessary? Is there a simpler approach? Does it duplicate existing utilities in the codebase?
  • Verify claims: if a comment, commit message, or name implies a behavior, check the code actually does that.
  • For each changed area, ask "how could this break?" and write down at least one hypothesis before concluding the area is fine.
  • A review that finds no P1-P3 issues in a non-trivial change is suspicious; re-examine before concluding the code is clean.

Do not pad the review with speculative or trivial comments to appear thorough — every reported issue must be concrete and actionable.

Show full SKILL.md (300 more words)Show less

Future improvements

After reporting the review comments, record future improvements in .opencode/state/future-improvements.md (create the file and directory if missing).

A future improvement is an observation about the project as a whole, discovered while reviewing the diff, that does not block the diff. The diff is the probe; the codebase is the patient. The change under review may be perfectly fine — the insight is about what the change revealed.

Litmus test: "Would I ask the author to fix this in this change?" If no, but the project should address it eventually → future improvement. If yes → regular review comment. Never mix the two channels.

Signals to capture:

  • friction — the change required more work than the intent justified (touched many files for one feature, repeated boilerplate, manual sync of duplicated state). Ask "why was this hard?"
  • missing-abstraction — the diff duplicates logic because no shared helper exists; a refactor would make this whole class of change trivial.
  • recurring-nit — the same P4/P5 comment keeps appearing across reviews; it's systemic, not incidental. Candidate for a new criterion, a lint, or a refactor.
  • verification-gap — behavior couldn't be confirmed because there's no test harness/preview/mock for that area.
  • architecture — the change is fine now, but a few more changes like it will strain the current design. Name the tipping point.

Procedure:

  1. Read the existing .opencode/state/future-improvements.md first.
  2. If an existing entry already covers an idea, update that entry by appending the new evidence instead of duplicating it — recurring evidence is what promotes an idea from "hunch" to "do it".
  3. Otherwise append a new entry in this format:
markdown
## <short title>
- Date / review context: <date>, <what was being reviewed>
- Signal: friction | missing-abstraction | recurring-nit | verification-gap | architecture
- Evidence: <files/observations that triggered this>
- Idea: <suggested direction, not a full plan>

It is acceptable to record nothing when the review genuinely surfaced no project-level insight — do not invent entries to appear thorough. At the end of the review, mention (in one line) which future improvements were recorded or updated, if any.

© ranfdev, GPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files in .agents/skills/code-review of ranfdev/DistroShelf.

  • SKILL.md
  • criteria/error-handling.md
  • criteria/fakers.md
  • criteria/gobject-conventions.md
  • criteria/simplicity.md
  • criteria/state-management.md

Open the folder on GitHubat commit 1b85cb0

Compare with similar skills

Code Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Code Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Code Review this skillranfdev/DistroShelf327—~1.1kAutomated safety check: PassGPL-3.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Code Review ChecklistshareAI-lab/learn-claude-code78k5 repos~1.1kAutomated safety check: PassMIT
Backend Code Reviewlangflow-ai/langflow156k—~3.5kAutomated safety check: NotesMIT
Understand Diff AnalysisEgonex-AI/Understand-Anything86k1 repos~1.4kAutomated safety check: PassMIT
Mole Bug Patternstw93/Mole70k—~2kAutomated safety check: PassGPL-3.0

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Code Review Checklist

    shareAI-lab/learn-claude-code

    Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.

    78k GitHub starsUsed in 5 repos~1.1k tokens
    DevelopmentAuto-check passed
  • Backend Code Review

    langflow-ai/langflow

    Review backend code for quality, security, maintainability, and best practices based on established checklist rules.

    156k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check: notes
  • Understand Diff Analysis

    Egonex-AI/Understand-Anything

    Reads your git changes or a pull request against a prebuilt knowledge graph of the project to explain what changed, which components are affected and what is risky.

    86k GitHub starsUsed in 1 repo~1.4k tokens
    DevelopmentAuto-check passed
  • A catalog of recurring bug shapes in the Mole Mac cleaner, used to review safety-sensitive diffs for deletion safety, unbounded commands, shell traps and weak tests.

    70k GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed
  • Backend Code Review

    langgenius/dify

    Reviews backend code under api/ for concrete, reproducible defects, routes to rule packs for architecture, schema, repositories and SQLAlchemy, and ranks findings from P0 to P3.

    158k GitHub stars~676 tokensUpdated today
    DevelopmentAuto-check passed

More from ranfdev/DistroShelf

  • Fix UI Files

    ranfdev/DistroShelf

    Diagnose and pinpoint structural errors in GTK Builder .ui files (mismatched closing tags, unclosed elements).

    327 GitHub stars~650 tokensUpdated 1 mo ago
    Auto-check passed
  • Release

    ranfdev/DistroShelf

    Prepare the next release of DistroShelf: version bump, release notes, commit, and tag.

    327 GitHub stars~448 tokensUpdated 1 mo ago
    Auto-check passed
  • Gnome SDK Docs

    ranfdev/DistroShelf

    Browse GNOME SDK documentation including GObject Introspection (.gir) files, D-Bus interfaces or icons that can be useful for GNOME apps development.

    327 GitHub stars~544 tokensUpdated 1 mo ago
    Auto-check passed

Categories

Questions about Code Review

What does Code Review do?

A skill your agent uses when performing a code review of changes, a diff, a commit, or a merge request in this project. Code Review is an agent skill from ranfdev/DistroShelf. Use when performing a code review of changes, a diff, a commit, or a merge request in this project.

When should I use Code Review?

Code Review fits situations like: performing a code review of changes; A merge request in this project.

How do I install Code Review in Claude Code?

Run `npx skills add ranfdev/DistroShelf --skill code-review -a claude-code`. Or copy the skill folder (.agents/skills/code-review in ranfdev/DistroShelf) into .claude/skills/code-review in your project. Claude Code loads it when a task matches its description.

How do I install Code Review in Codex?

Run `npx skills add ranfdev/DistroShelf --skill code-review -a codex`. Or copy the skill folder (.agents/skills/code-review in ranfdev/DistroShelf) into .agents/skills/code-review in your project. Codex loads it when a task matches its description.

Can I use Code Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ranfdev/DistroShelf --skill code-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/code-review, .gemini/skills/code-review, .github/skills/code-review and .opencode/skills/code-review in your project.

What does Code Review need to run?

SKILL.md names no scripts, command-line tools or credentials: Code Review is instructions for the agent only.

Does Code Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Code Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Code Review use?

Code Review is published under the GPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Code Review use?

About 1.1k tokens (SKILL.md is roughly 4.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Code Review?

Skills that share tags, products or a category with Code Review: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Code Review Checklist (shareAI-lab/learn-claude-code, 78k stars), Backend Code Review (langflow-ai/langflow, 156k stars) and Understand Diff Analysis (Egonex-AI/Understand-Anything, 86k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Code Review?

ranfdev (a GitHub user) maintains it in ranfdev/DistroShelf, which has 327 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on August 17, 2026.

Source: ranfdev/DistroShelf on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.