code-review

name	code-review
description	Code review skill — critique the working diff and surface real issues, with optional wiki context for the change
scope	repo

Code Review

Review the working diff in this repository. Surface real issues — correctness, security, edge cases, readability problems that will actually bite — not stylistic nits a linter would catch.

When to invoke

Run this skill when the user asks to "review", "code review", "check my changes", "look at the diff", or otherwise signals they want a critique of the current change before they commit, push, or open a PR.

Behavior

Step 1 — Establish the scope of the review

Default scope is the working diff against the closest integration branch (typically main or master). Use:

git diff --stat $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null || echo HEAD~1)

If $ARGUMENTS names a different base ref, PR number, or commit range, use that instead.

If the diff is empty, say so and stop — there's nothing to review.

Step 2 — Read the full diff and the surrounding code

git diff <base>...HEAD gives the patch. For each changed file, also read the full file (not just the hunks) so you can reason about call sites, invariants, and edge cases the diff hunk doesn't show on its own.

Step 3 — Pull in wiki context (opportunistic)

If this workspace has a wiki/ folder one or two directories up (rubber-ducky workspace pattern), look for related context before drafting the review:

rubber-ducky --workspace ../.. query "<feature or area name from the diff>" 2>/dev/null

Use whatever surfaces (recent task pages, design decisions, prior incidents) to inform the review. Skip silently if rubber-ducky is not on PATH or the workspace isn't a rubber-ducky vault — this is opportunistic context, not a hard dependency.

Step 4 — Critique

Organize findings into three buckets, in this order:

• Blocking — bugs, security issues, data-loss risks, broken invariants, missing error handling at real system boundaries. Things that should be fixed before merge.
• Worth raising — design tradeoffs, alternative approaches that may be simpler, edge cases the change doesn't handle, missing tests for non-trivial logic.
• Minor — readability, naming, comment clarity. Keep this section short; if it's growing, the author already knows.

For each finding, cite the file and line (path/to/file.ts:123) so the user can jump straight to it. Explain why it's a problem, not just what is unusual — "this swallows the error and returns null, so callers can't distinguish 'no result' from 'lookup failed'" is useful; "consider improving error handling" is not.

Step 5 — End with a verdict

One line: ship-ready, ship-with-followups, or needs-changes. Be direct. If you found nothing blocking, say so.

Output

A focused review. No preamble, no "great change overall" warm-up, no closing pep talk. Findings cited by file:line, organized blocking → worth-raising → minor, ending with a one-line verdict.

Composing with other skills

For engineering skills beyond what rubber-ducky bundles, install Matt Pocock's set inside the repo:

npx skills@latest add mattpocock/skills

Those land in <repo>/.claude/skills/ and compose with this one — no conflict.