From review-toolkit
Review current branch changes in isolation. Output starts with LGTM verdict — if no LGTM, the code is not ready to merge. IMPORTANT — always pass all flags you already know from context (target branch, project type, ticket, etc.). Do not rely on auto-detection when the answer is known. Pass --target to set which branch the changes are going INTO. Pass --ticket with a URL or ID to validate against requirements.
How this skill is triggered — by the user, by Claude, or both
Slash command
/review-toolkit:branch-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Important**: If the current directory is not a git repository, ask the user where the target repository is located before proceeding.
Important: If the current directory is not a git repository, ask the user where the target repository is located before proceeding.
CRITICAL: NEVER run git checkout, git switch, or any command that changes the current branch. You MUST stay on whatever branch is active when you start. All analysis must use git diff, git log, and file reads — never branch switching.
Parse $ARGUMENTS for:
~/git/github.com/org/repo or ../my-worktree). If provided, ALL git and file operations must run inside this directory--target the branch this PR is merging INTO (e.g. next, develop, main). This is the most important parameter for determining the correct diff scope--nitpick flag for pedantic mode--type project type (e.g. go, node, python, rust) — skips auto-detection--exclude additional exclude patterns, comma-separated (e.g. docs/,*.gen.go)--ticket ticket reference — URL (GitHub issue, Jira, Linear, Notion, etc.) or ID (e.g. #123, PROJ-456). When provided, the review includes a Ticket Compliance section that validates whether the changes fulfil the ticket requirementsExamples:
/review-branch → auto-detect everything in current directory/review-branch ~/git/github.com/org/repo → review in that directory/review-branch --target next → review changes going into next/review-branch --nitpick → pedantic mode/review-branch --type go --exclude "api/generated/" → Go project, extra excludes/review-branch --ticket https://github.com/org/repo/issues/42 → validate against GitHub issue/review-branch --ticket PROJ-456 → validate against ticket ID (fetched via appropriate tool)/review-branch ~/worktrees/feature --target develop --nitpick --type node → all combined/review-branch --target main --ticket #123 --nitpick → target main, validate against ticket, pedantic modeIf a path argument was provided, use it as the working directory for ALL git and file operations throughout the review. Pass -C <path> to every git command, and use the path as the base for all file reads.
First, record the current branch (you will need it throughout):
# Without path argument:
REVIEW_BRANCH=$(git branch --show-current)
# With path argument:
REVIEW_BRANCH=$(git -C <path> branch --show-current)
All analysis MUST be performed from this branch. Use git diff, git log, git show for comparisons — these do NOT require switching branches.
Determine target branch (the branch this PR is merging INTO):
--target argument provided: use itgh pr view --json baseRefName --jq .baseRefName 2>/dev/null
git rev-parse --abbrev-ref @{upstream} (tracking branch), stripping the remote prefix (e.g. origin/next → next)main, fallback to masterPrint the resolved target branch so the user can verify it is correct (e.g. "Reviewing against target branch: next").
Find the merge base (the point where the current branch diverged from the target):
MERGE_BASE=$(git merge-base $REVIEW_BRANCH <target-branch>)
<if --ticket>
If --ticket is provided, fetch the ticket content BEFORE reviewing the diff:
http:// or https://): use gh CLI for GitHub URLs (e.g. gh issue view <number> --repo <owner/repo>), or WebFetch for other URLs (Jira, Linear, Notion, etc.)#123): use gh issue view 123 in the repository being reviewedPROJ-456): attempt to resolve via web search or ask the user for the full URLExtract from the ticket:
If the ticket cannot be fetched (404, auth required, etc.), warn the user and continue the review without ticket validation.
If --type provided, use it. Otherwise detect the project type (Go, Node, Python, Rust, etc.) and build an exclude list dynamically:
Append any --exclude patterns from arguments.
Run the diff excluding those patterns:
git diff <MERGE_BASE> -- . ':!<pattern1>' ':!<pattern2>' ...
(Note: no HEAD — this compares the working tree against the merge base, capturing all changes including uncommitted ones. The merge base is the point where the current branch diverged from the target branch.)
You are NOT limited to the diff. When the diff alone is not enough to understand the change:
Do whatever is needed to review competently. The diff is the starting point, not the boundary.
Review the diff for:
<if --ticket>
Compare the changes against the ticket requirements:
Ticket compliance issues are blocking (NOT LGTM) when requirements are missing or the implementation contradicts the ticket.
<if --nitpick> Pedantic mode: include style nitpicks, naming suggestions, minor improvements. Leave no stone unturned.
<if not --nitpick> Be direct. If something is fine, don't mention it. Focus on what matters, skip nitpicks.
Start your review with one of:
LGTM is a high bar. It means: no bugs, no security issues, no missing error handling, no logic gaps, no untested paths. The ONLY things allowed to pass with LGTM are cosmetic issues (naming style, minor formatting) — and even those must be listed as "Recommended to fix" in the review. Everything else blocks. When in doubt, do not LGTM.
Then provide the review as free-form text, like a human reviewer would write.
<if --ticket> Include a Ticket Compliance section after the main review with:
End every review with this reminder (verbatim):
Reminder: "Pre-existing" is not a thing. If a problem is flagged in this review, it must be fixed in this PR — no exceptions.
Every issue listed above must have a corresponding test. No matter the severity — bug, logic error, security issue, error handling gap, documentation drift — each one must be covered by a test that fails without the fix and passes with it. Untested fixes are not fixes.
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 lexfrei/ccc --plugin review-toolkit