ux-review
Skill0 starsChanged 9 days agoApache-2.0View on GitHub
Audit and fix the UX of a running web app end to end with evidence — route sweep, role and persona flows, page review at every width, interaction states, accessibility, Thai copy, data consistency, a fix loop and a production re-check. Use when asked to review, audit or polish a product's UX or UI, before or after release, or when users found a UI problem tests missed. Not for PRDs or new flows (product-management), new visual design (impeccable) or test strategy (qa-testing).
23 other projects use a version of this.
Adopted by
Most recently taken up by
- whyashthakker/estacktheir own version, first seen Nov 8, 2026
- WilliamEbong/CourseForgetheir own version, first seen Nov 8, 2026
- striderZA/OpenCodeGameStudiostheir own version, first seen Nov 4, 2026
- ngmeyer/skillstheir own version, first seen Nov 1, 2026
- Donchitos/Claude-Code-Game-Studiostheir own version, first seen Oct 19, 2026
- venus2099/codex-game-studiostheir own version, first seen Oct 17, 2026
Other versions23 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 23
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- gitkraken/vscode-gitlens★ 10ksame name
- striderZA/OpenCodeGameStudios★ 118same name
- cenconq25/claude-code-app-studio★ 40same name
- brianwestphal/glassbox★ 34same name
- parhamb/design-skills★ 21same name
- dawn840705/codex-code-studios★ 17same name
- lilangMax/ClaudeCodeGameStudios★ 8same name
- RoleModel/skills★ 7same name
- hongyuanc/codex-game-studios★ 5same name
13 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- ai-agentsSkill
- ai-agent-workflowsSkill
- ai-native-estimationSkill
- ai-product-deliverySkill
- book-dev-engineering-loopSkill
- business-analysisSkill
- client-discovery-and-proposalsSkill
- content-distributionSkill
- data-engineeringSkill
- flow-videoSkill
- game-engineeringSkill
- govern-ai-skillsSkill
- graphic-designSkill
- lead-research-and-crmSkill
- main-only-developmentSkill
- product-managementSkill
- product-ownerSkill
- project-managementSkill
- qa-testingSkill
- security-and-privacySkill
- skill-templateSkill
- solo-empire-operatorSkill
- solution-architectureSkill
- subagent-orchestrationSkill
- system-docpackSkill
- unused-file-cleanupSkill
- xr-engineeringSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 21 edited versions we read keep these.
4
Distinctive
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 15
Run the phases in order. Each phase has inputs, steps, pass criteria and outputs in the linked reference.
- Distinctive: line 58
One finding means a whole-page review: if one finding is reported (by the owner, a client or a tool), review the whole page and every page …
- Distinctive: line 68
Production: never create accounts or data, or pay, on production.
- Distinctive: line 70
Numbers: never change a calculation to make a page look right.
“Common” is measured: kept by at least 6 in 10 of the 21 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
UX Review
Find what a real user would trip over, prove it with screenshots and numbers, fix what is clearly a defect, and hand the owner a short list of real decisions. Automated checks and tests narrow the search; only looking at the rendered page closes it.
Workflow
Run the phases in order. Each phase has inputs, steps, pass criteria and outputs in the linked reference. Skip a phase only when the owner says so, and record the skip.
- Set up (P0): environment, accounts per role, test data, widths, and the evidence
folder. Production stays read-only. See
references/phases-discovery.md. - Map the product from code (P1–P2): roles, routes, permissions, and main use cases as business outcomes, with implemented/partial/proposed status. Personas only where code shows them.
- Sweep every route (P3–P4): every route × role × width for status, errors, overflow and access, plus an authorization matrix of role × page × action × API.
- Walk the flows (P5–P6): as-is and to-be Mermaid flows per persona and use case,
then run each flow step in a browser at phone and desktop width. Record the main
flows per role as videos with
../flow-video/for the owner and handover. - Review every page (P7): section by section at 320/375/768/1024/1440 with
../qa-testing/scripts/ui_review.mjs, againstreferences/page-checklist.md. Open every screenshot slice. Main use cases also run in WebKit and Firefox and on emulated phones (--browser,--device). With a baseline (--baseline), start with the changed regions. - Check interaction states (P8): hover, focus, active, disabled, loading, empty,
error, success, dialogs, menus, toasts and forms. Use
scripts/ui_states.mjsandreferences/interaction-states.md. - Check accessibility and performance (P8b): axe-core WCAG findings on every
capture, mobile Core Web Vitals and JS bytes with
--perf mobile, and the keyboard and screen-reader checks that tools cannot do. - Check content (P9): Thai copy, terminology, and leaks of demo, sample, test or placeholder text, including text from the API and seed data.
- Check data and figures (P10): each figure has one home, precision is
consistent, numbers agree across pages and with the API, and calculations
reconcile. See
references/data-and-figures.md. - Score (P11): heuristic and IA findings with severity, linked to the flows and pages where they occur.
- Fix loop (P12): fix bugs and clear UX defects, re-run the affected phases, keep before/after evidence, and list owner decisions without changing them.
- Release and re-check (P13): sign off with
../qa-testing/scripts/ui_signoff.py --promote-baseline, ship through the release gate, then repeat P3, P7, P8 and P8b on the live URL against the baseline.
Report with references/report-format.md.
Decision rules
- What counts as reviewed: a page is reviewed only when every section was looked at at every width in scope. "Scanned", "no overflow" or "tests pass" do not count.
- One finding means a whole-page review: if one finding is reported (by the owner, a client or a tool), review the whole page and every page that renders the same components.
- What you fix:
- A defect (broken, unreadable, wrong, inconsistent with the product's own rules) gets fixed.
- A business choice goes on the owner list with options and a recommendation: menu order, pricing, legal text, role names, feature removal.
- Text from the API or seed data: fix it at the source repository and say so. Do not patch it over in the UI.
- Production: never create accounts or data, or pay, on production. Use local or staging for anything that writes.
- Numbers: never change a calculation to make a page look right. A figure that disagrees across pages is a defect to trace, not to hide.
- Splitting work: delegate a phase only with a brief that names pages, widths, evidence paths and pass criteria. Check the returned screenshots yourself before accepting the result.
Resources
references/phases-discovery.mdcovers P0–P6: setup, product map, personas, sitemap, authorization, flows and flow tests. Read it when starting a review.references/phases-quality.mdcovers P7–P13: page review, states, accessibility and performance (P8b), content, data, scoring, the fix loop and the production re-check.references/page-checklist.mdhas the measurable section-by-section criteria for P7.references/interaction-states.mdhas the state matrix and contrast rules for P8.references/data-and-figures.mdhas the figure inventory and reconciliation for P10.references/production-test-accounts.md: rules for read-only review accounts and sessions on production. Read it before any logged-in live check.references/report-format.mdsets the evidence folder layout, IDs, severities, CSV columns and summary.scripts/ui_states.mjsforces hover, focus and active on every control and measures contrast and focus visibility.../qa-testing/scripts/ui_review.mjs,ui_signoff.pyandui_review_gate.pyhandle capture, page audit, sign-off and the release gate.ui_review.mjsalso runs the visual baseline diff, axe-core and the mobile performance pass. Browser and device setup is in../qa-testing/references/browsers-and-tools.md.
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.

