Polish
Run a meticulous pre-ship UI pass—alignment, spacing, tokens, and micro-details—after feature work is done but before users see it.
Overview
Polish is an agent skill most often used in Ship (also Build frontend) that performs a final design-system-aligned quality pass on alignment, spacing, and micro-details before launch.
Install
npx skills add https://github.com/pbakaus/impeccable --skill polishWhat is this skill?
- Mandatory preparation: invoke /impeccable for design principles, anti-patterns, and Context Gathering Protocol—run /impe
- Design system discovery: locate tokens, spacing scale, typography, and shared components before touching pixels
- Drift detection: hard-coded colors vs tokens, duplicate components, spacing off-scale
- Final quality pass for alignment, spacing, consistency, and micro-detail issues (version 2.1.1)
- User-invocable with optional target argument for scoped polish on a screen or flow
- Skill version 2.1.1 documented in frontmatter
- Mandatory three-step design system discovery: find system, note conventions, identify drift
Adoption & trust: 86k installs on skills.sh; 35.9k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your feature works but feels amateur—misaligned grids, inconsistent spacing, and token drift that you cannot quite name before users see it.
Who is it for?
Solo builders with an existing design system or style guide who are one pass away from a confident pre-launch ship.
Skip if: Greenfield visual exploration or teaching a design language from scratch without running impeccable teach and gathering context first.
When should I use this skill?
User mentions polish, finishing touches, pre-launch review, something looks off, or wants to go from good to great; optional [target] scopes the pass.
What do I get? / Deliverables
UI aligned to discovered tokens and components with drift remediated to your stated MVP or flagship bar after impeccable context and teach prerequisites are satisfied.
- Drift report against design tokens, spacing, and shared components
- Applied micro-fixes for alignment, spacing, and consistency on the target surfaces
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship is the canonical shelf because the skill targets finishing touches, pre-launch review, and the gap between “works” and “shipped and polished.” launch fits explicit pre-launch and “something looks off” triggers even when the underlying fixes live in frontend files.
Where it fits
Sweep onboarding and paywall screens for spacing-scale violations the night before release.
After a large PR lands, reconcile hard-coded colors with semantic tokens across shared components.
Polish marketing-critical flows so screenshots and Loom demos match the flagship quality bar.
Tighten email-linked in-app surfaces where inconsistent buttons erode trust after acquisition campaigns.
How it compares
Final human-grade UI finishing workflow in the Impeccable stack—not a substitute for automated visual regression tests.
Common Questions / FAQ
Who is polish for?
Indie developers and designers shipping web or mobile UI who already have implementation in place and need a systematic last look before launch.
When should I use polish?
Use it in Ship during pre-launch review when something looks off; in Build frontend when closing a milestone PR; and before Launch distribution when hero or onboarding flows must match design tokens.
Is polish safe to install?
It guides repository reading and targeted UI edits; review the Security Audits panel on this Prism page and your agent filesystem permissions before applying changes broadly.
Workflow Chain
Requires first: impeccable
SKILL.md
READMESKILL.md - Polish
## MANDATORY PREPARATION Invoke /impeccable — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /impeccable teach first. Additionally gather: quality bar (MVP vs flagship). --- Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished. ## Design System Discovery Before polishing, understand the system you are polishing toward: 1. **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. 2. **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? 3. **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: 1. **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?) 2. **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, s