polish

Overview of polish skill

What polish does

The polish skill is a final-pass UI quality review and refinement workflow for work that is already basically complete. It is designed to catch the small issues that make interfaces feel unfinished: misalignment, uneven spacing, inconsistent copy, missing states, rough transitions, and edge-case gaps that are easy to miss before launch.

Who should use polish

This polish skill is best for designers, frontend engineers, and AI-assisted builders who already have a working screen, flow, or feature and want to move it from “good enough” to “ship-ready.” It is especially relevant for polish for UI Design, where visual consistency and interaction quality matter as much as functional correctness.

The real job-to-be-done

Users do not install polish to generate a design from scratch. They use it to run a structured finishing pass on an existing implementation, identify what still feels off, and apply targeted improvements in the right order. The skill is most useful when the question is not “what should I build?” but “what still needs refinement before release?”

What makes this polish skill different

Unlike a generic “make this nicer” prompt, polish is opinionated about sequence and readiness:

• it assumes polish happens late, not early
• it requires design context first
• it asks for the quality bar, such as MVP versus flagship
• it pushes a systematic pass across visual, interaction, copy, and state details rather than random tweaks

That makes the polish guide more actionable for pre-launch review than a loose aesthetic prompt.

Biggest adoption caveat

The main blocker is dependency on prior context. The skill explicitly requires /frontend-design, and if that context does not exist yet, it says to run /teach-impeccable first. If you skip that setup, the polish skill will be less consistent because it will lack the design principles and context-gathering process the workflow expects.

How to Use polish skill

Install context for polish

The upstream skill lives in pbakaus/impeccable at .claude/skills/polish. If you use a skills-compatible setup, add it from the repo and invoke it as polish on a concrete target such as a screen, flow, or component set.

A practical install pattern is:

npx skills add https://github.com/pbakaus/impeccable --skill polish

If your environment uses a different skill loader, the important detail is the skill path and name, not the exact command.

Read this file first

Start with:

• SKILL.md

This repository signal matters: there are no extra rules/, resources/, or helper scripts for this skill. Almost all usage value is in the main instruction file, so you do not need a deep repo dig before deciding whether to install.

Required prerequisites before invoking polish

Before using polish, prepare:

• design context from /frontend-design
• the current target to review
• quality bar: MVP or flagship
• shipping timeline and time budget
• known issues that should stay as TODOs instead of being “fixed” during polish

This is not optional ceremony. The skill is written to avoid wasted effort on unfinished work.

When to invoke polish in a workflow

Use the polish skill after:

• the feature works end to end
• major layout and content decisions are already made
• core states exist, even if some are rough
• you are near review, QA, handoff, or launch

Do not use polish as an early ideation tool. It will produce lower-value output if the work is still structurally changing.

Best inputs for polish usage

Strong inputs are specific and bounded. Good targets include:

• “Polish the settings page before beta launch”
• “Run polish on the onboarding flow for mobile”
• “Final pass on the checkout modal and its loading, error, and success states”

Weak inputs are vague:

• “Make it better”
• “Improve the UI”
• “Fix design”

The skill works best when the target is narrow enough to inspect carefully.

Turn a rough goal into a strong polish prompt

A good polish usage prompt should include:

1. the target
2. current completeness
3. quality bar
4. constraints
5. what not to change

Example:

“Use polish on the account settings page. The page is functionally complete. Quality bar is flagship, but we only have 2 hours before code freeze. Preserve current information architecture. Focus on alignment, spacing, copy consistency, missing hover/focus/disabled states, and anything that still feels unshipped.”

Why this works:

• it confirms readiness
• it limits scope
• it clarifies tradeoffs
• it prevents unnecessary redesign

What polish reviews systematically

Based on the source instructions, the polish skill should inspect at least these areas:

• alignment to grid
• spacing consistency
• visual rhythm
• interaction state completeness
• copy consistency
• edge cases and error states
• loading behavior
• transition smoothness

That breadth is why the skill is more useful than a single-pass visual critique.

Suggested operating workflow

Use this workflow to get better results from polish:

1. confirm the feature is complete enough
2. gather design context via /frontend-design
3. define the quality bar and time budget
4. ask polish for an assessment first, not immediate edits
5. group findings by severity and effort
6. apply high-value fixes first
7. rerun polish on the updated result for a second pass

