dot_claude/skills/ui-design-standards/SKILL.md
UI design quality standards and principles for frontend implementation and code review. Use when (1) implementing UI from design specs or mockups, (2) reviewing frontend/UI code, (3) creating new UI components, (4) building user interfaces for web or mobile apps. Complements frontend-design skills with quality enforcement.
npx skillsauth add paveg/dots ui-design-standardsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Quality standards for implementing and reviewing user interfaces. Apply these principles regardless of framework (React, Vue, SwiftUI, Flutter, etc.).
Match design specifications exactly:
Rule: Do not introduce new UI elements or redesign. Follow the design precisely.
Apply OOP principles to UI development:
// Good: Reusable, props-driven, single responsibility
<Button variant="primary" size="lg">Submit</Button>
// Bad: One-off, hardcoded, mixed concerns
<button style="background: #3b82f6; padding: 12px 24px;">Submit</button>
Use a single global theme file for all design tokens:
theme/
├── colors.ts # Color palette
├── typography.ts # Font styles
├── spacing.ts # Spacing scale
├── shadows.ts # Shadow definitions
└── index.ts # Unified export
Required tokens:
Rule: No hardcoded styles inside components. All values from theme.
UI must be fully functional:
When assets are missing (icons, images, avatars, illustrations):
Before marking UI implementation complete:
When reviewing UI code:
| Area | Check | |------|-------| | Visual | Does it match the design? | | Theme | Are all values from theme system? | | Components | Reusable and properly abstracted? | | States | All interaction states handled? | | Accessibility | Proper semantics and ARIA? | | Performance | No unnecessary re-renders? | | Hardcoding | Any magic numbers or colors? |
// Flag: Hardcoded color
color: '#3b82f6' // Should use theme.colors.primary
// Flag: Magic number
padding: 13px // Should use spacing scale
// Flag: Inline styles for reusable patterns
style={{ display: 'flex', gap: 8 }} // Should be component/class
// Flag: Missing states
<Button>Submit</Button> // Where is disabled/loading state?
| Level | Description | |-------|-------------| | A | Pixel-perfect, fully themed, all states, accessible | | B | Visually accurate, mostly themed, core states work | | C | Functional but visual inconsistencies, some hardcoding | | D | Major visual deviations, significant hardcoding |
Target: Level A for production, Level B minimum for review approval.
development
Iteratively improve agent-facing text instructions (skills, slash commands, task prompts, CLAUDE.md sections, code-generation prompts) by having a bias-free executor run them and evaluating from both sides (executor self-report + caller-side metrics). Repeat until improvement plateaus. Use immediately after creating or significantly revising a skill/prompt, or when unexpected agent behavior is suspected to stem from ambiguous instructions.
development
Create viral X/Twitter posts based on the official X algorithm (Phoenix/Grok). Generates and improves posts optimized for maximum engagement. Use when (1) creating X posts for products, services, or information, (2) improving existing post drafts, (3) designing thread structures for long content.
testing
End-to-end workflow for finding content, app, service, or product opportunities where search demand is high but quality supply is low (trend arbitrage). Use when: finding content gaps, keyword opportunities, niche research, analyzing whether a topic or idea is worth pursuing, or competitive gap analysis.
development
Conduct an attacker-perspective security review of a codebase, then ship the fixes as multiple non-conflicting pull requests in parallel using subagents and git worktrees. Verifies findings to filter false positives, plans fixes via file-occupation analysis to guarantee no merge conflicts, dispatches each fix to its own TDD-driven subagent in an isolated worktree, then pushes and opens one PR per fix. Use this whenever the user asks for a security audit, pentest, vulnerability review, attack surface analysis, or wants to "find vulnerabilities" / "review for security issues" in their own (or otherwise authorized) project, even if they don't say the word "pentest". Also use when the user already has a list of independent fixes (security or otherwise) and wants them shipped as parallel non-conflicting PRs without manually managing worktrees.