ds-design-audit
Skill80 starsChanged 15 days agoMITView on GitHub
Reviews an existing UI with scores based on evidence, then fixes the highest-impact problems. Use when a page or app screen looks generic, cluttered, or unfinished, or before you ship UI work. Run as /ds-design-audit.
In this repository28 other files it gives its agents.
- ds-adoptSkill
- ds-best-of-nSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-catchupSkill
- ds-context-resetSkill
- ds-designSkill
- ds-explainSkill
- ds-helpSkill
- ds-jurySkill
- ds-ledgerSkill
- ds-lessonsSkill
- ds-modeSkill
- ds-plan-loopSkill
- ds-pr-commentsSkill
- ds-principlesSkill
- ds-prSkill
- ds-readySkill
- ds-review-loopSkill
- ds-reviveSkill
- ds-sharpenSkill
- ds-shipSkill
- ds-swarmSkill
- ds-tddSkill
- ds-unslopSkill
- ds-unstickSkill
- ds-verify-loopSkill
- ds-watch-prSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Read the target's code: tokens, fonts, colors, focus styles, media queries, and copy.
- Distinctive: line 25
If an area still has a score of 2 or lower, or a banned default remains, repeat steps 6 to 8 once.
- Distinctive: line 34
Do not give a score without evidence.
- Distinctive: line 35
Do not change factual copy, prices, claims, or feature behavior without asking.
- Distinctive: line 36
If the brief requires a style that this skill would flag, it is not a fault.
- Distinctive: line 37
If the UI needs a full rebuild, recommend /ds-design.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Score a UI from what is on the screen, fix the worst problems, and show that the fixes work.
Steps
- Identify the target file or URL and render it. If it does not render, report this and stop. Do not audit from the source code alone.
- Take screenshots of the first viewport and the full page at about 1440px and 390px wide. Also capture the hover, focus, empty, loading, and error states where you can.
- Read the target's code: tokens, fonts, colors, focus styles, media queries, and copy.
- Give each area a score from 1 to 5. Give one line of evidence for each score: something visible or a line of code.
- Hierarchy: the main message and action are clear within 3 seconds, and there is one focal point.
- Typography: the fonts are paired on purpose, the scale is consistent, and the line length and leading are correct.
- Color: there is one dominant color and one accent, the colors are tokens and not scattered hex values, and there are no decorative gradients.
- Spacing: the spacing follows a scale, the rhythm is consistent, and the mobile alignment is correct.
- States: hover, focus, empty, loading, error, and long-content states all exist.
- Accessibility: the contrast is 4.5:1 or higher, the focus rings are visible, the fields have labels, the touch targets are 44px, and reduced motion is respected.
- Copy: the copy is specific to the product, with no stock phrases and no placeholder data.
- Record each banned default that you see: purple-blue gradients, a default font used for display, emoji used as icons, a centered hero with three identical cards, glassmorphism everywhere, gray text on gray, and generic copy.
- Rank the fixes by their impact on users. Put broken accessibility and an unclear main action first. Put decoration last. For each fix, give the file, the change, and the score that it raises.
- Apply the top 3 to 5 fixes. Fix the cause in the tokens or in the shared components, not in each instance. Keep the identity, content, and behavior of the product.
- Take new screenshots at the same widths and in the same states as in step 2. Score each area again and show the before and after scores side by side.
- If an area still has a score of 2 or lower, or a banned default remains, repeat steps 6 to 8 once. Do not do more than two passes.
Stop when
- Two passes are complete, or every area has a score of 3 or higher and no banned default remains.
- The report shows the before and after scores, the evidence, the fixes that you applied, and the fixes that you did not apply, each with a reason.
Rules
- Do not give a score without evidence. If you could not see an area, mark it "not checked" and give the reason.
- Do not change factual copy, prices, claims, or feature behavior without asking.
- If the brief requires a style that this skill would flag, it is not a fault.
- If the UI needs a full rebuild, recommend /ds-design. Do not rebuild it in this skill.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.