Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →kdlbs/code-review
Review changed code for quality, security, and architecture compliance. Use only when the user explicitly requests local review or a PR finding requires it.
Passed 11 of 17 test cases with the skill, and 2 of 17 without it.
and 10 more in the full report
11 fixed3 passed either way8 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/20/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
During review of a Go domain service PR, you find new business logic for calculating tier discounts without any corresponding unit test in *_test.go. How should this finding be categorized and what skill recommendation should be attached?
| Checked | Without skill | With skill |
|---|---|---|
| Categorizes missing test coverage for new non-UI logic as a blocker finding | Passed | Passed |
| Recommends the /tdd skill to assist the author in authoring tests for untested logic | Missed | Passed |
The instructions your model reads when the skill loads.
Run this local review only when the user explicitly asks or an actionable PR/CI finding requires it. Do not use it automatically before opening a PR: the two configured PR AI reviewers are the semantic-review gate.
Review the current changes in the codebase (Go backend + Vite/React SPA monorepo). Every finding needs a file_path:line_number reference, an explanation of why it matters, and a concrete fix.
Start from intent and evidence: read the spec/task first when available, then changed tests before production code. Tests reveal the expected behavior and whether the change is actually verified.
For a large architectural change, verify the authenticated actor's repository
permission before the PR opens. Maintainers and collaborators with push,
maintain, or admin permission may proceed without a linked issue. For an
actor without write access, require a linked issue with maintainer discussion;
if the issue or discussion is missing, report a blocker. Prefer one logical
change and a small diff because this limits risk and maintainer burden.
/tdd — Recommend when flagging untested logic. The author can use this to add tests./mobile-parity — Required when a review touches frontend or user-facing UI, including scrolling, visibility, or activation behavior, even when the change is not described as responsive.Determine the right diff scope:
git diff --name-only (unstaged) and git diff --cached --name-only (staged)git ls-files --others --exclude-standard; read any in-scope source or tests before drawing conclusionsgit diff origin/<base_branch>...HEAD --name-only to diff against the base branchReconcile the inventory with git status --short without staging user changes. If
the review includes uncommitted files, describe it as a working-tree snapshot
over HEAD; do not imply that HEAD contains the implementation.
For an existing PR, first confirm the exact head under review. Do not assume the
test cases passed, vs 2 / 17 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.