design-polish

Perform a meticulous final pass to catch all the small details that separate good work from great work. This skill makes changes — /design-audit and /design-critique are report-only. Polish is the last step, not the first — don't polish work that isn't functionally complete.

Detector and automated QA output are defect evidence only. A clean script result is never proof that the design is strong; gather browser evidence and inspect the real interaction path.

Preparation

Read ~/.claude/skills/minoan-frontend-design/SKILL.md for aesthetic principles. Check .design-context.md for project context.

Confirm the work is functionally complete before starting. If it's not, tell the user and suggest finishing the feature first.

Pull in prior critique (optional signal): If /design-critique has been run on the same target, read the latest snapshot from .design-critique/ and fold its P0/P1 items into your polish list. The critique is one input among many — do your own pass either way.

Triage cosmetic vs functional: Classify each issue as cosmetic (looks off, doesn't impede the user) or functional (breaks, blocks, or confuses the experience). When polish time is tight, functional issues ship first; cosmetic ones can land in a follow-up. Quality should be consistent — never perfect one corner while leaving another rough.

Design System Discovery

Aligning the feature to the design system is not optional. Polish without alignment is decoration on top of drift.