polish
Performs a final quality pass fixing alignment, spacing, consistency, and micro-detail issues before shipping. Use when the user mentions polish, finishing touches, pre-launch review, something looks off, or wants to go from good to great.
71
58%
Does it follow best practices?
Impact
87%
1.11xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.cursor/skills/polish/SKILL.mdQuality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description with excellent trigger terms and clear completeness, explicitly covering both what the skill does and when to use it. Its main weakness is a lack of specificity about what types of artifacts it polishes (UI components? documents? code?), which creates potential overlap with other quality-focused skills. Adding the target domain would significantly strengthen distinctiveness.
Suggestions
Specify the type of artifact being polished (e.g., 'UI components', 'web pages', 'design files') to reduce conflict risk with code linting, proofreading, or other review skills.
Replace the vague 'micro-detail issues' with more concrete examples of what gets fixed (e.g., 'pixel alignment, padding inconsistencies, font weight mismatches').
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (quality pass) and some actions (fixing alignment, spacing, consistency, micro-detail issues), but the actions are somewhat general and not deeply concrete—'micro-detail issues' is vague, and the specific outputs or file types aren't mentioned. | 2 / 3 |
Completeness | Clearly answers both 'what' (performs a final quality pass fixing alignment, spacing, consistency, and micro-detail issues before shipping) and 'when' (explicit 'Use when...' clause with multiple trigger scenarios). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually say: 'polish', 'finishing touches', 'pre-launch review', 'something looks off', 'good to great'. These are varied and cover multiple natural phrasings. | 3 / 3 |
Distinctiveness Conflict Risk | The concept of 'polish' and 'finishing touches' is somewhat distinct, but without specifying what kind of artifact it polishes (UI, code, documents, presentations), it could overlap with linting, code review, design review, or proofreading skills. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but overly verbose UI polish checklist that reads more like a design handbook than a targeted Claude skill. Its main strength is thoroughness and some opinionated, specific guidance (easing functions, tinted neutrals, gray-on-color rules). Its main weaknesses are extreme verbosity covering many concepts Claude already knows, lack of executable code examples, and a monolithic structure that should be split across files.
Suggestions
Cut the content by 50-60% by removing well-known best practices (WCAG basics, semantic HTML, no console.logs, proper alt text) and keeping only the opinionated, non-obvious guidance that Claude wouldn't already know.
Add concrete code snippets for key recommendations—e.g., a CSS snippet for the recommended easing curves, a reduced-motion media query pattern, or a design token spacing scale example.
Split the detailed polish dimensions into a separate reference file (e.g., POLISH-CHECKLIST.md) and keep SKILL.md as a concise overview with the workflow and links to the detailed checklist.
Add explicit validation steps between polish phases—e.g., 'After fixing spacing, run Lighthouse accessibility audit' or 'After transitions, verify 60fps with Performance tab'—to create feedback loops for catching regressions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~200+ lines. Many items are general UI/UX best practices Claude already knows (WCAG contrast, semantic HTML, no console.logs, 44px touch targets). The exhaustive checklists read like a textbook rather than a targeted skill. Significant token waste on concepts that don't need re-teaching. | 1 / 3 |
Actionability | Provides specific, concrete guidance (e.g., '150-300ms transitions', '45-75 characters line length', 'ease-out-quart/quint/expo') but lacks executable code examples. Most items are checklist bullets rather than copy-paste-ready commands or code snippets. The guidance is specific enough to act on but not fully executable. | 2 / 3 |
Workflow Clarity | There is a clear sequence (pre-assessment → systematic polish → checklist → final verification) and the 'CRITICAL: Polish is the last step' constraint is good. However, there are no explicit validation checkpoints between polish dimensions, no feedback loops for catching regressions introduced during polish, and no concrete verification commands or tools specified. | 2 / 3 |
Progressive Disclosure | References /frontend-design and /teach-impeccable as prerequisites, which is good. However, the massive amount of inline content (all the polish dimensions with their sub-bullets) would benefit greatly from being split into separate reference files. The checklist alone could be a separate file. The skill is monolithic despite its length. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- pbakaus/impeccable
- Commit
db1add7
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.