Reviews code for logic flaws, edge cases, performance bottlenecks, security vulnerabilities, maintainability concerns, architecture best practices, and adherence to local patterns and CLAUDE.md guidelines. Use when users ask for code review or analysis, including reviewing uncommitted changes, the last local commit, unpushed code, or a specific GitHub pull request.
From kw-pluginnpx claudepluginhub kwiggen/claude-code-plugin --plugin kw-pluginThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.
Review the code against these categories:
Correctness – Logic bugs, incorrect assumptions, unhandled edge cases, race conditions, error handling gaps.
Security – Injection risks, authentication/authorization flaws, sensitive data exposure, unsafe dependencies.
Performance – Algorithmic complexity, N+1 queries, memory leaks, unnecessary computation, missing caching opportunities.
Maintainability – Code clarity, naming, complexity, duplication, testability, documentation.
Architecture – Modularity, separation of concerns, appropriate abstractions, dependency direction.
Testing – Test coverage for new code, test quality, edge case coverage.
Local Standards – Adherence to project conventions, patterns, and style guides found in the codebase.
Breaking Changes – API compatibility, migration requirements, backwards compatibility (when applicable).
CLAUDE.md Compliance – Check changes against CLAUDE.md files in:
Only flag violations explicitly stated in CLAUDE.md. Quote the guideline when flagging.
Brief overview of the change quality and key concerns.
Highlight 1–3 positive aspects worth preserving or replicating.
Organize findings by severity (only report issues with confidence ≥50):
For each finding include:
src/auth.ts:42)Confidence scale:
(Optional) Issues spotted that predate this change – for awareness only.
Prioritized action items for the author.
Avoid false positives by NOT flagging:
Adjust review intensity based on change scope:
WRONG — vague finding:
🟠 Major — This function could have issues with error handling.
CORRECT — actionable finding with evidence:
🟠 Major (82%)
src/api/users.ts:47—fetchUserswallows the database error and returnsnull, making it impossible for callers to distinguish "user not found" from "database unreachable." Return aResult<User, DbError>or rethrow with context.
WRONG — flagging pre-existing code outside the diff:
🟡 Minor — The
loggermodule on line 12 usesconsole.loginstead of a structured logger. (Line 12 was not modified in this change.)
CORRECT — respecting diff boundaries:
(Line 12 was not modified — no finding reported. If important, noted under "Pre-existing Issues Worth Noting.")
Before presenting a review, verify:
file:line reference