ux-extract

Name: ux-extract
Author: jezweb

459installs96forks

How to install ux-extract?

jezweb/claude-skills/ux-extract

$npx -y skills add jezweb/claude-skills --skill ux-extract

Installs into the current project.

Summary

Exhaustively extract UX patterns from a reference web app. Walks every screen, captures screenshots of every state, records interaction patterns, copy verbatim, keyboard shortcuts, responsive treatments, motion, and empty/error/loading states. Produces a reusable pattern library

Files · 1

View on GitHub

SKILL.md

1	# UX Extract
2
3	Exhaustively study a reference web app and produce a reusable pattern library. Goes everywhere, captures everything, then organises it into a document another audit or build can reference.
4
5	The inverse of `ux-audit`:
6	- Audit asks: does this match a bar?
7	- Extract asks: what is the bar?
8
9	Audits without extracts implicitly compare to "my memory of other apps" — fragile and inconsistent. Extracts turn that memory into a concrete, navigable artifact. An audit can then say: "Empty state on /app/clients shows no CTA. Reference (claude.ai) shows 3 keyboard shortcuts plus 'New chat' in the same position" instead of "feels a bit sparse".
10
11	## When to use
12
13	- Before building a new feature — study how best-in-class apps handle it
14	- Benchmarking a build — extract the reference, then audit against it
15	- Onboarding designers or engineers — here's what good looks like, concretely
16	- Competitor research — document the competitor's UX so you can meaningfully differentiate
17	- Refreshing an old app — extract patterns from modern equivalents to guide the update
18
19	## Scope and ethics
20
21	Before starting, confirm the target is fair game:
22
23	1. Use your own account — don't scrape anything that requires credentials you don't legitimately hold
24	2. Respect `robots.txt` for unauthenticated crawling
25	3. Rate-limit — act like a human user, not a crawler. Pause between pages.
26	4. Check ToS — most SaaS Terms of Service permit individual inspection but prohibit automated scraping
27	5. Don't redistribute screenshots of a live competitor's app publicly — pattern libraries are internal references
28
29	If the target is behind a paywall or requires a trial account, ask the user whether they have legitimate access before proceeding.
30
31	## Setup
32
33	### 1. Browser tool
34
35	\| Target \| Tool \| Notes \|
36	\|--------\|------\|-------\|
37	\| Authenticated reference (you have an account) \| Chrome MCP \| Uses your logged-in session \|
38	\| Public reference (marketing pages, docs, public demos) \| Playwright MCP \| No login needed \|
39
40	See [../ux-audit/references/browser-tools.md](../ux-audit/references/browser-tools.md) for commands.
41
42	### 2. Viewport
43
44	Pin 1440×900 as baseline (MacBook standard). Also capture 768 and 375 for responsive patterns. Don't exceed 2000px wide.
45
46	### 2b. Screenshot post-processing
47
48	On Retina Macs, Chrome captures at 2× the logical viewport — a 1440-wide window produces a 2880-wide PNG. Post-process after each batch so the library isn't full of oversized files:
49
50	```bash
51	img-process batch ./screenshots --action optimise --max-width 1440
52	```
53
54	Idempotent — no-op on already-small files. Run at the end of each route's capture, or across the whole `screenshots/` folder at the end of the extract. Playwright MCP users can set `deviceScaleFactor: 1` in the context options and skip this step.
55
56	### 3. Scope
57
58	Decide before starting:
59
60	- Whole app — traverse everything reachable (can take hours, produces a comprehensive library)
61	- Feature area — one section ("the settings flow", "the dashboard", "the billing flow")
62	- Pattern class — just empty states, just error handling, just onboarding
63
64	Narrower scope produces tighter, more useful libraries. "Whole app" is only worth it for apps you'll be building a direct analogue of.
65
66	### 4. Focus lens (optional)
67
68	Optional bias for capture. Examples:
69	- "Focus on patterns for data-heavy lists" — prioritise table, filter, search, virtualisation screenshots
70	- "Focus on onboarding and empty states" — prioritise first-run flows and zero-data views
71	- "Focus on permission boundaries" — log in as multiple roles, document the differences
72
73	If no focus is given, capture broadly.
74
75	## Discovery
76
77	### Sitemap crawl
78
79	Build the full route inventory:
80
81	1. Public sitemap — check `/sitemap.xml`, `/robots.txt` for discoverability
82	2. Nav crawl — click through every section visible in the top nav, sidebar, footer
83	3. In-app discovery — once inside, note every link that appears (breadcrumbs, tabs, contextual menus)
84	4. URL inspection — some apps have useful patterns in `/settings`, `/preferences`, `/admin` that aren't in the main nav
85
86	Record each route with its purpose: `/settings/billing — subscription plan, payment method, invoice history`.
87
88	### Pattern inventory
89
90	Before deep-capture, scan the app once and list pattern types you'll document. Typical categorie

