polish
by pbakauspolish is a final-pass UI review skill for catching alignment, spacing, consistency, token usage, and micro-detail issues before shipping. It is best for screens, flows, or components that already work but feel close, not quite polished. Use it to improve launch readiness, design-system alignment, and overall quality without unnecessary redesign.
This skill scores 71/100, which means it is list-worthy for directory users, but it should be installed with clear expectations: it offers a real, actionable polishing workflow, though the repo does not include supporting scripts or references that would make adoption fully turnkey. The description and body are detailed enough to help an agent trigger and execute the skill with less guesswork than a generic prompt.
- Strong triggerability: the frontmatter gives a clear use case for final-pass polishing and includes a concrete argument hint.
- Operational workflow guidance: the skill spells out a multi-step process for design system discovery, drift detection, and alignment before polishing.
- No placeholder/demo signals: the body is substantial and specific, with valid frontmatter and no experimental/test-only markers.
- No support files or references: there are no scripts, resources, or linked docs to help an agent ground decisions beyond the skill text.
- Some execution depends on external context: the skill asks for design system docs and a quality bar, so it may be less effective when that context is absent.
Overview of polish skill
What polish does
The polish skill is a final-pass UI review workflow for catching the issues that make work feel almost done rather than truly shippable. It focuses on alignment, spacing, consistency, token usage, visual rhythm, interaction detail, and small implementation drift that generic prompts often miss.
Who the polish skill is for
Use this polish skill if you already have a working interface and want to raise its quality before review, launch, or handoff. It fits designers, frontend engineers, and AI-assisted builders working on screens, flows, or components that feel “close, but off,” especially when a design system or existing product conventions should guide the finish.
What matters before you install
The biggest adoption detail is that polish is not meant to invent a design direction from nothing. It assumes there is something to inspect and improve. It also depends on $impeccable: the skill explicitly requires running that broader skill first for context gathering, principles, and anti-pattern checks. If no design context exists yet, the workflow says to run $impeccable teach before using polish.
Why not just use a normal prompt
A plain “make this look better” prompt usually produces vague advice or random redesigns. polish is more useful when you need a systematic pass against an actual system: identify the design conventions, detect drift from tokens/components/patterns, and make targeted corrections without changing the product unnecessarily. That makes it more practical for pre-launch cleanup and UI design consistency work.
How to Use polish skill
Install context and first files to read
Install the skill from the pbakaus/impeccable repository and review SKILL.md first, because that file contains the real operating rules. The most important instruction is mandatory: invoke $impeccable first. For a polish install decision, that means this skill works best as part of the broader impeccable workflow, not as a standalone one-off prompt.
What input polish needs to work well
The polish skill performs best when you provide:
- the target screen, flow, or component
- the current implementation or screenshots
- the design system, component library, or token conventions if available
- the quality bar:
MVPorflagship - any known pain points such as “spacing feels uneven” or “buttons look inconsistent”
A weak request is: Polish this settings page.
A stronger polish usage prompt is: Use polish on the settings page. Quality bar: flagship. Match our existing design system. Check spacing scale, token usage, component consistency, alignment, and interaction details. Avoid redesigning layout unless needed.
A practical polish workflow
A reliable workflow is:
- Run
$impeccableto gather context and principles. - Identify the design system or, if none exists, infer conventions from nearby product areas.
- Assess the current UI for drift: hard-coded values, inconsistent spacing, duplicate custom patterns, uneven hierarchy, or visual noise.
- Apply small, high-confidence changes first.
- Re-check the screen as a whole so local fixes do not create new inconsistencies.
This is the best polish guide mindset: do not jump straight into edits. The repository emphasizes understanding what “polished” means in this product before changing details.
Prompting tips for polish for UI Design
For polish for UI Design, ask for a structured output. Good prompt additions include:
List issues by severity before proposing changes.Prefer system alignment over novelty.Call out where tokens or shared components should replace custom styling.Separate must-fix launch blockers from nice-to-have refinements.
This improves output quality because the skill is strongest at systematic inspection, not broad creative exploration. If you want exploration, use a concepting or redesign-oriented skill first, then bring in polish at the end.
polish skill FAQ
Is polish good for beginners?
Yes, if you already have a concrete UI to improve. The polish skill gives beginners a better checklist than a generic prompt, especially around spacing, consistency, and design-system alignment. But it is less beginner-friendly if you do not yet know your product conventions, because the workflow assumes context exists or must be taught through $impeccable.
When should I not use polish?
Do not use polish when the problem is actually strategy, information architecture, or missing UX direction. It is also a poor fit for blank-canvas design work. If the screen is fundamentally wrong, polish will not replace a proper redesign; it is for finishing touches and quality elevation, not core product invention.
How is polish different from a code review?
A code review may catch maintainability or correctness issues. The polish skill is more focused on shipped experience: visual consistency, system drift, micro-detail quality, and whether the interface feels coherent. There can be overlap, but polish usage is primarily about UI quality rather than engineering architecture.
Does polish require a design system?
No, but it works better with one. If there is no formal system, the skill still asks you to polish toward visible product conventions. That means it can still help in scrappy products, but outputs will be stronger when there are reusable tokens, components, or established patterns to align with.
How to Improve polish skill
Give polish a sharper target
The fastest way to improve polish results is to define the target clearly: MVP versus flagship, which surface to inspect, and whether the goal is consistency, premium feel, launch readiness, or design-system compliance. Without that, the skill may over-fix minor issues or spend effort where quality does not matter.
Feed stronger evidence, not just opinions
Better inputs produce better polish. Provide screenshots, component code, neighboring screens, token files, or examples of “this is the level we want.” That helps the skill distinguish real inconsistency from intentional variation. If you only say “make it nicer,” it has to guess the standard.
Watch for common failure modes
The main failure modes are:
- over-redesigning instead of refining
- fixing local details while breaking page-level rhythm
- introducing new custom styles instead of aligning to shared components
- treating every inconsistency as a bug when some are purposeful
Ask the skill to preserve the product’s established patterns unless a deviation clearly hurts quality.
Iterate after the first pass
The best way to improve the polish skill in practice is a second pass with feedback. After the first output, respond with specifics such as too aggressive, keep layout unchanged, focus only on spacing and typography, or prioritize design-token cleanup. That narrows the pass from general refinement to the exact standard your team expects.