Perform a meticulous final pass to catch the small details that separate good work from great work.
Design System Discovery
Before polishing, understand the system you are polishing toward:
- Find the design system: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
- Note the conventions: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
- Identify drift: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
Pre-Polish Assessment
Understand the current state and goals:
Review completeness:
- Is it functionally complete?
- Are there known issues to preserve (mark with TODOs)?
- What's the quality bar? (MVP vs flagship feature?)
- When does it ship? (How much time for polish?)
Identify polish areas:
- Visual inconsistencies
- Spacing and alignment issues
- Interaction state gaps
- Copy inconsistencies
- Edge cases and error states
- Loading and transition smoothness
CRITICAL: Polish is the last step, not the first. Don't polish work that's not functionally complete.
Polish Systematically
Work through these dimensions methodically:
Visual Alignment & Spacing
- Pixel-perfect alignment: Everything lines up to grid
- Consistent spacing: All gaps use spacing scale (no random 13px gaps)
- Optical alignment: Adjust for visual weight (icons may need offset for optical centering)
- Responsive consistency: Spacing and alignment work at all breakpoints
- Grid adherence: Elements snap to baseline grid
Check:
- Enable grid overlay and verify alignment
- Check spacing with browser inspector
- Test at multiple viewport sizes
- Look for elements that "feel" off
Typography Refinement
- Hierarchy consistency: Same elements use same sizes/weights throughout
- Line length: 45-75 characters for body text
- Line height: Appropriate for font size and context
- Widows & orphans: No single words on last line
- Hyphenation: Appropriate for language and column width
- Kerning: Adjust letter spacing where needed (especially headlines)
- Font loading: No FOUT/FOIT flashes
Color & Contrast
- Contrast ratios: All text meets WCAG standards
- Consistent token usage: No hard-coded colors, all use design tokens
- Theme consistency: Works in all theme variants
- Color meaning: Same colors mean same things throughout
- Accessible focus: Focus indicators visible with sufficient contrast
- Tinted neutrals: No pure gray or pure black—add subtle color tint (0.01 chroma)
- Gray on color: Never put gray text on colored backgrounds—use a shade of that color or transparency
Interaction States
Every interactive element needs all states:
- Default: Resting state
- Hover: Subtle feedback (color, scale, shadow)
- Focus: Keyboard focus indicator (never remove without replacement)
- Active: Click/tap feedback
- Disabled: Clearly non-interactive
- Loading: Async action feedback
- Error: Validation or error state
- Success: Successful completion
Missing states create confusion and broken experiences.
Micro-interactions & Transitions
- Smooth transitions: All state changes animated appropriately (150-300ms)
- Consistent easing: Use ease-out-quart/quint/expo for natural deceleration. Never bounce or elastic—they feel dated.
- No jank: 60fps animations, only animate transform and opacity
- Appropriate motion: Motion serves purpose, not decoration
- Reduced motion: Respects
prefers-reduced-motion
Content & Copy
- Consistent terminology: Same things called same names throughout
- Consistent capitalization: Title Case vs Sentence case applied consistently
- Grammar & spelling: No typos
- Appropriate length: Not too wordy, not too terse
- Punctuation consistency: Periods on sentences, not on labels (unless all labels have them)
Icons & Images
- Consistent style: All icons from same family or matching style
- Appropriate sizing: Icons sized consistently for context
- Proper alignment: Icons align with adjacent text optically
- Alt text: All images have descriptive alt text
- Loading states: Images don't cause layout shift, proper aspect ratios
- Retina support: 2x assets for high-DPI screens
Forms & Inputs
- Label consistency: All inputs properly labeled
- Required indicators: Clear and consistent
- Error messages: Helpful and consistent
- Tab order: Logical keyboard navigation
- Auto-focus: Appropriate (don't overuse)
- Validation timing: Consistent (on blur vs on submit)
Edge Cases & Error States
- Loading states: All async actions have loading feedback
- Empty states: Helpful empty states, not just blank space
- Error states: Clear error messages with recovery paths
- Success states: Confirmation of successful actions
- Long content: Handles very long names, descriptions, etc.
- No content: Handles missing data gracefully
- Offline: Appropriate offline handling (if applicable)
Responsiveness
- All breakpoints: Test mobile, tablet, desktop
- Touch targets: 44x44px minimum on touch devices
- Readable text: No text smaller than 14px on mobile
- No horizontal scroll: Content fits viewport
- Appropriate reflow: Content adapts logically
Performance
- Fast initial load: Optimize critical path
- No layout shift: Elements don't jump after load (CLS)
- Smooth interactions: No lag or jank
- Optimized images: Appropriate formats and sizes
- Lazy loading: Off-screen content loads lazily
Code Quality
- Remove console logs: No debug logging in production
- Remove commented code: Clean up dead code
- Remove unused imports: Clean up unused dependencies
- Consistent naming: Variables and functions follow conventions
- Type safety: No TypeScript
any or ignored errors
- Accessibility: Proper ARIA labels and semantic HTML
Polish Checklist
Go through systematically:
IMPORTANT: Polish is about details. Zoom in. Squint at it. Use it yourself. The little things add up.
NEVER:
- Polish before it's functionally complete
- Spend hours on polish if it ships in 30 minutes (triage)
- Introduce bugs while polishing (test thoroughly)
- Ignore systematic issues (if spacing is off everywhere, fix the system)
- Perfect one thing while leaving others rough (consistent quality level)
- Create new one-off components when design system equivalents exist
- Hard-code values that should use design tokens
Final Verification
Before marking as done:
- Use it yourself: Actually interact with the feature
- Test on real devices: Not just browser DevTools
- Ask someone else to review: Fresh eyes catch things
- Compare to design: Match intended design
- Check all states: Don't just test happy path
Clean Up
After polishing, ensure code quality:
- Replace custom implementations: If the design system provides a component you reimplemented, switch to the shared version.
- Remove orphaned code: Delete unused styles, components, or files made obsolete by polish.
- Consolidate tokens: If you introduced new values, check whether they should be tokens.
- Verify DRYness: Look for duplication introduced during polishing and consolidate.
Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
Related
layout — fix the underlying spacing scale, hierarchy, and grid first when the composition itself is what feels wrong; polish refines, it does not restructure.
1---
2name: polish
3description: Runs the last pass over a functionally complete feature — pixel alignment, interaction and loading states, empty and error states, copy consistency, transition smoothness, and micro-details measured against the design system. Requires the work to be finished first; it refines, it never restructures. Use when the user asks for polish, finishing touches, a pre-launch review, or wants to go from good to great. To fix the underlying composition instead, use `layout`.
4user-invocable: true
5argument-hint: "[target]"
6metadata:
7 version: "2.1.2"
8 tags: "polish, ui, quality"
9 source: https://github.com/pbakaus/impeccable/blob/main/skill/reference/polish.md
10 upstream_version: skill-v2.1.1
11 upstream_latest: skill-v3.5.0
12 last_synced: "2026-06-12"
13 license: Apache-2.0
14---
15
16Perform a meticulous final pass to catch the small details that separate good work from great work.
17
18## Design System Discovery
19
20Before polishing, understand the system you are polishing toward:
21
221. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
232. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
243. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
25
26If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
27
28## Pre-Polish Assessment
29
30Understand the current state and goals:
31
321. **Review completeness**:
33 - Is it functionally complete?
34 - Are there known issues to preserve (mark with TODOs)?
35 - What's the quality bar? (MVP vs flagship feature?)
36 - When does it ship? (How much time for polish?)
37
382. **Identify polish areas**:
39 - Visual inconsistencies
40 - Spacing and alignment issues
41 - Interaction state gaps
42 - Copy inconsistencies
43 - Edge cases and error states
44 - Loading and transition smoothness
45
46**CRITICAL**: Polish is the last step, not the first. Don't polish work that's not functionally complete.
47
48## Polish Systematically
49
50Work through these dimensions methodically:
51
52### Visual Alignment & Spacing
53
54- **Pixel-perfect alignment**: Everything lines up to grid
55- **Consistent spacing**: All gaps use spacing scale (no random 13px gaps)
56- **Optical alignment**: Adjust for visual weight (icons may need offset for optical centering)
57- **Responsive consistency**: Spacing and alignment work at all breakpoints
58- **Grid adherence**: Elements snap to baseline grid
59
60**Check**:
61
62- Enable grid overlay and verify alignment
63- Check spacing with browser inspector
64- Test at multiple viewport sizes
65- Look for elements that "feel" off
66
67### Typography Refinement
68
69- **Hierarchy consistency**: Same elements use same sizes/weights throughout
70- **Line length**: 45-75 characters for body text
71- **Line height**: Appropriate for font size and context
72- **Widows & orphans**: No single words on last line
73- **Hyphenation**: Appropriate for language and column width
74- **Kerning**: Adjust letter spacing where needed (especially headlines)
75- **Font loading**: No FOUT/FOIT flashes
76
77### Color & Contrast
78
79- **Contrast ratios**: All text meets WCAG standards
80- **Consistent token usage**: No hard-coded colors, all use design tokens
81- **Theme consistency**: Works in all theme variants
82- **Color meaning**: Same colors mean same things throughout
83- **Accessible focus**: Focus indicators visible with sufficient contrast
84- **Tinted neutrals**: No pure gray or pure black—add subtle color tint (0.01 chroma)
85- **Gray on color**: Never put gray text on colored backgrounds—use a shade of that color or transparency
86
87### Interaction States
88
89Every interactive element needs all states:
90
91- **Default**: Resting state
92- **Hover**: Subtle feedback (color, scale, shadow)
93- **Focus**: Keyboard focus indicator (never remove without replacement)
94- **Active**: Click/tap feedback
95- **Disabled**: Clearly non-interactive
96- **Loading**: Async action feedback
97- **Error**: Validation or error state
98- **Success**: Successful completion
99
100**Missing states create confusion and broken experiences**.
101
102### Micro-interactions & Transitions
103
104- **Smooth transitions**: All state changes animated appropriately (150-300ms)
105- **Consistent easing**: Use ease-out-quart/quint/expo for natural deceleration. Never bounce or elastic—they feel dated.
106- **No jank**: 60fps animations, only animate transform and opacity
107- **Appropriate motion**: Motion serves purpose, not decoration
108- **Reduced motion**: Respects `prefers-reduced-motion`
109
110### Content & Copy
111
112- **Consistent terminology**: Same things called same names throughout
113- **Consistent capitalization**: Title Case vs Sentence case applied consistently
114- **Grammar & spelling**: No typos
115- **Appropriate length**: Not too wordy, not too terse
116- **Punctuation consistency**: Periods on sentences, not on labels (unless all labels have them)
117
118### Icons & Images
119
120- **Consistent style**: All icons from same family or matching style
121- **Appropriate sizing**: Icons sized consistently for context
122- **Proper alignment**: Icons align with adjacent text optically
123- **Alt text**: All images have descriptive alt text
124- **Loading states**: Images don't cause layout shift, proper aspect ratios
125- **Retina support**: 2x assets for high-DPI screens
126
127### Forms & Inputs
128
129- **Label consistency**: All inputs properly labeled
130- **Required indicators**: Clear and consistent
131- **Error messages**: Helpful and consistent
132- **Tab order**: Logical keyboard navigation
133- **Auto-focus**: Appropriate (don't overuse)
134- **Validation timing**: Consistent (on blur vs on submit)
135
136### Edge Cases & Error States
137
138- **Loading states**: All async actions have loading feedback
139- **Empty states**: Helpful empty states, not just blank space
140- **Error states**: Clear error messages with recovery paths
141- **Success states**: Confirmation of successful actions
142- **Long content**: Handles very long names, descriptions, etc.
143- **No content**: Handles missing data gracefully
144- **Offline**: Appropriate offline handling (if applicable)
145
146### Responsiveness
147
148- **All breakpoints**: Test mobile, tablet, desktop
149- **Touch targets**: 44x44px minimum on touch devices
150- **Readable text**: No text smaller than 14px on mobile
151- **No horizontal scroll**: Content fits viewport
152- **Appropriate reflow**: Content adapts logically
153
154### Performance
155
156- **Fast initial load**: Optimize critical path
157- **No layout shift**: Elements don't jump after load (CLS)
158- **Smooth interactions**: No lag or jank
159- **Optimized images**: Appropriate formats and sizes
160- **Lazy loading**: Off-screen content loads lazily
161
162### Code Quality
163
164- **Remove console logs**: No debug logging in production
165- **Remove commented code**: Clean up dead code
166- **Remove unused imports**: Clean up unused dependencies
167- **Consistent naming**: Variables and functions follow conventions
168- **Type safety**: No TypeScript `any` or ignored errors
169- **Accessibility**: Proper ARIA labels and semantic HTML
170
171## Polish Checklist
172
173Go through systematically:
174
175- [ ] Visual alignment perfect at all breakpoints
176- [ ] Spacing uses design tokens consistently
177- [ ] Typography hierarchy consistent
178- [ ] All interactive states implemented
179- [ ] All transitions smooth (60fps)
180- [ ] Copy is consistent and polished
181- [ ] Icons are consistent and properly sized
182- [ ] All forms properly labeled and validated
183- [ ] Error states are helpful
184- [ ] Loading states are clear
185- [ ] Empty states are welcoming
186- [ ] Touch targets are 44x44px minimum
187- [ ] Contrast ratios meet WCAG AA
188- [ ] Keyboard navigation works
189- [ ] Focus indicators visible
190- [ ] No console errors or warnings
191- [ ] No layout shift on load
192- [ ] Works in all supported browsers
193- [ ] Respects reduced motion preference
194- [ ] Code is clean (no TODOs, console.logs, commented code)
195
196**IMPORTANT**: Polish is about details. Zoom in. Squint at it. Use it yourself. The little things add up.
197
198**NEVER**:
199
200- Polish before it's functionally complete
201- Spend hours on polish if it ships in 30 minutes (triage)
202- Introduce bugs while polishing (test thoroughly)
203- Ignore systematic issues (if spacing is off everywhere, fix the system)
204- Perfect one thing while leaving others rough (consistent quality level)
205- Create new one-off components when design system equivalents exist
206- Hard-code values that should use design tokens
207
208## Final Verification
209
210Before marking as done:
211
212- **Use it yourself**: Actually interact with the feature
213- **Test on real devices**: Not just browser DevTools
214- **Ask someone else to review**: Fresh eyes catch things
215- **Compare to design**: Match intended design
216- **Check all states**: Don't just test happy path
217
218## Clean Up
219
220After polishing, ensure code quality:
221
222- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
223- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
224- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
225- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
226
227Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
228
229## Related
230
231- `layout` — fix the underlying spacing scale, hierarchy, and grid first when the composition itself is what feels wrong; polish refines, it does not restructure.