Stats
Actions
Tags
From dbud
Use when reviewing branch or PR changes against a base branch for correctness, security, concurrency, architecture, maintainability, testing, and performance risks.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dbud:code-review [--base BRANCH] [--comment [LANGUAGE]][--base BRANCH] [--comment [LANGUAGE]]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Review the current branch or PR against a base branch with adversarial, evidence-based scrutiny. Prefer concrete regressions over style feedback.
Review the current branch or PR against a base branch with adversarial, evidence-based scrutiny. Prefer concrete regressions over style feedback.
Default to a single pass. One reviewer reads the whole diff against the checklist in step 3; a single context keeps cross-cutting bugs (e.g. a change that is both a concurrency and a security issue) visible and findings high-signal. Reserve isolated subagents for one case: a diff too large to review in one focused pass. Partition the substantive files into a few cohesive groups (by module/directory), review each group against the full checklist — sequentially, or as a handful of parallel subagents — then merge and dedup. Never fan out by lens, and never one subagent per file — both fragment cross-cutting bugs and inflate false positives.
origin/main. --base BRANCH compares against BRANCH.--comment [LANGUAGE]: after the report, gate posting through Posting (below) — the user approves a subset in chat and only that subset is posted via add-pr-comments. LANGUAGE sets comment language (default English). Without --comment, the report (step 6) is the final artifact and nothing is posted.Pin the comparison. Set BASE_BRANCH from --base or origin/main, then:
HEAD_SHA=$(git rev-parse HEAD)
MERGE_BASE=$(git merge-base "$BASE_BRANCH" "$HEAD_SHA")
Review "$MERGE_BASE".."$HEAD_SHA" for the entire pass.
Inventory the diff: changed files, shortstat, added/deleted files, diff body. Ignore generated files, vendored code, lockfiles, snapshots, and docs-only changes unless they affect runtime, build, or security.
Read the whole diff against this checklist — or, if it is too large for one focused pass, partition it as described in the intro. correctness always applies; the rest are cues — weight attention to what the diff actually touches. Gather evidence first (cited ranges, prior vs current behavior, touched callers, reachable inputs), then draft a finding only from evidence: title, severity, confidence, file:line, failure mode, fix.
| Lens | Look for |
|---|---|
correctness | logic, null handling, contracts, stale callers, data corruption, migrations, cache staleness, unreachable code |
security | auth/authz, injection, unsafe deserialization, SSRF, path traversal, tenant or PII leaks |
concurrency | non-atomic updates, lock ordering, cancellation hazards, retry interactions, double-submit/double-process |
architecture | boundary breaks, dependency direction, wrong-layer abstractions, cross-module coupling |
maintainability | brittle abstractions, unclear invariants, accidental complexity, obvious simplification not taken |
testing | coverage gaps for changed behavior, weak assertions, flakiness, fixture pollution |
performance | query shape, N+1s, hot-path allocations, nested loops over user data, missing or wrong caching |
Apply the bar. Self-critique each candidate from the PR author's perspective and keep only what the author would clearly fix. Returning zero findings is correct — if nothing clears the bar, say so; never pad the report. Move plausible-but-unverified concerns to residual risks.
Validate every surviving finding against the current code and diff; drop anything the cited range does not support. Dedup overlapping findings, keeping the strongest severity/confidence.
Report in this order:
<merge-base>..<HEAD> resolved to short SHAsready to approve, ready after fixes, or not ready — one line, naming the blockers if anySEV/CONF, file:line, failure mode, fixIf --comment is set, gate posting through Posting below — the only path that writes to GitHub, and only after explicit user approval.
--comment)Posting is the only irreversible step — never invoke add-pr-comments or any gh write until the user approves the final set.
F1, F2, …). Ask the user to reply keep / drop / dive per finding — e.g. "drop F2, dive F4: check the lock at L138, keep the rest."git rev-parse HEAD; if it moved since the review, warn that line anchors may have shifted and confirm before continuing. Hand the kept set + LANGUAGE (default English) to add-pr-comments.After the report, answer user follow-ups conversationally:
critical: exploitable security issue, auth bypass, data loss, corruption, severe outagehigh: likely production failure or serious regressionmedium: real bug under a plausible edge caselow: non-trivial issue worth fixing, not a blockerA blocker is a finding that makes the change unsafe to merge as-is — critical or high by default, a medium only when its edge case is plausible in practice; low is never a blocker.
high: directly supported by cited codemedium: strong evidence with one assumptionlow: plausible but speculative — prefer residual risk over a low-confidence findingProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub tkxkd0159/dbud