Stats
Actions
Tags
From skills
Complete multi-agent code review EXCLUSIVELY of the changes between the current branch and a base branch (default main, fallback master/develop) — not an audit of the entire repo, but a deep review only of the diff-touched areas. Spawns parallel subagents for code quality, architecture, security (OWASP/CWE/CVSS), SEO, privacy/legal, UI/UX (WCAG), and performance, and consolidates their reports into a complete Findings.md with P0–P4 prioritization and reasoned recommendations. Optionally (`--apply-fixes`) applies clear fixes directly afterwards and escalates design decisions to the user. Use this skill for "review this branch", "PR review", "diff review", "branch review", "review my PR", "code review for branch", "review what changed", "review and fix", "fix PR issues", or German equivalents "review meinen branch", "review die änderungen", "schau dir den branch an", "PR-Review", whenever a PR link, a branch range, or a diff is posted for review — even without the explicit word "review" if context is clear. DO NOT trigger for an audit of the entire project without branch context — use full-project-review for that.
How this skill is triggered — by the user, by Claude, or both
Slash command
/skills:branch-review [base-branch] [--apply-fixes][base-branch] [--apply-fixes]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
**The diff is the only anchor.** This review does NOT inspect the whole project — it inspects the changes between `<base>` and `HEAD`. If this skill triggers without a diff: abort and point to `full-project-review`.
The diff is the only anchor. This review does NOT inspect the whole project — it inspects the changes between <base> and HEAD. If this skill triggers without a diff: abort and point to full-project-review.
Allowed reads:
Diff trigger: <file:line>.Forbidden:
You are the orchestrator of a multi-agent review. You yourself write NO review content — you plan, delegate to subagents (Task tool), wait for their reports, and consolidate them. Subagents may in turn spawn further subagents when their topic is too large — all sub-subagents inherit the diff discipline above.
Code-review depth: only the changes between the current branch and the base branch (git diff <base>...<HEAD>).
Determine the base branch (in this order):
main, fallback master, fallback develop.If the diff is empty: STOP. Report back to the user that the branch is identical to base, and suggest full-project-review instead. Do not silently expand scope.
Context scope for security/legal/performance: primarily the diff. If a change has system-wide implications (e.g. new auth middleware, modified CSP), the corresponding subagent MAY and SHOULD also inspect affected places outside the diff — and mark them in the finding ("Diff trigger: …, also affects …").
Live site (for SEO/legal/UX): only when the diff touches user-facing content AND a live URL is known or obtainable. Otherwise skip and note in the coverage report.
Findings language: the language of the user request (default). Code examples in their original language.
Jurisdiction (for privacy/legal): derive from user context / project README (server location, target market). If unclear, ask the user — default GDPR/EU.
Before spawning subagents: detect the tech stack from the repo (package.json, composer.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile, etc.). Pass this info to each subagent so it applies the right conventions and tool checks (linter configs, framework best practices, language-specific security patterns). When project-specific convention skills are available in the plugin set (e.g. Vue, Nuxt, Shopware skills), mention them to the relevant subagent.
npm audit, composer audit, pip-audit, gh dependabot, etc.), headers (CSP/HSTS/COOP/COEP), rate limiting, logging. Per finding: CWE reference, OWASP category, CVSS estimate, PoC sketch.If a subagent sees no relevance in the diff for its scope, it still delivers a report (may be short) with the reason it found nothing — no silence.
Path: store in the outputs/workspace folder (outputs/Findings.md or equivalent).
### [P{0-4}] [Category] Short title
- **Location:** path:line / URL
- **Diff reference:** which file/line from the diff triggered it
- **Description:** what is the problem?
- **Justification / why critical:** impact + exploitation/occurrence scenario. Even for P3/P4 a justification is mandatory ("why mentioned at all").
- **Reference:** CWE/OWASP/WCAG/GDPR article/best-practice source
- **Recommendation:** concrete fix (code snippet when useful)
- **Why better:** technical/legal justification of the recommendation
- **Effort:** S / M / L (rough estimate)
- **Status:** verified | hypothesis — verification needed
Every spawned subagent receives EXACTLY this structure. The orchestrator fills the placeholders — omit nothing, paraphrase nothing.
ROLE: <Code-Quality | Architecture | Security | SEO | Legal | UI/UX | Performance> Agent
DIFF DISCIPLINE (NON-NEGOTIABLE):
- The anchor is the diff embedded below. Findings ONLY on code touched by the diff OR demonstrably affected by it.
- Forbidden: repo-wide scans, findings on unchanged code, generic best-practice lists without diff reference.
- Allowed system-wide for your role: <fill in per role — see list below>. Mark every system-wide extension in the finding: "Diff trigger: <file:line>".
ALLOWED-FILES (whitelist — these you may read in full):
<output of git diff --name-only, one file per line>
TECH STACK: <detection result>
BASE BRANCH: <base> HEAD SHA: <sha> MERGE BASE: <sha>
DIFF (unified):
<full output of `git diff <base>...<HEAD>` OR a note "see file <path>" if too large>
OBLIGATIONS:
- Completeness within the diff (no omissions, including P3/P4).
- Every finding with required fields per schema (see main skill).
- No hallucinations: inaccessible locations → escalation block, do not guess.
- If your scope is not touched by the diff: short report with reason, no silence.
OUTPUT: Markdown report with findings per schema + coverage note (what was checked, what was not + reason).
System-wide extensions per role (what may be read outside the diff when a diff trigger is demonstrable):
git diff <base>...<HEAD> and git diff --name-only <base>...<HEAD>, record diff statistics. On empty diff, abort and point to full-project-review.--apply-fixes)Default is read-only. The following phase runs after step 8 (verification pass) ONLY if $ARGUMENTS contains the flag --apply-fixes.
This phase applies clear fixes directly to the branch and escalates design decisions to the user. It replaces the former review-and-fix skill.
git status --porcelain empty). Otherwise abort with the note "Please commit or stash first."main/master/develop (no commit on the default branch).Findings.md from the previous phases exists.For every finding in Findings.md, assign one of three categories:
| Category | Criteria | Action |
|---|---|---|
| Confident Fix | Unambiguous bug, obvious correction (e.g. typo in API path, missing guard following an established pattern, stale doc contradicts code, undefined function, DRY violation with a clear extraction target) | patch directly |
| Design Decision | Multiple valid approaches, architectural impact, scope question, depth of security hardening | do not patch, escalate |
| Out of Auto-Fix Scope | Test coverage, linter style, refactoring nice-to-have, performance tuning without a clear target | list only, neither patch nor escalate |
No multi-classification. When uncertain → Design Decision (escalating is always cheaper than silently fixing wrong).
Per confident fix:
git show <branch>:<file>, make sure the location and the problem exist as the finding claims. On mismatch: return the finding to Findings.md as hypothesis and do not patch.git add <file> && git commit -m "fix(<area>): <one-line>" with a reference to the finding ID (e.g. [F-014]).Related confident fixes can be combined in one commit when they logically belong together (e.g. the same stale doc in three places).
For each design-decision entry, send a table to the user in this format:
### N. <Title>
<One-sentence problem description>
Source: <subagent / finding ID>
| Option | Pro | Con |
|--------|-----|-----|
| A. <Variant 1> | … | … |
| B. <Variant 2> | … | … |
| C. <Variant 3> | … | … |
Recommendation: <A | B | C> — <one-sentence justification>
At the end: "Which options should I implement? (e.g. 1.B, 2.A, 3.C)"
After the user's reply: implement the options, one commit per affected concern, then git push.
git push to the PR branch.git push -u origin <branch>.main/master/develop.After the auto-fix phase, append a new section ## Auto-Fix Summary to Findings.md:
This keeps it traceable what the skill changed in the code — and what the user still needs to decide.
--apply-fixes.npx claudepluginhub lx-wnk/claude-marketplace --plugin skillsProvides 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.