ss-review
starsforks
How to install ss-review?
bitjaru/styleseed/ss-review
$npx -y skills add bitjaru/styleseed --skill ss-reviewReview UI code for design system compliance, accessibility, and best practices
SKILL.md
| 1 | # UI Design Review |
| 2 | |
| 3 | First resolve the effective rule set from `PRODUCT-PRINCIPLES.md`, `RULESETS.md` or the compiled |
| 4 | grammar, `ADAPTERS.md`, domain/page, optional `PRESETS.md` profile, and `STYLESEED.md`. Review |
| 5 | task fitness and grammar coherence before framework conventions. For non-web artifacts, replace |
| 6 | React/Tailwind-only checks with the active adapter's render/export checks. |
| 7 | |
| 8 | ## When NOT to use |
| 9 | |
| 10 | - For accessibility-only issues → use `/ss-a11y` |
| 11 | - For Nielsen UX heuristics → use `/ss-audit` |
| 12 | - For a quick automated check → use `/ss-lint` |
| 13 | - For non-UI code (data fetching, business rules) |
| 14 | |
| 15 | Review the file: **$ARGUMENTS** |
| 16 | |
| 17 | ## Checklist |
| 18 | |
| 19 | ### 1. Design Token Compliance |
| 20 | - [ ] No hardcoded hex colors (use semantic tokens: `text-foreground`, `bg-brand`, etc.) |
| 21 | - [ ] No hardcoded px spacing in Tailwind (use `p-6` not `p-[24px]`) |
| 22 | - [ ] Shadows use CSS variables (`shadow-[var(--shadow-card)]`) |
| 23 | - [ ] Border radius follows the scale (`rounded-md`, `rounded-lg`, `rounded-2xl`) |
| 24 | |
| 25 | ### 2. Component Conventions |
| 26 | - [ ] Uses `data-slot` attribute |
| 27 | - [ ] Uses `cn()` for className merging |
| 28 | - [ ] Props typed with `React.ComponentProps<>` |
| 29 | - [ ] Supports `className` prop override |
| 30 | - [ ] Named export (not default export for components) |
| 31 | - [ ] No wrapper components that only add a className |
| 32 | |
| 33 | ### 3. Accessibility (a11y) |
| 34 | - [ ] Touch targets >= 44x44px for interactive elements |
| 35 | - [ ] `focus-visible` styles on all interactive elements |
| 36 | - [ ] Proper `aria-*` attributes where needed |
| 37 | - [ ] Color contrast meets WCAG AA (4.5:1 for text, 3:1 for large text) |
| 38 | - [ ] Animations respect `prefers-reduced-motion` |
| 39 | - [ ] Images have `alt` text |
| 40 | - [ ] Form inputs have associated labels |
| 41 | |
| 42 | ### 4. Mobile Best Practices |
| 43 | - [ ] No horizontal overflow |
| 44 | - [ ] Touch-friendly spacing between interactive elements |
| 45 | - [ ] Safe area insets handled for notched devices |
| 46 | - [ ] Text sizes >= 12px for readability |
| 47 | - [ ] Scrollable containers have `-webkit-overflow-scrolling: touch` |
| 48 | |
| 49 | ### 5. Performance |
| 50 | - [ ] No unnecessary re-renders (stable references, memoization where needed) |
| 51 | - [ ] Images are lazy-loaded |
| 52 | - [ ] Heavy components are code-split |
| 53 | |
| 54 | ### 6. Typography |
| 55 | - [ ] Uses the Pretendard/Inter font stack |
| 56 | - [ ] Font sizes from the 14-step scale (10-48px, see CLAUDE.md) |
| 57 | - [ ] Proper font weights (400, 500, 600, 700) |
| 58 | - [ ] Display text (36-48px): `leading-none` + `tracking-[-0.02em]` |
| 59 | - [ ] Heading text (18-24px): `leading-snug` + `tracking-[-0.01em]` |
| 60 | - [ ] Body text (14-17px): `leading-normal` (no custom tracking) |
| 61 | - [ ] Caption uppercase (10-13px): `tracking-[0.05em]` or `tracking-wide` |
| 62 | - [ ] No `line-height: 1.5` on display/heading text (too loose) |
| 63 | |
| 64 | ### 7. Spacing Consistency |
| 65 | - [ ] All spacing values are multiples of 6px (p-1.5, p-3, p-6, etc.) |
| 66 | - [ ] No arbitrary spacing (p-5=20px, gap-3.5=14px are violations) |
| 67 | - [ ] Uses `size-*` shorthand instead of `w-* h-*` |
| 68 | - [ ] Uses `ms-*/me-*` instead of `ml-*/mr-*` (logical properties) |
| 69 | - [ ] Motion transitions use design tokens (`duration-[var(--duration-fast)]`) |
| 70 | |
| 71 | ### 8. Coherence (VISUAL-CRAFT.md §C0 — the "one choice per axis" laws) |
| 72 | > The biggest reason a UI reads as "AI-generated" isn't ugly parts — it's *mixed* |
| 73 | > parts. Check that each axis below uses ONE value system-wide; flag a mix as a real |
| 74 | > issue, not a nitpick. |
| 75 | - [ ] **One radius personality** — sharp (0-4px) OR soft (8-12px) OR pill, applied to every card/button/input/modal. No mixing (e.g. a `rounded-none` panel with `rounded-full` buttons). |
| 76 | - [ ] **One identifiable primary action** plus only the selected grammar's stable semantic, |
| 77 | categorical, or brand roles — no competing decorative emphasis hues. |
| 78 | - [ ] **No emoji as UI icons** (🚗🧺⭐ as list/nav/status/category markers) — they inject many uncontrolled hues; use one line-icon set in `currentColor`. |
| 79 | - [ ] **Status color = severity, not decoration** — a normal/OK/"보통" state is neutral grey (not colored); color marks only the minority of rows that need attention; same value → same color. |
| 80 | - [ ] **No decorative hues** — favorite stars, category dots, avatars use the accent or grey, not a new color each. |
| 81 | - [ ] **One shadow language** — same light direction, same scale/tint; not some black + some tinted, some up-lit + some down-lit. |
| 82 | - [ ] **One icon family / fill mode / stroke weight** across the file. |
| 83 | - [ ] **Nested-radius law** — an element inside a rounded container uses `inner = outer − padding`, not the same radius (which bulges). |
| 84 | - [ ] **Consistent control heights** — buttons, inputs, selects share a height set (e.g. 40px). |
| 85 | - [ ] Errors/states never rely on color alone (icon + text too). |
| 86 | |
| 87 | ## Output Format |
| 88 | |
| 89 | Provide: |
| 90 | 1. **Score**: Pass / Needs Improvement / Fail |
| 91 | 2. **Issues**: List each violation with file:line reference |
| 92 | 3. **Fixes**: Concrete code changes for each issue |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
