ux-audit
Skill2 starsChanged 55 days agoMITView on GitHub
Walk through a product UI as a real user — take screenshots, find broken flows, and produce a structured report with every fix listed. Use when: audit the UI or UX, do a UX review, QA a feature, check if something looks right, verify a user flow or onboarding, walk through a journey, 'is X broken?', 'check how X works'. Do NOT use for: proving that a specific change works with pass/fail evidence for a PR, fixing a specific known bug, reading a component's code, deploying, writing tests, or answering questions about code structure.
26 other projects use a version of this.
Adopted by
Most recently taken up by
- thensls/nsls-builder-toolkittheir own version, first seen Nov 8, 2026
- naman10parikh/pennytheir own version, first seen Nov 8, 2026
- naman10parikh/wikimemtheir own version, first seen Nov 8, 2026
- lobehub/lobehubtheir own version, first seen Nov 5, 2026
- AhmedAbdelfattah0/AI-Skillstheir own version, first seen Nov 4, 2026
- drvoss/everything-copilot-clitheir own version, first seen Oct 26, 2026
Used with
Projects with it also use ecosystem-reference, fractal-delegation and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
naman10parikhSkillecosystem-reference
Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.
Also in 5 projects that use this
naman10parikhSkillfractal-delegation
Also in 5 projects that use this
KirchliveSkillskill-routing
Decides which of the installed skills a task needs and loads them before the work starts. This skill should be used at the beginning of any multi-step task — build, fix, refactor, migrate, review, plan, release, research, write, design, video — and again at every phase change, after context compaction, and when work moves into a different part of the codebase. Use it for requests like "let's build X", "fix this bug", "refactor Y", "plan the migration", "review this", and also when the user asks which skill applies, why a skill did not fire, or asks to check what is available.
Also in 5 projects that use this
sublimotionSkillagent-runtime
Launch and manage detached agent runs on EKS via the agent-runner CLI. Use when the user says "launch an agent run", "agent runtime", "agent-runner", "run this spec on the cluster", "check run status", "agent run logs", or "stop a run". Do NOT use for writing the agent-runner code itself (edit the sibling ../agent-runner repo), Terraform of the foundation (use terraform-automation), or GPU serving deployments (use infra-deployer).
Also in 5 projects that use this
GoZippySkillrepo-scout
Also in 5 projects that use this
BenjaminGSkillharness-review
Turn one PR's review comments into harness fixes — classify each cause by the most solid place it can live (codebase, lint, rules, skill), then draft the fixes in a separate PR.
Also in 5 projects that use this
- +6 more from naman10parikh
Other versions26 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 26
- lobehub/lobe-chat★ 84ksame name
- lobehub/lobehub★ 84ksame name
- thedesignproject/agent-skills★ 88same name
- drvoss/everything-copilot-cli★ 48same name
- EliaAlberti/ux-audit-skill★ 17same name
- kevin-burns/claude-skills★ 10same name
- naman10parikh/agentgrid★ 9same name
- naman10parikh/wikimem★ 8same name
- AhmedAbdelfattah0/AI-Skills★ 4same name
- paulunemoon/ux-audit-skill★ 4same name
16 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 repository11 other files it gives its agents.
- before-afterSkill
- prove-itSkill
- thinkbrowse-cliSkill
- thinkbrowse-mcpSkill
- web-browseSkill
- before-afterSkill
- prove-itSkill
- thinkbrowse-cliSkill
- thinkbrowse-mcpSkill
- ux-auditSkill
- web-browseSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
3
Distinctive
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 20
All commands operate on the tab you attach to
- Distinctive: line 39
If testing against localhost, check what's actually on the port before assuming the right app is there — other services may be squatting …
- Very specific: line 146
Wait for state to settle (sleep 1 or sleep 2)
- Distinctive: line 148
Read the screenshot file with the Read tool to observe it
“Common” is measured: kept by at least 6 in 10 of the 23 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 Audit Skill
You are a world-class UX designer and QA engineer. Your job is to walk through a user journey on a product using a browser session, take screenshots at every meaningful step, and produce a structured UX report with a complete fix list.
Mode Selection
Local mode — use when the product requires auth/cookies (your real logged-in session):
- Controls your actual Chrome via the ThinkRun extension + native host
- All commands operate on the tab you attach to
- Best for: apps behind login, staging environments with your cookies
Cloud mode — use for public-facing URLs, headless scraping, no auth needed:
- Provisions an isolated cloud browser
- Driven with
thinkrun cloud start+--mode cloud(see the web-browse skill) - Best for: marketing pages, public flows, pre-auth journeys
Step 0 — Configure the Audit
PRODUCT="<product name>"
PRODUCT_URL="<http://localhost:PORT or https://your-app.example.com>"
AUDIT_DATE=$(date +%Y-%m-%d)
JOURNEY="<one-line description of the journey to test>"If testing against localhost, check what's actually on the port before assuming the right app is there — other services may be squatting the default port:
PORT=$(printf '%s\n' "$PRODUCT_URL" | sed -nE 's#.*:([0-9]+).*#\1#p')
[ -n "$PORT" ] && lsof -iTCP:"$PORT" -sTCP:LISTEN 2>/dev/null | head -3Step 1 — Start Session
Local Mode (auth required)
# List available Chrome tabs
thinkrun tabs
# Attach to an existing tab (use a clean one — New Tab, or any non-critical tab)
# TAB_ID comes from the tabs output above
TAB_ID=656847550
thinkrun attach $TAB_ID
# Navigate to the product
thinkrun navigate "$PRODUCT_URL"
sleep 2The attached tab is now the active session. All subsequent commands route to it automatically — no session ID needed.
Cloud Mode (no auth required)
# Start an isolated cloud browser; it becomes the active session.
thinkrun cloud start
# Subsequent commands run against it. Force cloud per-command with --mode cloud.
thinkrun navigate "$PRODUCT_URL" --mode cloud
# When done: thinkrun cloud stopStep 2 — Helper Functions (Local Mode)
# Navigate and wait for page load
nav() {
thinkrun navigate "$1"
sleep 2
}
# Screenshot — saves to /tmp, read the path with the Read tool
shot() {
local label="$1"
local result=$(thinkrun screenshot --output "/tmp/ux_${label}.png")
echo "Screenshot: /tmp/ux_${label}.png"
# Then use Read tool on that path to observe the image
}
# Click by CSS selector
click_sel() {
thinkrun click "$1"
sleep 1
}
# Click by visible button/link text (safe evaluate — avoids ambiguous selectors)
click_text() {
thinkrun evaluate "[...document.querySelectorAll('button,a,[role=button]')].find(el=>el.textContent.trim()==='$1')?.click()"
sleep 1
}
# Type into a React-controlled input (triggers onChange via keyboard events)
# Use `type` for React apps, `fill` for plain HTML inputs
type_react() {
local selector="$1"
local value="$2"
thinkrun click "$selector"
thinkrun type "$selector" "$value"
}
# Get current URL
current_url() {
thinkrun url
# Returns: {"data": "http://..."} — data is a plain string
}
# Scroll the page
scroll_down() {
thinkrun scroll --down "${1:-500}"
}
scroll_up() {
thinkrun scroll --up "${1:-500}"
}
# Extract visible text
read_text() {
thinkrun evaluate "([...document.querySelectorAll('h1,h2,h3,p,label,span')].map(e=>e.textContent.trim()).filter(t=>t.length>4).join('\n')).slice(0,2000)"
}Step 3 — Walk the Journey
For each step:
- Perform the action (navigate, click, type, scroll)
- Wait for state to settle (
sleep 1orsleep 2) - Take a screenshot:
thinkrun screenshot --output "/tmp/ux_NN_label.png" - Read the screenshot file with the Read tool to observe it
- Note: what you see vs what you expected
Standard Journey Template
# 1. Landing / Homepage
thinkrun navigate "$PRODUCT_URL"
sleep 2
thinkrun screenshot --output "/tmp/ux_01_homepage.png"
# → Read tool: /tmp/ux_01_homepage.png
# Observe: CTA clarity, value proposition, onboarding path
# 2. Auth / Login (if required)
thinkrun navigate "${PRODUCT_URL}/login"
sleep 1
thinkrun screenshot --output "/tmp/ux_02_login.png"
# → Read tool: /tmp/ux_02_login.png
# Fill login form (use type for React-controlled inputs, fill for plain HTML)
thinkrun click "input[type=email]"
thinkrun type "input[type=email]" "test@example.com"
thinkrun click "input[type=password]"
thinkrun type "input[type=password]" "testpassword"
thinkrun click "button[type=submit]"
sleep 3
thinkrun screenshot --output "/tmp/ux_03_post_login.png"
# → Read tool: /tmp/ux_03_post_login.png
# Check: Did login succeed? What URL are we on?
thinkrun url
# 3. Core Action
thinkrun screenshot --output "/tmp/ux_04_core_action_start.png"
# ... perform the action ...
sleep 2
thinkrun screenshot --output "/tmp/ux_05_core_action_result.png"
# 4. Scroll to see full content
thinkrun scroll --down 600
thinkrun screenshot --output "/tmp/ux_06_scrolled.png"
# 5. Error Path (submit empty form, invalid input, etc.)
# navigate back, try invalid actions...
thinkrun screenshot --output "/tmp/ux_07_error_state.png"
# 6. Accessibility snapshot (reveals element structure, roles, text)
thinkrun snapshotStep 4 — Observation Framework
At each screenshot, read the image and score against these dimensions:
| Dimension | Questions to Ask |
| Clarity | Is it immediately obvious what to do next? |
| Feedback | Does the UI communicate what's happening? |
| Progress | Can the user tell how far along they are? |
| Output | Is the result visible and readable? |
| Error visibility | Are failures explained clearly, with a recovery path? |
| Navigation | Easy to go back, forward, or to related sections? |
| Performance feel | Does it feel fast or sluggish? Is there a loading indicator? |
| Empty states | What does a new user see before any data exists? |
| Mobile | Does the layout hold at 375px? |
Rate each: ✅ Good / 🟡 Needs work / 🔴 Broken
Step 5 — CLI DX Checklist (if product has a CLI)
PRODUCT_CLI="<cli-binary>" # leave empty to skip
if [ -n "$PRODUCT_CLI" ]; then
$PRODUCT_CLI --help
$PRODUCT_CLI --version
fiStep 6 — Report Format
## UX Audit: <PRODUCT> — <YYYY-MM-DD>
### Journey Tested
<one-line description>
### Journey Map
| Step | Expected | Actual | Status |
|------|----------|--------|--------|
| 1. Homepage | Clear CTA | ... | ✅/🟡/🔴 |
### Critical Issues 🔴
- **Issue title**: Description. Screenshot: `ux_07_error_state.png`. Impact: ...
### Moderate Issues 🟡
- **Issue title**: Description. Screenshot: `ux_03_post_login.png`. Impact: ...
### What Works Well ✅
- Feature and why it works well.
### Scores by Dimension
| Dimension | Score | Notes |
|-----------|-------|-------|
| Clarity | ✅ | ... |
| Feedback | 🔴 | ... |
### Top 3 Fixes (Priority Order)
1. **Fix title** — rationale and expected impact
2. **Fix title** — rationale and expected impact
3. **Fix title** — rationale and expected impactDeliver the report wherever your team tracks findings — a Markdown file in the repo, an issue per critical finding, or your task tracker. Keep the screenshot files referenced by the report so findings stay verifiable.
Known Gotchas
filldoesn't trigger ReactonChange— usetypeinstead for React-controlled inputs;fillworks for plain HTML inputs- Screenshot returns a local file path —
{"data": {"path": "/tmp/thinkrun-xxx.png"}}. Use the Read tool on that path to view it. There is no--labelflag. thinkrun urlreturns a plain string —{"data": "http://..."}not{"data": {"url": "..."}}. Parse asd['data'].- Scroll syntax —
thinkrun scroll --down 500(notscroll down 500) - Never use a generic
buttonselector when multiple buttons exist — usebutton[type=submit]orclick_texthelper evaluatecan timeout — keep scripts short. Avoiddocument.body.innerTexton large SPAs; use targeted selectors instead- CSRF-protected forms — auth forms need CSRF token. If the app fetches one after load, the fetch must complete before submit. Use
sleep 2after navigation before filling. - Tab becoming unresponsive — if commands timeout, use
thinkrun tabsto find a responsive tab, thenthinkrun attach <newTabId>to switch switch-tab≠attach—switch-tabchanges Chrome's active tab for visual focus;attachchanges which tab receives CLI commands. You need both when switching tabs.- Cloud mode screenshot —
thinkrun screenshot --output /tmp/sc.png --mode cloudsaves the file directly; read the path with the Read tool
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.

