Skip to content
Back to skills

Design Polish

ASecurity

Use when building or changing a user interface (HTML, CSS, JSX/TSX, Vue, Svelte, a Creator artifact). Run Shodh's design check, fix what it finds in order of harm, keep the project's own look, and finish with a clean check.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 11, 2026
ai-agentsrustgovuegit

Works with

  • cli

Security analysis

A100/100

Scanned November 11, 2026

npx -y skills add varun29ankuS/shodhRAG --skill design-polish --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Design Polish?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Design Polish
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/varun29ankus-design-polish/badge)](https://www.skillsdirectory.com/skills/varun29ankus-design-polish)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: design-polish
description: Use when building or changing a user interface (HTML, CSS, JSX/TSX, Vue, Svelte, a Creator artifact). Run Shodh's design check, fix what it finds in order of harm, keep the project's own look, and finish with a clean check.
license: Apache-2.0
metadata:
  bundled-by: Shodh
  sources: pbakaus/impeccable (polish, audit)
---

# Design polish

A page that works can still be hard to read, impossible to use with a
keyboard, or look like every other generated page. Polish is refinement, not
a hidden redesign: keep the project's look, words and behaviour, and fix what
is wrong.

Fourth of Shodh's six building skills, for UI work (plan-before-building →
test-first → debug-systematically → **design-polish** → verify-before-done →
fresh-eyes-review). It comes before verify-before-done, so the design fixes are
built, tested and reviewed like any other change.

## The check

Shodh's `design_check` tool reads UI files with fixed rules (no model) and
shows its findings to the user in the code pane. Shodh also runs it on the UI
files you changed after you write them, so the user sees a "Design check: 3
issues" badge either way.

- Give it a file or folder (`path`), or an artifact (`artifact_id`).
- Each finding has a rule, a severity, a file:line and a suggested fix. Some
  carry an exact one-line replacement: a proposal, made only with your edit
  tool, never without the edit's normal approval.
- A finding is evidence to check, not proof. Read the cited line before
  changing it, and say so when a rule is wrong for this case.

If `design_check` is not among your tools, ask the user to run "Design check"
from the code pane or the Artifacts page.

## Order of work

Fix in this order, and do not perfect one corner while the rest stays broken:

1. **People cannot use it** (errors): images without alt text, fields without
   labels, buttons with no name, clickable divs, focus outlines removed.
2. **People cannot read it**: low contrast, text under 12px, tight line
   height, crushed or wide letter spacing, justified or all-caps paragraphs.
3. **It looks unfinished or generated**: Lorem ipsum, placeholder images,
   emoji used as icons, purple-to-blue gradients, gradient text, side-tab
   borders, glows, marketing buzzwords.
4. **It is not one system**: too many radii, type sizes or the same spacing
   everywhere. Use the project's scale; add a value to it only when it is
   reused.

## How to fix

- Use the project's own tokens, components and icon set first. Classify each
  problem: a missing token, a one-off that a shared component should replace,
  or a local slip. Fix it at the narrowest level that is right.
- Text is at least 12px everywhere; body text 14px to 16px.
- Plain words on labels and buttons. An icon sits to the left of its label;
  an icon alone needs `aria-label`.
- Every control has a visible focus style, a hover style and a disabled
  style. Keyboard order follows the reading order.
- Show the shortcut a control has (from the app's shortcut list) next to it,
  never a made-up one.
- Never undo what the user explicitly asked for (a font, a colour, a gradient,
  an emoji they chose), even when a rule flags it. Keep it, and say which
  findings you left for that reason.
- Ask before changing claims, product copy or anything outside the request.

## Finish

1. Run `design_check` on the files you changed. Repeat until no errors or
   warnings remain, or each one left is explained.
2. Then follow verify-before-done: build, run the checks and the tests.
3. Tell the user what you fixed, what you left and why. A clean check does
   not replace looking at the page: say what you could not see.

## Rules that do not bend

- The design check changes nothing. Every fix goes through your edit tool and
  its approval.
- Never remove a feature, a state or content to make a finding go away.

## Sources and credit

Rewritten for Shodh from **pbakaus/impeccable**, commands `polish` and `audit`
(https://github.com/pbakaus/impeccable, commit
a90602e9f6fed600d6d9b18cf78275d66cac7a6c), Apache License 2.0, Copyright 2025
Paul Bakaus. See `LICENSE-impeccable.txt`. Changed by Shodh: the polish pass
and the audit's accessibility and integrity checks are condensed into one
order of work, the detector is Shodh's own Rust port run through
`design_check` (impeccable's scripts, browser capture, critique snapshots and
scores are not used), and the user's interface rules (12px floor, plain words,
icons left of labels, shortcut hints) are added.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in ai-agents →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.