visual-design-principles/skills/craftsmanship-polish/SKILL.md
This skill should be used when the user is polishing UI details, optimizing images, implementing shadows or elevation systems, ensuring pixel-perfect alignment, defining border-radius systems, adding micro-interactions or transitions, handling loading/empty/error states, or reducing Cumulative Layout Shift (CLS). Covers VisAWI Craftsmanship facet, retina-ready images, layered shadows, consistent border-radius, transition timing, skeleton screens, and layout stability.
npx skillsauth add oborchers/fractional-cto craftsmanship-polishInstall 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.
Craftsmanship is the strongest single correlate with perceived visual quality in the VisAWI model (Moshagen & Thielsch, 2010). Users cannot articulate why a polished interface feels trustworthy, but they punish sloppiness instantly. Every blurry image, inconsistent radius, and missing hover state erodes credibility.
Enforce the >90% grid alignment rule from the layout-spatial-structure skill. Misalignment of even 1px between adjacent elements is visible at retina resolution.
Debug technique: Add outline: 1px solid rgba(255,0,0,0.3) to all elements temporarily. Misaligned edges become obvious.
| Rule | Requirement |
|------|-------------|
| Resolution | All images must be >=2x rendered resolution (e.g., 800px image for a 400px container) |
| Format priority | AVIF > WebP > JPEG (use <picture> with fallbacks) |
| Hero image budget | <=300KB after compression |
| Lazy loading | All images below the fold use loading="lazy" |
| Aspect ratio | Always specify width and height attributes to prevent CLS |
Use layered box-shadows for realistic depth. Single-layer shadows look flat and artificial. Define exactly 5 levels and use them consistently.
| Level | Name | Use Case | Box-Shadow |
|-------|------|----------|-----------|
| 0 | Flat | Inline elements, flush cards | none |
| 1 | Card | Cards, tiles, raised surfaces | 0 1px 2px rgba(0,0,0,0.06), 0 1px 3px rgba(0,0,0,0.1) |
| 2 | Dropdown | Dropdowns, popovers, tooltips | 0 4px 6px rgba(0,0,0,0.07), 0 2px 4px rgba(0,0,0,0.06) |
| 3 | Modal | Modals, dialogs, drawers | 0 10px 15px rgba(0,0,0,0.1), 0 4px 6px rgba(0,0,0,0.05) |
| 4 | Popover | Floating toolbars, command palettes | 0 20px 25px rgba(0,0,0,0.1), 0 8px 10px rgba(0,0,0,0.04) |
Rule: Higher elevation = larger offset + larger blur + lower opacity. Never use a single heavy shadow.
Define 3-4 radius values. Use them everywhere. Never invent ad-hoc values.
| Token | Value | Use |
|-------|-------|-----|
| --radius-sm | 4px | Badges, tags, inline code |
| --radius-md | 8px | Cards, inputs, buttons |
| --radius-lg | 12px | Modals, large containers |
| --radius-full | 9999px | Avatars, pills, toggles |
Nested radius rule: When an element with border-radius contains a child with border-radius, the inner radius = outer radius - padding. A card with border-radius: 12px and padding: 8px gives children border-radius: 4px.
Every interactive element must have visible hover, focus, and active states.
| State | Implementation |
|-------|----------------|
| Hover | Color shift, subtle scale, or shadow lift |
| Focus | Visible focus ring (2px solid, offset 2px) — see accessibility-inclusive-design for full focus rules |
| Active | Slight scale-down (transform: scale(0.98)) for tactile feedback |
For transition timing, easing, and prefers-reduced-motion rules, see the visual-interest-expression skill which owns motion design guidelines.
Use a single icon library per project. Mix outlined and filled icons deliberately: outlined for navigation, filled for active/selected states. Maintain consistent stroke weight (1.5px or 2px) and size (20px or 24px grid). Never mix icon sets from different libraries.
Skeleton screens beat spinners for loads of 1.5-10 seconds. Match the skeleton to actual content shape. Use a left-to-right shimmer animation at a 1.5s cycle (Bill Chung research: perceived as faster than pulsing).
Empty states must include: illustration or icon + heading + description + primary CTA. Never show a blank page.
Error states must include: what went wrong + what the user can do + a retry action.
Target CLS < 0.1 (Google Core Web Vitals "good" threshold).
| Cause | Fix |
|-------|-----|
| Images without dimensions | Always set width and height attributes |
| Web fonts causing FOUT | Apply font-display strategy (see typography skill for web font loading rules) |
| Dynamic content injected above fold | Reserve space with min-height or use content-visibility: auto |
| Ads or embeds without reserved space | Set explicit container dimensions before content loads |
| Anti-Pattern | Why It Fails | Fix |
|-------------|-------------|-----|
| Pixelated or blurry images | Signals amateur quality | Serve >=2x resolution in AVIF/WebP |
| Single heavy box-shadow | Looks like a drop shadow from 2010 | Use layered shadows with multiple values |
| Inconsistent border-radius (4px here, 6px there, 10px elsewhere) | Subtle discord that feels "off" | Define 3-4 tokens, use them everywhere |
| No hover or focus states | Interactive elements feel dead | Add transition on every clickable element |
| Flash of unstyled text (FOUT) | Layout jumps, text reflows | Apply web font loading rules (see typography skill) |
| Spinners for everything | No spatial context during loading | Use skeleton screens matching content shape |
Working implementations in examples/:
examples/shadow-system-and-states.md — Complete elevation system with layered shadows, skeleton screen implementation, and empty state component in CSS/Tailwind/ReactWhen reviewing or building for craftsmanship:
layout-spatial-structure skill)width and height attributesvisual-interest-expression skill for timing and easing)typography skill rules (font-display, preloading)tools
This skill should be used when the user invokes any /plan-* command from the planning-tools plugin (/plan-context, /plan-master, /plan-open-questions, /plan-verify, /plan-tick, /plan-progress, /plan-delete), asks how Claude Code's plan files work, asks where plans are stored, asks to author or audit a multi-phase master planning document, asks how to walk through a plan's Open Questions interactively, asks how to write progress entries, or mentions ~/.claude/plans/ or .claude/planning-tools.local.md. Provides the index of planning-tools commands, the master-plan workflow lifecycle, the v0.3.0+ list-shape mandate (phases and questions as headings + bulleted scope items, never tables), the v0.3.2+ plain-bullet shape (no `- [ ]` checkboxes — heading emoji is the sole tick signal), the progress-entry methodology, and the mechanics of Claude Code's plan-mode file storage.
testing
This skill should be used by the plan-verifier agent and the /plan-verify command to audit a drafted master plan against a fixed checklist. Covers universal-core completeness, the v0.3.0+ no-tables-for-phases-or-questions rule, trigger-based section-coverage gaps, phase actionability (heading + per-phase TL;DR + bulleted scope + exit criteria), the v0.3.1+ per-phase TL;DR requirement, the v0.3.2+ plain-bullet scope shape (legacy `- [ ]`/`- [x]` accepted silently), the v0.3.3+ context-block shape (plan-level `**TL;DR:**` + bulleted metadata, legacy `>` blockquote accepted silently), integer phase numbering enforcement, dependency traceability, citation resolution, callout/evidence convention compliance, Open Questions placement, and the one-PR-per-master-plan rule. Single-owner of the audit checklist.
tools
This skill should be used when authoring, reviewing, or modifying a multi-phase master planning document via the planning-tools plugin (especially the /plan-master and /plan-verify commands). Codifies the universal core sections, trigger-based optional sections, integer-only phase numbering, Open Questions placement, one-PR-per-plan rule, status conventions, evidence attribution, callouts, cross-reference formats, the v0.3.0 list-shape mandate (phases and questions are heading + bulleted list, never markdown tables), the v0.3.1 per-phase TL;DR requirement (1–3 sentence what/why summary under each phase heading for glance-ability), the v0.3.2 plain-bullet scope shape (`- <action>` items, no `- [ ]` checkboxes — the phase status emoji is the sole tick signal), and the v0.3.3 context-block shape (a plan-level `**TL;DR:**` + a bulleted metadata list instead of a `>` blockquote; legacy blockquote blocks accepted silently). Project-agnostic — no ticket-prefix or plan-type taxonomy.
testing
This skill should be used when the user is adjusting spacing, padding, margins, content density, section gaps, vertical rhythm, or separation between elements. Also applies when reviewing whether a design feels cramped or too sparse, choosing between borders and whitespace for separation, or defining a spacing system. Covers the 4px/8px spacing system, macro vs micro whitespace, content density spectrum, separation techniques (whitespace > background shifts > borders), and vertical rhythm.