This avoids churn and keeps the skill focused on launch-critical details.

What to ask polish to return

For practical use, ask the skill to structure output as:

• blocking issues before ship
• high-impact quick wins
• missing states
• consistency fixes
• optional flagship-level refinements

That format makes the output easier to act on than a flat list of observations.

Common misuses that reduce output quality

Avoid these patterns:

• invoking polish before functional completion
• using it without prior design context
• asking it to redesign the whole product
• skipping quality bar guidance
• providing no time constraint, which leads to unrealistic refinement scope

These are the main reasons a polish install feels disappointing even when the skill itself is sound.

polish skill FAQ

Is polish only for visual cleanup

No. The polish skill clearly goes beyond cosmetic cleanup. It also checks interaction states, loading behavior, transitions, copy consistency, and edge-case handling. If your issue is “the UI works but still feels unready,” polish is a good fit.

Is polish beginner-friendly

Yes, with one caveat: beginners may miss the prerequisite workflow. If you follow the required setup and give a concrete target, the skill is straightforward. If you skip the design-context step, the output may feel less grounded.

How is polish different from a normal prompt

A normal prompt often yields generic advice like “improve spacing” or “make buttons consistent.” The polish skill is stronger because it defines timing, readiness, and review dimensions. That reduces guesswork and makes the feedback more systematic.

When should I not use polish

Do not use polish when:

• the feature is still being defined
• functionality is incomplete
• you need a concept or redesign
• you lack enough artifact context to review real UI details

In those cases, another design or implementation skill is a better first step.

Does polish work for MVPs or only premium UI

It works for both, but you need to declare the bar. For an MVP, polish should prioritize obvious inconsistencies and missing states. For a flagship experience, it should push further into micro-interactions, rhythm, and finer consistency.

Is polish useful outside UI design

Mostly it is best for UI and frontend work. The source emphasis is on spacing, alignment, states, and transitions, so polish for UI Design is the clearest fit. It is less appropriate for backend logic or general product strategy.

How to Improve polish skill

Give polish a quality bar and deadline

This is one of the highest-leverage inputs. “Make it polished” is ambiguous. “MVP with 30 minutes left” and “flagship with a full sprint available” produce very different recommendations. The skill explicitly asks for this because polish is always constrained by time and ambition.

Provide the current state, not just the desired state

Tell polish what already exists:

• completed screens
• known defects
• intentional compromises
• preserved TODOs

This helps the skill avoid re-opening settled decisions and focus on finish quality.

Narrow the target for better polish results

You will usually get better output from:

• one flow
• one page
• one component family

than from:

• an entire product
• a vague “app-wide polish pass”

A narrow target enables more precise review and fewer generic comments.

Ask for prioritized findings

One of the biggest failure modes in polish usage is getting a long list with no triage. Ask the skill to separate:

• must-fix before ship
• should-fix if time permits
• nice-to-have refinements

That makes the output more usable for real release pressure.

Include state coverage in your prompt

Many rough interfaces fail not in the default state but in the missing ones. Explicitly ask polish to inspect:

• hover
• focus
• active
• disabled
• loading
• empty
• error
• success

This raises the chance of catching the issues that most often slip through.

Use a two-pass polish workflow

For the best polish guide in practice:

1. first pass: ask for diagnosis only
2. implement fixes
3. second pass: ask for regression and consistency review

This is better than asking for everything at once because the second pass can catch new inconsistencies introduced by the first round of changes.

Watch for over-polishing

The polish skill is strong, but users can misuse it by continuing refinement after the product goal is already met. Stop when:

• major inconsistencies are resolved
• critical states are covered
• the UI supports the declared quality bar
• further changes mostly become subjective taste

That keeps polish from turning into endless churn.

Improve polish by pairing it with evidence

If available, include:

• screenshots
• target component names
• design tokens or spacing system
• launch context
• known user pain points

The skill can then judge polish against actual constraints instead of inventing a standard from scratch.

If the first output feels generic, strengthen the brief

When polish gives broad advice, the usual fix is not replacing the skill but improving the input. Add:

• the exact target
• current maturity
• visual system constraints
• quality bar
• deadline
• non-goals

That usually converts generic critique into usable pre-ship guidance.