People who liked this also viewed

6 picks

Type

ux-extract

459installs96forks

View on GitHub

How to install ux-extract?

jezweb/claude-skills/ux-extract

$npx -y skills add jezweb/claude-skills --skill ux-extract

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# UX Extract
2
3	Exhaustively study a reference web app and produce a reusable pattern library. Goes everywhere, captures everything, then organises it into a document another audit or build can reference.
4
5	The inverse of `ux-audit`:
6	- Audit asks: does this match a bar?
7	- Extract asks: what is the bar?
8
9	Audits without extracts implicitly compare to "my memory of other apps" — fragile and inconsistent. Extracts turn that memory into a concrete, navigable artifact. An audit can then say: "Empty state on /app/clients shows no CTA. Reference (claude.ai) shows 3 keyboard shortcuts plus 'New chat' in the same position" instead of "feels a bit sparse".
10
11	## When to use
12
13	- Before building a new feature — study how best-in-class apps handle it
14	- Benchmarking a build — extract the reference, then audit against it
15	- Onboarding designers or engineers — here's what good looks like, concretely
16	- Competitor research — document the competitor's UX so you can meaningfully differentiate
17	- Refreshing an old app — extract patterns from modern equivalents to guide the update
18
19	## Scope and ethics
20
21	Before starting, confirm the target is fair game:
22
23	1. Use your own account — don't scrape anything that requires credentials you don't legitimately hold
24	2. Respect `robots.txt` for unauthenticated crawling
25	3. Rate-limit — act like a human user, not a crawler. Pause between pages.
26	4. Check ToS — most SaaS Terms of Service permit individual inspection but prohibit automated scraping
27	5. Don't redistribute screenshots of a live competitor's app publicly — pattern libraries are internal references
28
29	If the target is behind a paywall or requires a trial account, ask the user whether they have legitimate access before proceeding.
30
31	## Setup
32
33	### 1. Browser tool
34
35	\| Target \| Tool \| Notes \|
36	\|--------\|------\|-------\|
37	\| Authenticated reference (you have an account) \| Chrome MCP \| Uses your logged-in session \|
38	\| Public reference (marketing pages, docs, public demos) \| Playwright MCP \| No login needed \|
39
40	See [../ux-audit/references/browser-tools.md](../ux-audit/references/browser-tools.md) for commands.
41
42	### 2. Viewport
43
44	Pin 1440×900 as baseline (MacBook standard). Also capture 768 and 375 for responsive patterns. Don't exceed 2000px wide.
45
46	### 2b. Screenshot post-processing
47
48	On Retina Macs, Chrome captures at 2× the logical viewport — a 1440-wide window produces a 2880-wide PNG. Post-process after each batch so the library isn't full of oversized files:
49
50	```bash
51	img-process batch ./screenshots --action optimise --max-width 1440
52	```
53
54	Idempotent — no-op on already-small files. Run at the end of each route's capture, or across the whole `screenshots/` folder at the end of the extract. Playwright MCP users can set `deviceScaleFactor: 1` in the context options and skip this step.
55
56	### 3. Scope
57
58	Decide before starting:
59
60	- Whole app — traverse everything reachable (can take hours, produces a comprehensive library)
61	- Feature area — one section ("the settings flow", "the dashboard", "the billing flow")
62	- Pattern class — just empty states, just error handling, just onboarding
63
64	Narrower scope produces tighter, more useful libraries. "Whole app" is only worth it for apps you'll be building a direct analogue of.
65
66	### 4. Focus lens (optional)
67
68	Optional bias for capture. Examples:
69	- "Focus on patterns for data-heavy lists" — prioritise table, filter, search, virtualisation screenshots
70	- "Focus on onboarding and empty states" — prioritise first-run flows and zero-data views
71	- "Focus on permission boundaries" — log in as multiple roles, document the differences
72
73	If no focus is given, capture broadly.
74
75	## Discovery
76
77	### Sitemap crawl
78
79	Build the full route inventory:
80
81	1. Public sitemap — check `/sitemap.xml`, `/robots.txt` for discoverability
82	2. Nav crawl — click through every section visible in the top nav, sidebar, footer
83	3. In-app discovery — once inside, note every link that appears (breadcrumbs, tabs, contextual menus)
84	4. URL inspection — some apps have useful patterns in `/settings`, `/preferences`, `/admin` that aren't in the main nav
85
86	Record each route with its purpose: `/settings/billing — subscription plan, payment method, invoice history`.
87
88	### Pattern inventory
89
90	Before deep-capture, scan the app once and list pattern types you'll document. Typical categorie

People who liked this also viewed

6 picks

Type