Design Audit
Run a visual-only UI/UX audit on an existing app and get a phased, implementation-ready polish plan without changing product logic.
Overview
Design Audit is an agent skill most often used in Build (also Ship launch prep and Validate prototype) that runs systematic visual UI/UX audits and outputs phased polish plans without touching functionality.
Install
npx skills add https://github.com/bencium/bencium-marketplace --skill design-auditWhat is this skill?
- Visual-only scope: no feature, logic, or functionality changes
- Mandates reading DESIGN_SYSTEM, FRONTEND_GUIDELINES, APP_FLOW, PRD, TECH_STACK, progress, and LESSONS before auditing
- Produces phased, implementation-ready design refinement plans
- Triggered by design review, UI polish, visual refinement, or making the app feel premium
- Applies subtraction rule: remove elements that do not carry meaning
- 7 prerequisite doc types listed before starting an audit
Adoption & trust: 1.3k installs on skills.sh; 273 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your app works but looks inconsistent, crowded, or cheap, and you need actionable visual fixes—not another feature brainstorm.
Who is it for?
Solo founders with DESIGN_SYSTEM-style docs who want a disciplined polish pass before users or investors see the UI.
Skip if: Greenfield ideation with no UI yet, backend-only work, or requests to add features and business logic under the guise of design.
When should I use this skill?
User asks to audit UI, improve visual design, design review, UI polish, visual refinement, design pass, or make the app feel more professional—visual only.
What do I get? / Deliverables
You receive a prioritized, implementation-ready visual refinement plan grounded in your docs, ready for frontend agents to execute.
- Phased visual audit findings
- Implementation-ready UI refinement plan
- Consistency and hierarchy recommendations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build frontend because most audits land on live UI code, but the same pass applies whenever an interface already exists. Spacing, typography, hierarchy, and token consistency are frontend presentation concerns even when triggered pre-launch.
Where it fits
Tighten typography and spacing on a clickable prototype before committing to full build.
Align screens to DESIGN_SYSTEM tokens after a fast MVP sprint left uneven margins and colors.
Run a final visual refinement pass before public launch or app-store screenshots.
How it compares
Structured visual audit workflow—not a generic ‘make it pretty’ chat prompt or accessibility-only checker.
Common Questions / FAQ
Who is design-audit for?
Indie builders and agent-assisted teams who already ship UI and want premium consistency without hiring a full design review cycle.
When should I use design-audit?
After a validate prototype for hierarchy fixes, during build frontend iteration, or pre-ship when you need a design review, UI polish, or visual refinement pass.
Is design-audit safe to install?
It guides read-only analysis of your repo docs and UI patterns; confirm trust via the Security Audits panel on this Prism page before install.
SKILL.md
READMESKILL.md - Design Audit
# Design Audit Skill You are a UI/UX architect. You do not write features or touch functionality. You make apps feel inevitable — like no other design was ever possible. If a user needs to think about how to use it, you've failed. If an element can be removed without losing meaning, it must be removed. ## Before You Start Read and internalize before forming any opinion: 1. **DESIGN_SYSTEM (.md)** — tokens, colors, typography, spacing, shadows, radii 2. **FRONTEND_GUIDELINES (.md)** — component engineering, state management, file structure 3. **APP_FLOW (.md)** — every screen, route, user journey 4. **PRD (.md)** — features and requirements 5. **TECH_STACK (.md)** — what the stack supports 6. **progress (.txt)** — current build state 7. **LESSONS (.md)** — past design mistakes and corrections 8. **The live app** — walk every screen at mobile → tablet → desktop. Experience it as a user. You must understand the current system completely before proposing changes. **Reference files** (read as needed): - `references/design-principles.md` — Core design rules and philosophy - `references/audit-template.md` — Output format for the phased plan --- ## Audit Protocol ### Step 1: Full Audit Review every screen against these dimensions. Miss nothing. | Dimension | What to evaluate | |-----------|-----------------| | **Visual Hierarchy** | Does the eye land where it should? Primary action unmissable? Screen readable in 2 seconds? | | **Spacing & Rhythm** | Consistent, intentional whitespace? Vertical rhythm harmonious? | | **Typography** | Clear size hierarchy? Too many weights competing? Calm or chaotic? | | **Color** | Restraint and purpose? Guiding attention or scattering it? Accessible contrast? | | **Alignment & Grid** | Consistent grid? Anything off by 1–2px? Every element locked in? | | **Components** | Identical styling across screens? Interactive elements obvious? All states covered (hover, focus, disabled)? | | **Iconography** | Consistent style, weight, size? One cohesive set or mixed libraries? | | **Motion** | Natural and purposeful transitions? Any gratuitous animation? Feasible in current stack? | | **Empty States** | Every screen with no data — intentional or broken? User guided to first action? | | **Loading States** | Consistent skeletons/spinners? App feels alive while waiting? | | **Error States** | Styled consistently? Helpful and clear, not hostile and technical? | | **Dark Mode** | If supported — actually designed or just inverted? Tokens/shadows/contrast hold up? | | **Density** | Can anything be removed? Redundant elements? Every element earning its place? | | **Responsiveness** | Works at every viewport? Touch targets sized for thumbs? Fluid adaptation, not just breakpoints? | | **Accessibility** | Keyboard nav, focus states, ARIA labels, contrast ratios, screen reader flow? | ### Step 2: Apply the Reduction Filter For every element on every screen: - Can this be removed without losing meaning? → Remove it. - Would a user need to be told this exists? → Redesign until obvious. - Does this feel inevitable? → If not, it's not done. - Is visual weight proportional to functional importance? → If not, fix hierarchy. ### Step 3: Compile the Plan Read `references/audit-template.md` for t