From design-kit
Use when reviewing code for quality, design system compliance, build correctness, and test coverage. Triggers on: "Review this code", "code review", "check code quality", "/code-review". Runs a structured 3-iteration loop until clean.
How this skill is triggered — by the user, by Claude, or both
Slash command
/design-kit:code-reviewerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Structured code review with severity levels, build verification, test checks, and PR comment resolution. Runs up to 3 iterations until clean.
Structured code review with severity levels, build verification, test checks, and PR comment resolution. Runs up to 3 iterations until clean.
Reads coding rules from the repo's CODING_GUIDELINES.md and REVIEW.md (paths configured in design-kit.config.json → contextPaths.codingRules). These files are scaffolded by /design-kit:init.
for iteration in 1..3:
Phase 0: Branch sync
Phase 1: Code review
Phase 2: Build checks
Phase 3: Tests
Phase 4: PR comment resolution
if zero issues in all phases → break early
After 3 iterations: document remaining issues in summary report
git fetch origin main
If behind main:
git rebase origin/main
If already up to date, skip.
git diff --name-only origin/main...HEADCODING_GUIDELINES.md and REVIEW.md to load project-specific rules before reviewing.app/ paths, check against the severity levels below..github/, scripts/, config files, CSS token files.| Code | Rule |
|---|---|
| C01 | Design system import violation — importing DS internals in consumer code |
| C02 | Hardcoded colors — hex values, raw color functions, framework color utilities where semantic tokens should be used |
| C03 | Raw HTML elements where a DS component equivalent exists (e.g. <button>, <input>, <select>, <dialog>) |
| C04 | any type or @ts-ignore suppression |
| C05 | Security — hardcoded secrets, unsanitized dangerous HTML injection |
| C06 | Committed binary or generated files that should not be in source |
| C07 | DS component API misuse — wrong prop names or values per the component's documented API |
| C08 | Inline style objects where utility classes exist |
| C09 | Bulk violations — 3+ DS violations in a single file → flag for full rewrite |
| Code | Rule |
|---|---|
| I01 | Missing dark mode — custom color without a dark-mode pair |
| I02 | Missing accessible name — icon-only interactive element without aria-label |
| I03 | File over 800 lines — should be split into smaller components |
| I04 | Missing class composition utility — manual string concatenation for dynamic class names |
| I05 | Commented-out code blocks |
| I06 | Wrong import order — should be: DS → framework → external → internal → types |
| I07 | Props interface not defined before the component function |
| I08 | Structural DS violation — styled raw element used where a DS composite exists (e.g. styled <div> as card, <span> as badge) |
| I09 | Missing DS composite — custom implementation where an equivalent DS component exists |
| I10 | Missing internationalization — user-facing text not wrapped in the project's i18n utility |
| I11 | Missing translations — new string added in one locale but not others |
| Code | Rule |
|---|---|
| A01 | File over 300 lines — consider splitting |
| A02 | Naming conventions — component or file name doesn't match project conventions |
| A03 | Missing "why" comment — non-obvious logic without explanation |
| A04 | Duplicated pattern — pattern exists elsewhere in the codebase; consider extracting |
/code-review: Report all findings. Do not auto-fix unless the user asks.When reviewing files, check against any DS component mapping documented in the repo (e.g. a ds-component-mapping.md file or equivalent). Look for:
Run the project's build and lint commands sequentially. Fix failures before proceeding.
Typical commands (adapt to the project's package.json scripts):
npm run build # TypeScript compilation
npm run lint # ESLint / linter
If the project has a DS enforcement scanner, run it first:
npm run review:ds # if available
If any check fails:
Run the project's test suite. Scope to affected areas when only one component or feature changed.
Skip if no PR exists.
If a PR exists:
gh api repos/{owner}/{repo}/pulls/{number}/commentsOutput this after the loop completes:
## Code Review Summary
**Branch:** <branch-name>
**Iterations:** N of 3
**Status:** PASS / ISSUES_REMAINING
### Per-Iteration Results
| Iteration | Review Findings | Build | Tests | PR Comments | Status |
|-----------|----------------|-------|-------|-------------|--------|
| 1 | N fixed | pass/fail | N fixed | N resolved | ... |
| 2 | N fixed | pass | N fixed | N resolved | ... |
| 3 | 0 | pass | 0 | 0 | CLEAN |
### Remaining Issues (if any)
- ...
bg-red-50 dark:bg-red-900/20)<div>, <section>, <main>, <p>, <h1>–<h6>) — not DS componentsstyle={{}} for dynamic computed values (percentage widths, grid templates from data)npx claudepluginhub anindhitavidia/design-agent-kit --plugin design-kitCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.