ui-quality
Skill1 starsChanged yesterdayMITView on GitHub
UI quality floor (forms, dashboards, settings): build every state; audit by measuring the page (axe-core, focus, reflow, contrast). Use: 'audit accessibility', 'is this UI production-ready', 'check this page on mobile', 'feels wrong on my phone', 'break this UI' with worst-case data. Ambitious look → showpiece; conversion → conversion-ux.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use the request accompanying $ui-quality as the target.
- Distinctive: line 14
Read the repository instructions.
- Distinctive: line 31
Keep unverified candidates and checks you could not perform separate from confirmed findings.
- Very specific: line 32
Use WCAG sources only for what their criterion requires.
- Distinctive: line 33
Follow repository constraints and existing design decisions.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
UI quality
Build or audit screens people can see, read, reach and operate: forms, dashboards, settings, tables and app screens. Use the project's design system. Visual direction belongs to showpiece or frontend-design; conversion decisions belong to conversion-ux.
Start here
Use the request accompanying $ui-quality as the target. Both Claude Code and Codex follow the same steps:
- Read the repository instructions. Identify the requested screen, its main user task, and whether you may change it. A public site you do not own is read-only.
- Choose the route below. Read only that route first.
| Request | Read next | Finish with |
| Build or change a UI | build.md, in order | Implemented states, saved design decisions, then a quick audit |
| Audit, accessibility review, mobile check, production readiness | audit.md, in order | Verified findings and explicit coverage gaps |
| Check after a build or a narrow fix | audit.md, quick depth | Evidence for the changed screen and states |
Make a web app behave on a phone: sticky hover, tap flash, input zoom, notch, 100vh, carousel or sheet gestures | mobile.md | Fixes applied, a quick audit of the changed screen per audit.md, and which fixes need a real phone to confirm |
| Break a component with worst-case data, stress-test, edge cases | worst-case.md, in order | A dev-only data toggle and a break report; fixes only when the owner names them or the request asked for them |
rules.md is a lookup table. During a build, read the groups relevant to the components. During an audit, use the rule IDs in the audit guide to look up the source for each finding. You do not need to read the probe's implementation to run it.
Evidence rules
- A finding needs evidence, labelled Probe (a row in this run's output), Measured by hand, Observed, or From code, with its location. Report the user's difficulty and a concrete fix.
- Probe rows are candidates. Verify them before presenting them as defects. A clean run establishes only that the checks found nothing in the tested state; it never establishes WCAG compliance.
- Keep unverified candidates and checks you could not perform separate from confirmed findings. Include failures to start the probe or reach a state in coverage gaps.
- Use WCAG sources only for what their criterion requires. Label craft, platform and AAA advice separately. The probe's
fail,reviewandadvisorylabels are not owner-facing priorities. - Follow repository constraints and existing design decisions. Detect the stack from manifests before choosing implementation techniques. Report conflicting project decisions rather than silently replacing them.
The probe uses headed Chrome, offscreen at -2400,-2400 and muted. It uses the repository's launchPlacedChrome() when available; it never uses headless or minimized Chrome. Audit setup, commands, output interpretation and cleanup are all in audit.md.
In this repository99 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- addskillSkill
- adopt-repoSkill
- advocateSkill
- apply-firmwareSkill
- arenaSkill
- astra-reviewSkill
- babysit-ciSkill
- brainstormingSkill
- broSkill
- cache-loopSkill
- cavemanSkill
- claude-reviewSkill
- codex-reviewSkill
- conversion-uxSkill
- dareSkill
- deep-planSkill
- design-prototypesSkill
- enhance-promptSkill
- external-reviewSkill
- fable-modeSkill
- forge-repo-ui-skillSkill
- handoff-auditSkill
- impartial-reviewSkill
- init-projectSkill
- labSkill
- long-horizonSkill
- mergeSkill
- motion-designSkill
- optimize-contextSkill
- opus-fullreviewSkill
- perf-loopSkill
- product-walkthroughSkill
- recallSkill
- redesign-conceptsSkill
- refineSkill
- security-loopSkill
- seo-loopSkill
- serversSkill
- session-hubSkill
- showpieceSkill
- sync-starterSkill
- whySkill
- wow-loopSkill
- wrapupSkill
- writing-plansSkill
- writingSkill
- addskillSkill
- adopt-repoSkill
- advocateSkill
- apply-firmwareSkill
- arenaSkill
- astra-fullreviewSkill
- astra-reviewSkill
- babysit-ciSkill
- brainstormingSkill
- broSkill
- cache-loopSkill
- cavemanSkill
- The first 60 shown.
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.