ux-compare

Name: ux-compare
Author: jezweb

459installs96forks

How to install ux-compare?

jezweb/claude-skills/ux-compare

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

Installs into the current project.

Summary

Compare UX patterns across multiple reference apps using pattern libraries produced by ux-extract. Reads 2+ pattern-library.md files, walks them category by category, identifies where apps converge (strong signal), where they diverge (genuine design choice), what's unique to one

Files · 1

View on GitHub

SKILL.md

1	# UX Compare
2
3	Read N pattern libraries produced by `ux-extract` and synthesise a comparison. Answers questions like:
4
5	- "Across claude.ai, Linear, Notion, Vercel, and Superhuman — how are empty states handled?"
6	- "Which apps use keyboard shortcuts, and what's the shared vocabulary?"
7	- "When we build our billing page, should we follow convention or deliberately break it?"
8
9	A single extract is a reference point. Multiple extracts are a design library. A comparison is a decision aid — it turns the library into "here's what to do and why".
10
11	## When to use
12
13	- Before a build — comparing 3–5 references for the feature class you're about to build reveals the convention and the tradeoffs
14	- During a design review — "this pattern isn't in any of the 5 references we've extracted — is that deliberate?"
15	- For team alignment — shared reference for a design decision
16	- To produce a design brief — convergent patterns become the baseline; divergent patterns become the discussion
17
18	## Inputs
19
20	### Available libraries
21
22	First, discover what's available. Pattern libraries live at:
23
24	- `docs/ux-extracts/<app-name>/pattern-library.md`
25	- `.jez/artifacts/ux-extracts/<app-name>/pattern-library.md`
26
27	List everything you find. Show the user the inventory with the extraction date for each so they can spot stale ones:
28
29	```
30	Available pattern libraries:
31	- claude.ai (extracted 2026-03-12)
32	- linear.app (extracted 2026-02-28)
33	- notion.so (extracted 2026-01-15) ← 3 months old
34	- superhuman (extracted 2026-03-20)
35	```
36
37	If only one library exists, stop and suggest running `ux-extract` on more apps first. A one-library "comparison" is just the library.
38
39	### Scope / focus
40
41	Ask the user what to compare — or infer from their request:
42
43	- Whole library — compare every category across every library (verbose but comprehensive)
44	- One category — just empty states, just keyboard, just modals (tighter, more useful for specific decisions)
45	- A feature area — "how do these apps handle settings", crosses multiple categories but stays focused
46	- A specific question — "which apps support offline?" — searches Notable Absences sections too
47
48	Narrower scope produces sharper recommendations. Default to asking: "What feature or pattern do you want to compare?"
49
50	### Libraries to include
51
52	By default, include every library the user mentions or all of them if they don't specify. Let them exclude: "all except notion — their library is too stale".
53
54	## Comparison Process
55
56	### 1. Read every library
57
58	For each library in scope, read the full `pattern-library.md`. Note:
59	- Extraction date
60	- Scope of the extract (whole app vs partial)
61	- Any Notable Absences section — often the most interesting data for comparison
62
63	### 2. Walk category by category
64
65	For the scope requested, walk each pattern category that appears in any library. For each category:
66
67	1. List what each app does — one bullet per app, concrete and verbatim where possible
68	2. Identify convergence — what's the same across most or all? This is the low-risk default.
69	3. Identify divergence — where do they genuinely differ? This is a design decision.
70	4. Flag unique approaches — only one app does X. Either innovation or weirdness; call it out either way.
71	5. Flag coverage gaps — if an app's library doesn't cover this category, say so (don't silently treat absent-from-library as absent-from-app).
72
73	### 3. Cross-reference absences
74
75	After walking categories, collect what's absent across the set. If 4 of 5 apps have no undo on destructive actions, that's a pattern. If 3 of 5 apps have no keyboard shortcut for new-record creation, that's a decision someone keeps making.
76
77	### 4. Synthesise recommendations
78
79	Close with opinionated guidance:
80	- Safe default — the convergent pattern. Following it means users feel at home.
81	- Deliberate choices — the divergent patterns, with the tradeoff of each so the user can pick.
82	- Avoid — unique-to-one patterns unless there's a clear reason why that one app does it differently.
83	- Gaps worth filling — absences that are surprising, or that your users would benefit from seeing addressed.
84
85	The recommendations section is the reason to run the comparison. Without it, the doc is a pile of bullets. With it, it's a decision.
86
87	## Output
88
89	Write to `docs/ux-comparisons/<topic>-YYYY-MM-DD.md` (or

People who liked this also viewed

6 picks

Type

ux-compare

459installs96forks

View on GitHub

How to install ux-compare?

jezweb/claude-skills/ux-compare

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# UX Compare
2
3	Read N pattern libraries produced by `ux-extract` and synthesise a comparison. Answers questions like:
4
5	- "Across claude.ai, Linear, Notion, Vercel, and Superhuman — how are empty states handled?"
6	- "Which apps use keyboard shortcuts, and what's the shared vocabulary?"
7	- "When we build our billing page, should we follow convention or deliberately break it?"
8
9	A single extract is a reference point. Multiple extracts are a design library. A comparison is a decision aid — it turns the library into "here's what to do and why".
10
11	## When to use
12
13	- Before a build — comparing 3–5 references for the feature class you're about to build reveals the convention and the tradeoffs
14	- During a design review — "this pattern isn't in any of the 5 references we've extracted — is that deliberate?"
15	- For team alignment — shared reference for a design decision
16	- To produce a design brief — convergent patterns become the baseline; divergent patterns become the discussion
17
18	## Inputs
19
20	### Available libraries
21
22	First, discover what's available. Pattern libraries live at:
23
24	- `docs/ux-extracts/<app-name>/pattern-library.md`
25	- `.jez/artifacts/ux-extracts/<app-name>/pattern-library.md`
26
27	List everything you find. Show the user the inventory with the extraction date for each so they can spot stale ones:
28
29	```
30	Available pattern libraries:
31	- claude.ai (extracted 2026-03-12)
32	- linear.app (extracted 2026-02-28)
33	- notion.so (extracted 2026-01-15) ← 3 months old
34	- superhuman (extracted 2026-03-20)
35	```
36
37	If only one library exists, stop and suggest running `ux-extract` on more apps first. A one-library "comparison" is just the library.
38
39	### Scope / focus
40
41	Ask the user what to compare — or infer from their request:
42
43	- Whole library — compare every category across every library (verbose but comprehensive)
44	- One category — just empty states, just keyboard, just modals (tighter, more useful for specific decisions)
45	- A feature area — "how do these apps handle settings", crosses multiple categories but stays focused
46	- A specific question — "which apps support offline?" — searches Notable Absences sections too
47
48	Narrower scope produces sharper recommendations. Default to asking: "What feature or pattern do you want to compare?"
49
50	### Libraries to include
51
52	By default, include every library the user mentions or all of them if they don't specify. Let them exclude: "all except notion — their library is too stale".
53
54	## Comparison Process
55
56	### 1. Read every library
57
58	For each library in scope, read the full `pattern-library.md`. Note:
59	- Extraction date
60	- Scope of the extract (whole app vs partial)
61	- Any Notable Absences section — often the most interesting data for comparison
62
63	### 2. Walk category by category
64
65	For the scope requested, walk each pattern category that appears in any library. For each category:
66
67	1. List what each app does — one bullet per app, concrete and verbatim where possible
68	2. Identify convergence — what's the same across most or all? This is the low-risk default.
69	3. Identify divergence — where do they genuinely differ? This is a design decision.
70	4. Flag unique approaches — only one app does X. Either innovation or weirdness; call it out either way.
71	5. Flag coverage gaps — if an app's library doesn't cover this category, say so (don't silently treat absent-from-library as absent-from-app).
72
73	### 3. Cross-reference absences
74
75	After walking categories, collect what's absent across the set. If 4 of 5 apps have no undo on destructive actions, that's a pattern. If 3 of 5 apps have no keyboard shortcut for new-record creation, that's a decision someone keeps making.
76
77	### 4. Synthesise recommendations
78
79	Close with opinionated guidance:
80	- Safe default — the convergent pattern. Following it means users feel at home.
81	- Deliberate choices — the divergent patterns, with the tradeoff of each so the user can pick.
82	- Avoid — unique-to-one patterns unless there's a clear reason why that one app does it differently.
83	- Gaps worth filling — absences that are surprising, or that your users would benefit from seeing addressed.
84
85	The recommendations section is the reason to run the comparison. Without it, the doc is a pile of bullets. With it, it's a decision.
86
87	## Output
88
89	Write to `docs/ux-comparisons/<topic>-YYYY-MM-DD.md` (or

People who liked this also viewed

6 picks

Type