@nqlib/nqui 0.5.6 → 0.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/{command-palette-DhoWGyk_.js → command-palette-CHUiGh5m.js} +2 -2
- package/dist/{command-palette-D24rOeE6.cjs → command-palette-DsvP2QNP.cjs} +2 -2
- package/dist/command.cjs.js +1 -1
- package/dist/command.es.js +1 -1
- package/dist/components/custom/table-of-contents.d.ts +2 -2
- package/dist/components/custom/table-of-contents.d.ts.map +1 -1
- package/dist/components/index.d.ts +3 -0
- package/dist/components/index.d.ts.map +1 -1
- package/dist/components/theme-appearance-menu.d.ts +9 -0
- package/dist/components/theme-appearance-menu.d.ts.map +1 -0
- package/dist/components/theme-toggle.d.ts +2 -0
- package/dist/components/theme-toggle.d.ts.map +1 -0
- package/dist/components/ui/checkbox.d.ts.map +1 -1
- package/dist/components/ui/combobox.d.ts +5 -3
- package/dist/components/ui/combobox.d.ts.map +1 -1
- package/dist/components/ui/toggle-group.d.ts.map +1 -1
- package/dist/{debug-panel-BjfW-YVo.js → debug-panel-BcYzsTp2.js} +1 -1
- package/dist/{debug-panel-CpqsKuxd.cjs → debug-panel-mwtujy5J.cjs} +1 -1
- package/dist/debug.cjs.js +1 -1
- package/dist/debug.es.js +1 -1
- package/dist/elevation-debate.html +286 -0
- package/dist/{input-shared-CDgy_NdJ.cjs → input-shared-C9Try5fg.cjs} +1 -1
- package/dist/{input-shared-NnOiyHpu.js → input-shared-DXf3Edqt.js} +1 -1
- package/dist/lib/floating-surface.d.ts +6 -2
- package/dist/lib/floating-surface.d.ts.map +1 -1
- package/dist/nqui.cjs.js +15 -13
- package/dist/nqui.es.js +2752 -2646
- package/dist/styles.css +151 -255
- package/docs/components/README.md +4 -1
- package/docs/components/nqui-combobox.md +15 -2
- package/docs/components/nqui-command-palette.md +7 -0
- package/docs/components/nqui-command.md +41 -0
- package/docs/components/nqui-scroll-area.md +69 -0
- package/docs/nqui-skills/AGENT_PROMPT.md +190 -0
- package/docs/nqui-skills/COMPONENTS_INDEX.md +51 -1
- package/docs/nqui-skills/COMPOSITION.md +321 -0
- package/docs/nqui-skills/ELEVATION.md +181 -0
- package/docs/nqui-skills/EVAL.md +148 -0
- package/docs/nqui-skills/HUMAN_GUIDE.md +18 -0
- package/docs/nqui-skills/MIGRATION.md +133 -0
- package/docs/nqui-skills/MOTION.md +189 -0
- package/docs/nqui-skills/README.md +2 -0
- package/docs/nqui-skills/READ_BUDGET.md +60 -0
- package/docs/nqui-skills/RECIPES.md +820 -0
- package/docs/nqui-skills/SKILL.md +58 -1
- package/docs/nqui-skills/STATES.md +154 -0
- package/docs/nqui-skills/THEMING.md +203 -0
- package/docs/nqui-skills/WRITING.md +205 -0
- package/docs/nqui-skills/_claude-commands/README.md +50 -0
- package/docs/nqui-skills/_claude-commands/design/SKILL.md +111 -0
- package/docs/nqui-skills/_claude-commands/edit/SKILL.md +97 -0
- package/docs/nqui-skills/adapt/SKILL.md +5 -2
- package/docs/nqui-skills/animate/SKILL.md +5 -2
- package/docs/nqui-skills/audit/SKILL.md +5 -2
- package/docs/nqui-skills/bolder/SKILL.md +5 -2
- package/docs/nqui-skills/clarify/SKILL.md +5 -2
- package/docs/nqui-skills/colorize/SKILL.md +5 -2
- package/docs/nqui-skills/delight/SKILL.md +5 -4
- package/docs/nqui-skills/distill/SKILL.md +5 -2
- package/docs/nqui-skills/impeccable/SKILL.md +0 -16
- package/docs/nqui-skills/impeccable/reference/INDEX.md +26 -0
- package/docs/nqui-skills/layout/SKILL.md +5 -2
- package/docs/nqui-skills/nqui-components/SKILL.md +33 -9
- package/docs/nqui-skills/nqui-composition/SKILL.md +148 -0
- package/docs/nqui-skills/nqui-data-tables/SKILL.md +127 -0
- package/docs/nqui-skills/nqui-design-system/SKILL.md +22 -1
- package/docs/nqui-skills/nqui-install/SKILL.md +1 -0
- package/docs/nqui-skills/overdrive/SKILL.md +5 -2
- package/docs/nqui-skills/polish/SKILL.md +5 -4
- package/docs/nqui-skills/quieter/SKILL.md +5 -2
- package/docs/nqui-skills/shape/SKILL.md +5 -2
- package/docs/nqui-skills/typeset/SKILL.md +5 -2
- package/package.json +2 -1
- package/scripts/build-styles.js +4 -3
- package/scripts/cli.js +2 -0
- package/scripts/install-claude-skills.js +148 -0
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Claude Code slash commands shipped with nqui
|
|
2
|
+
|
|
3
|
+
This folder contains the **slash command entry points** that the `init-claude-skills` CLI installs into `~/.claude/skills/` on a consumer machine. These become invocable as `/design` and `/edit` inside Claude Code and Claude Desktop after install.
|
|
4
|
+
|
|
5
|
+
## How a consumer installs (once they `pnpm install`)
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
pnpm install @nqlib/nqui # install the library
|
|
9
|
+
npx @nqlib/nqui init-claude-skills # install Claude Code skills to ~/.claude/skills
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
What that command does:
|
|
13
|
+
1. Copies all 15 root docs (SKILL.md, AGENT_PROMPT.md, ELEVATION.md, MOTION.md, RECIPES.md, STATES.md, WRITING.md, EVAL.md, THEMING.md, MIGRATION.md, COMPOSITION.md, COMPONENTS_INDEX.md, HUMAN_GUIDE.md, READ_BUDGET.md, README.md) → `~/.claude/skills/nqui/`
|
|
14
|
+
2. Copies all subdirectory skills (nqui-composition, nqui-components, nqui-design-system, nqui-shadcn, impeccable, audit, layout, polish, etc.) → `~/.claude/skills/<skill-name>/`
|
|
15
|
+
3. Copies all 68 per-component docs → `~/.claude/skills/nqui/components/`
|
|
16
|
+
4. Copies the slash command skills (this folder) → `~/.claude/skills/design/` and `~/.claude/skills/edit/`
|
|
17
|
+
|
|
18
|
+
After install, the consumer restarts Claude Code, and `/design` and `/edit` become available as tools.
|
|
19
|
+
|
|
20
|
+
## What `/design` does
|
|
21
|
+
|
|
22
|
+
When the user types `/design [a login form]` (or any UI build request), the agent:
|
|
23
|
+
|
|
24
|
+
1. Loads `AGENT_PROMPT.md` (the non-negotiable rules)
|
|
25
|
+
2. Loads design context from `.impeccable.md` (or asks the user if missing)
|
|
26
|
+
3. Picks a named layout pattern from `COMPOSITION.md`
|
|
27
|
+
4. Pulls combos from `RECIPES.md`
|
|
28
|
+
5. Applies the elevation rule (2+1 surfaces), state matrix, writing rules
|
|
29
|
+
6. Runs the 30-second Linear designer self-review
|
|
30
|
+
7. Ships work that's reliably 8/10 or better
|
|
31
|
+
|
|
32
|
+
## What `/edit` does
|
|
33
|
+
|
|
34
|
+
When the user points at existing UI (`/edit the sprint tracker page`), the agent:
|
|
35
|
+
|
|
36
|
+
1. Reads the target file(s)
|
|
37
|
+
2. Diagnoses against the design rules (elevation / states / writing / motion / composition / anti-patterns)
|
|
38
|
+
3. Names findings as P0/P1/P2 with file:line locations
|
|
39
|
+
4. Proposes minimum-viable fixes
|
|
40
|
+
5. Applies them via Edit tool, citing which rule each fix maps to
|
|
41
|
+
|
|
42
|
+
Different from `/design` (which builds from scratch).
|
|
43
|
+
|
|
44
|
+
## Updating the slash commands
|
|
45
|
+
|
|
46
|
+
The source of truth lives in this folder (`docs/nqui-skills/_claude-commands/`). Edit `design/SKILL.md` or `edit/SKILL.md` here; the next `init-claude-skills` run propagates changes.
|
|
47
|
+
|
|
48
|
+
## Why both files live in the package, not just in `~/.claude/skills/`
|
|
49
|
+
|
|
50
|
+
So consumers get the same versioned slash commands every install. The local `~/.claude/skills/` copy can drift (manual edits, partial deletes); the package source is the canonical version that ships with each nqui release.
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design
|
|
3
|
+
description: Build a new product UI screen/page/feature with @nqlib/nqui. Apple-inspired craft, 2+1 elevation rule, full state coverage, restrained motion. Use when the user says "design", "build", "create a page", "make a screen", or any new-UI request. Loads the full nqui skill chain and follows the Agent Build Protocol from start to finish.
|
|
4
|
+
argument-hint: "[what to build, e.g. 'a login form' or 'a sprint dashboard']"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /design — Build with nqui
|
|
8
|
+
|
|
9
|
+
This is the **canonical entry point** for any UI build request when nqui is available. It orchestrates the full skill chain (composition → patterns → recipes → components) and produces production-quality output.
|
|
10
|
+
|
|
11
|
+
## What this skill does
|
|
12
|
+
|
|
13
|
+
When invoked, you build a new UI surface using `@nqlib/nqui` following the **Agent Build Protocol** (10 steps) and the **30-second Linear designer test** before declaring done.
|
|
14
|
+
|
|
15
|
+
The output bar: a senior Linear / Vercel / Stripe / Apple designer reviewing your diff would find **zero** AI-flavored cues (nested cards, "Submit" buttons, missing empty states, decorative shadows, generic copy).
|
|
16
|
+
|
|
17
|
+
## Mandatory protocol
|
|
18
|
+
|
|
19
|
+
### Step 1 — Load the entry contract
|
|
20
|
+
Read `~/.claude/skills/nqui/AGENT_PROMPT.md` if you have not in this conversation. This is the non-negotiable rule set: hard rules, anti-patterns, build flow. Don't skip it.
|
|
21
|
+
|
|
22
|
+
### Step 2 — Load design context
|
|
23
|
+
Check for `.impeccable.md` in the project root.
|
|
24
|
+
- If present: use that brand/voice/aesthetic context.
|
|
25
|
+
- If absent: ASK the user for brand tone, target audience, and any reference apps. Do not infer from the codebase — code tells you what was built, not who it's for.
|
|
26
|
+
|
|
27
|
+
### Step 3 — Understand the user's job (5-word outcome)
|
|
28
|
+
- One sentence: what is the outcome of this screen?
|
|
29
|
+
- One primary action?
|
|
30
|
+
- What can move off-screen (Sheet, route, hover card)?
|
|
31
|
+
|
|
32
|
+
If the user's request is vague ("build me a dashboard"), ask 2-3 clarifying questions before writing code. Generic prompts produce generic output.
|
|
33
|
+
|
|
34
|
+
### Step 4 — Pick a named layout pattern
|
|
35
|
+
Read `~/.claude/skills/nqui/COMPOSITION.md` and match the request to one of the named patterns:
|
|
36
|
+
- App Shell (sidebar + content)
|
|
37
|
+
- Settings page
|
|
38
|
+
- Dashboard (metrics + table/chart)
|
|
39
|
+
- Master-Detail Split (responsive → Sheet below 900px)
|
|
40
|
+
- Wizard / Stepper
|
|
41
|
+
- Command / Search Interface
|
|
42
|
+
- Form Dialog
|
|
43
|
+
|
|
44
|
+
Commit to one. Don't blend.
|
|
45
|
+
|
|
46
|
+
### Step 5 — Look up combos in RECIPES.md
|
|
47
|
+
Read `~/.claude/skills/nqui/RECIPES.md` and grab the specific recipes you need (status pill, bulk action, filter toolbar, the three states, auth recipes 16-22 for login/signup, etc.). Don't reinvent — use the canonical blueprints.
|
|
48
|
+
|
|
49
|
+
### Step 6 — Apply the elevation rule
|
|
50
|
+
Read `~/.claude/skills/nqui/ELEVATION.md`. Cap inline nesting at **2 surfaces**: page (`bg-background`) → card (`bg-muted/40`). Past that, use spacing + uppercase labels + type weight. `bg-popover` + `.nqui-elevated` is for Dialog / Sheet / Popover / DropdownMenu only.
|
|
51
|
+
|
|
52
|
+
### Step 7 — Cover all states
|
|
53
|
+
Read `~/.claude/skills/nqui/STATES.md`. For every interactive surface, design:
|
|
54
|
+
- Lists: idle + loading (Skeleton) + empty (Empty w/ CTA) + error (Alert w/ retry)
|
|
55
|
+
- Forms: idle + focus + filled + submitting + validation-error + server-error + success
|
|
56
|
+
- Buttons: idle + hover + focus + active + disabled + loading
|
|
57
|
+
- Async views: loading + populated + empty + error + refreshing
|
|
58
|
+
|
|
59
|
+
**No blank screens. No happy-path-only views.**
|
|
60
|
+
|
|
61
|
+
### Step 8 — Write the copy properly
|
|
62
|
+
Read `~/.claude/skills/nqui/WRITING.md`. Every button, label, error, empty state, toast must:
|
|
63
|
+
- Specific verb + object ("Send invite", not "Submit")
|
|
64
|
+
- Errors say what + how to fix
|
|
65
|
+
- Sentence case, present tense, no exclamation marks
|
|
66
|
+
- No "Welcome!" / "Awesome!" / "Let's get started!" — these are AI signatures
|
|
67
|
+
- No emoji in UI chrome
|
|
68
|
+
|
|
69
|
+
### Step 9 — Motion only with intent
|
|
70
|
+
Read `~/.claude/skills/nqui/MOTION.md` ONLY if you're adding animation. Default: no motion. When present: 150ms quick / 200ms standard, ease-out for entrances, ease-in for exits. Never bounce/elastic. Respect `prefers-reduced-motion`.
|
|
71
|
+
|
|
72
|
+
### Step 10 — Self-review (the 30-second Linear designer test)
|
|
73
|
+
Before declaring done, walk this checklist:
|
|
74
|
+
1. Hierarchy clear within 2 seconds?
|
|
75
|
+
2. All states designed (not just happy path)?
|
|
76
|
+
3. Copy specific, not generic?
|
|
77
|
+
4. One primary action per surface?
|
|
78
|
+
5. Spacing varied (not monotonous)?
|
|
79
|
+
6. Cards used only for bounded topics?
|
|
80
|
+
7. Focus styles on every interactive element?
|
|
81
|
+
8. No decorative shadows on flat elements?
|
|
82
|
+
9. No nested cards inside cards?
|
|
83
|
+
10. No banned anti-patterns (border-l-4 stripes, gradient text, hero metrics, "Submit" buttons)?
|
|
84
|
+
|
|
85
|
+
**If you can name 2+ failures → fix them BEFORE asking the user.**
|
|
86
|
+
|
|
87
|
+
## Routing reference
|
|
88
|
+
|
|
89
|
+
If uncertain at any step, the doc to load is in `~/.claude/skills/nqui/READ_BUDGET.md`. Don't bulk-read the skills folder.
|
|
90
|
+
|
|
91
|
+
## What you do NOT do in /design
|
|
92
|
+
|
|
93
|
+
- Don't ship a single happy-path view without the other states
|
|
94
|
+
- Don't invent custom CSS where a component exists
|
|
95
|
+
- Don't add transitions "to feel modern" — most state changes should not animate
|
|
96
|
+
- Don't ask "is this OK?" when you can name 2+ failures from the self-review
|
|
97
|
+
- Don't deliver work that would trigger any of the 10 "Linear designer" reactions
|
|
98
|
+
|
|
99
|
+
## What you DO in /design
|
|
100
|
+
|
|
101
|
+
- Cite which named pattern + which recipes you used (helps the user understand the choices)
|
|
102
|
+
- Apply the surface rule strictly (count surfaces before declaring done — never more than 2 inline)
|
|
103
|
+
- Use real-feeling content (not lorem ipsum, not "Card Title 1 / Card Title 2")
|
|
104
|
+
- Test the responsive split if using master-detail (does it switch to Sheet below 900px?)
|
|
105
|
+
- Verify accessibility minimums (focus visible, ARIA on interactive non-buttons, no tooltip-as-label)
|
|
106
|
+
|
|
107
|
+
## The promise
|
|
108
|
+
|
|
109
|
+
Output from `/design` is reliably 8/10 or better. Not 10/10 (that requires design context this skill can't infer alone), but never embarrassing, never AI-flavored, never missing critical states.
|
|
110
|
+
|
|
111
|
+
That's the bar. Hit it on every invocation.
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: edit
|
|
3
|
+
description: Refine, fix, or improve existing UI built with @nqlib/nqui. Diagnoses issues against the design rules (elevation, states, writing, motion), then applies the smallest fix that resolves them. Use when the user says "fix this", "improve this", "this looks off", "edit", "refine", or references a specific page/component that needs polish. Different from /design (which builds from scratch) — /edit changes what's already there.
|
|
4
|
+
argument-hint: "[what to fix, e.g. 'the sprint tracker page' or 'this dialog']"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /edit — Refine existing nqui UI
|
|
8
|
+
|
|
9
|
+
This is the **canonical entry point** for fixing or improving UI that's already in the codebase. It runs a diagnostic pass against the nqui design rules, names what's wrong specifically, then applies the smallest fix.
|
|
10
|
+
|
|
11
|
+
Different from `/design`:
|
|
12
|
+
- `/design` = build from scratch (Agent Build Protocol, 10 steps)
|
|
13
|
+
- `/edit` = read what's there, diagnose, fix in place
|
|
14
|
+
|
|
15
|
+
## Mandatory protocol
|
|
16
|
+
|
|
17
|
+
### Step 1 — Load the entry contract (skip if loaded this session)
|
|
18
|
+
Read `~/.claude/skills/nqui/AGENT_PROMPT.md`. The rules you'll judge the existing code against.
|
|
19
|
+
|
|
20
|
+
### Step 2 — Read the target
|
|
21
|
+
- If the user named a file/component: read it.
|
|
22
|
+
- If the user pointed at a page route: find the page file in `src/pages/` (or wherever the project keeps them) and read it.
|
|
23
|
+
- Read enough context to understand the surrounding components/layout, not just the line they're complaining about.
|
|
24
|
+
|
|
25
|
+
### Step 3 — Diagnose against the design rules
|
|
26
|
+
Walk the code mentally against these checks (skip checks the user explicitly excluded):
|
|
27
|
+
|
|
28
|
+
| Rule | What to look for | Doc |
|
|
29
|
+
|------|------------------|-----|
|
|
30
|
+
| **Elevation** | Cards inside cards inside cards? `bg-muted/60` or `bg-muted/70` (third surface)? `shadow-*` on inline cards? | `ELEVATION.md` |
|
|
31
|
+
| **State coverage** | Lists without empty/loading/error? Buttons without loading state? Forms without validation states? | `STATES.md` |
|
|
32
|
+
| **Composition** | More than 3 surfaces on screen? Two competing primary buttons? Toolbar floating on bg-background? | `COMPOSITION.md` |
|
|
33
|
+
| **Writing** | "Submit" / "OK" / "Are you sure?"? Exclamation marks? "Welcome!" / "Awesome!"? Generic errors? | `WRITING.md` |
|
|
34
|
+
| **Motion** | Elastic/bounce easing? Durations > 250ms for routine state changes? Animating layout properties? | `MOTION.md` |
|
|
35
|
+
| **Component selection** | RadioGroup in a toolbar? Dialog for a confirmation? Tooltip as the only label? Sheet for >5 fields? | `COMPONENTS_INDEX.md` |
|
|
36
|
+
| **Anti-patterns** | `border-l-4` colored stripes? Gradient text? Hero metric template? Sparklines as decoration? Glassmorphism on inline cards? | `nqui-composition/SKILL.md` |
|
|
37
|
+
|
|
38
|
+
### Step 4 — Name the findings specifically
|
|
39
|
+
Before fixing anything, tell the user what you found. Use this format:
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
Findings (in order of severity):
|
|
43
|
+
|
|
44
|
+
🔴 [P0] {issue} — {file:line}. Why it matters: {one sentence}.
|
|
45
|
+
🟠 [P1] {issue} — {file:line}.
|
|
46
|
+
🟡 [P2] {issue} — {file:line}.
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
P0 = clear rule violation (banned anti-pattern, missing critical state, broken accessibility).
|
|
50
|
+
P1 = noticeable quality issue (wrong component, lazy copy, monotonous spacing).
|
|
51
|
+
P2 = polish (could be tighter, but not embarrassing).
|
|
52
|
+
|
|
53
|
+
If you find nothing: say so. Don't invent issues to look thorough.
|
|
54
|
+
|
|
55
|
+
### Step 5 — Propose minimum-viable fixes
|
|
56
|
+
For each finding, propose the smallest change that resolves it. Don't refactor surrounding code unless the user asked. Examples:
|
|
57
|
+
|
|
58
|
+
- "Submit" → "Send invite" (change 1 word)
|
|
59
|
+
- Nested Cards → outer Card + `<section>` with uppercase label (replace 1 Card pair)
|
|
60
|
+
- Missing empty state → add Empty component with one CTA (insert 8 lines)
|
|
61
|
+
- Bouncy easing → swap to `ease-out` (change 1 className)
|
|
62
|
+
|
|
63
|
+
The goal is **edit, not rewrite**. Honor the existing structure; remove violations.
|
|
64
|
+
|
|
65
|
+
### Step 6 — Apply the fixes
|
|
66
|
+
Apply your proposed fixes via Edit tool. After each change, briefly state what changed and why ("Swapped to `Sheet` because the form has 8 fields — Dialog would feel trapped").
|
|
67
|
+
|
|
68
|
+
### Step 7 — Self-review the edit
|
|
69
|
+
Walk the same diagnostic again post-edit. If new issues surfaced from your fix, name them — don't pretend the edit is done if it created new violations.
|
|
70
|
+
|
|
71
|
+
## What you do NOT do in /edit
|
|
72
|
+
|
|
73
|
+
- Don't rebuild the page. The user said "edit," not "redesign."
|
|
74
|
+
- Don't bundle unrelated improvements ("while I was here I also refactored X"). Stay scoped.
|
|
75
|
+
- Don't fix one violation by introducing another (replacing nested Cards with a 4-color gradient header — that's just a different anti-pattern).
|
|
76
|
+
- Don't skip the diagnostic step ("I'll just fix obvious stuff"). The diagnostic IS the value — naming what's wrong is half the deliverable.
|
|
77
|
+
- Don't ask the user to verify before applying fixes if the fixes are P0 (clearly wrong) and small (< 20 lines). Just do them.
|
|
78
|
+
|
|
79
|
+
## What you DO in /edit
|
|
80
|
+
|
|
81
|
+
- Cite the rule each fix maps to ("removed the third nested Card per ELEVATION.md")
|
|
82
|
+
- Note what you intentionally left alone ("the Card-of-cards on line 80 looks suspect but I'm leaving it — it's a Sortable wrapper, not a hierarchy choice")
|
|
83
|
+
- When the user's complaint is vague ("it looks off"), do the diagnostic first, then offer 2-3 specific options with trade-offs
|
|
84
|
+
|
|
85
|
+
## Triggering examples
|
|
86
|
+
|
|
87
|
+
- "the sprint tracker feels heavy" → /edit, diagnose elevation + spacing + density
|
|
88
|
+
- "this dialog has too many fields" → /edit, suggest Sheet conversion + state coverage check
|
|
89
|
+
- "fix the empty state on the inbox page" → /edit, audit the empty state against STATES.md + WRITING.md
|
|
90
|
+
- "this button feels wrong" → /edit, check component selection + label specificity + state coverage
|
|
91
|
+
- "make this look more Apple" → /edit, diagnose against `nqui-composition/SKILL.md` clarity/deference/depth principles
|
|
92
|
+
|
|
93
|
+
## The promise
|
|
94
|
+
|
|
95
|
+
`/edit` finds the real issues, not imaginary ones. Names them with rules and locations. Fixes them minimally. Leaves the working parts alone.
|
|
96
|
+
|
|
97
|
+
That's the bar.
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target] [context (mobile, tablet, print...)]"
|
|
|
8
8
|
|
|
9
9
|
Adapt existing designs to work effectively across different contexts - different screen sizes, devices, platforms, or use cases.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file. Additionally gather: target platforms/devices and usage contexts.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file. Additionally gather: performance constraints.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -6,9 +6,12 @@ user-invocable: true
|
|
|
6
6
|
argument-hint: "[area (feature, page, component...)]"
|
|
7
7
|
---
|
|
8
8
|
|
|
9
|
-
##
|
|
9
|
+
## Context check (lightweight)
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
Before proceeding, ensure design context is loaded:
|
|
12
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
13
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
14
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file.
|
|
12
15
|
|
|
13
16
|
---
|
|
14
17
|
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file. Additionally gather: audience technical level and users' mental state in context.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file. Additionally gather: existing brand colors.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -8,11 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on a specific topic, see `impeccable/reference/INDEX.md` and load ONE file.
|
|
16
17
|
|
|
17
18
|
## Assess Delight Opportunities
|
|
18
19
|
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -7,22 +7,6 @@ argument-hint: "[craft|teach|extract]"
|
|
|
7
7
|
license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
|
|
8
8
|
---
|
|
9
9
|
|
|
10
|
-
<post-update-cleanup>
|
|
11
|
-
BEFORE doing any design work, run this one-time maintenance step. Tell the user:
|
|
12
|
-
|
|
13
|
-
> **Impeccable was updated.** A few skills were renamed or merged in this version (e.g. `/arrange` is now `/layout`, `/normalize` was folded into `/polish`). I'll clean up the old skill files so they don't clutter your project. This only runs once after an update.
|
|
14
|
-
|
|
15
|
-
Then run:
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
node .agents/skills/impeccable/scripts/cleanup-deprecated.mjs
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
If the script removed files, briefly confirm what was cleaned up. If it found nothing, skip any output and move on.
|
|
22
|
-
|
|
23
|
-
After running the script, delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file so it does not run again until the next update. Save the file.
|
|
24
|
-
</post-update-cleanup>
|
|
25
|
-
|
|
26
10
|
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
|
27
11
|
|
|
28
12
|
## Context Gathering Protocol
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: impeccable-reference-index
|
|
3
|
+
description: One-line summary of each impeccable reference file. Read this before opening any reference file so you load only the topic you need (never all 8).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Impeccable reference — pick ONE
|
|
7
|
+
|
|
8
|
+
The main `impeccable/SKILL.md` covers principles inline. Open a reference file ONLY when you need depth on that specific topic. Never load multiple references at once.
|
|
9
|
+
|
|
10
|
+
| File | Lines | Load when |
|
|
11
|
+
|------|-------|-----------|
|
|
12
|
+
| `typography.md` | 142 | Picking fonts, modular scale ratios, OpenType features, web font loading, line-length calculations |
|
|
13
|
+
| `color-and-contrast.md` | 105 | OKLCH details, WCAG contrast calculation, palette construction beyond the inline `<color_principles>` |
|
|
14
|
+
| `spatial-design.md` | 100 | Grid systems, container queries, optical centering, fluid spacing math |
|
|
15
|
+
| `motion-design.md` | 99 | Easing curves, reduced-motion patterns, timing values, transform-vs-layout details |
|
|
16
|
+
| `interaction-design.md` | 195 | Form patterns, focus management, loading-state choreography, progressive disclosure depth |
|
|
17
|
+
| `responsive-design.md` | 114 | Mobile-first patterns, container queries vs viewport queries, fluid design math |
|
|
18
|
+
| `ux-writing.md` | 107 | Labels, error messages, empty-state copy, button text patterns |
|
|
19
|
+
| `craft.md` | 70 | The `craft` mode flow (only when invoked via `/impeccable craft`) |
|
|
20
|
+
| `extract.md` | 70 | The `extract` mode flow (only when invoked via `/impeccable extract`) |
|
|
21
|
+
|
|
22
|
+
## Rules
|
|
23
|
+
|
|
24
|
+
1. **One file per task.** If you need typography AND color, do typography first, finish the task, then color if still needed.
|
|
25
|
+
2. **Skip if inline principle is enough.** `impeccable/SKILL.md` has `<typography_principles>`, `<color_principles>`, `<spatial_principles>` blocks that often answer the question without opening the reference.
|
|
26
|
+
3. **`craft.md` and `extract.md` are mode-only** — never load unless the user typed `/impeccable craft` or `/impeccable extract`.
|
|
@@ -8,9 +8,12 @@ argument-hint: "[target]"
|
|
|
8
8
|
|
|
9
9
|
Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Context check (lightweight)
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Before proceeding, ensure design context is loaded:
|
|
14
|
+
- If `.impeccable.md` exists in project root, the project context is set — DO NOT re-invoke /impeccable.
|
|
15
|
+
- If `.impeccable.md` is missing, run `/impeccable teach` ONCE to create it.
|
|
16
|
+
- For depth on one topic only, see `impeccable/reference/INDEX.md` and load ONE file.
|
|
14
17
|
|
|
15
18
|
---
|
|
16
19
|
|
|
@@ -33,29 +33,49 @@ When designing app UI (toolbars, headers, inline controls):
|
|
|
33
33
|
|
|
34
34
|
| Context | Layout | Reference |
|
|
35
35
|
|---------|--------|-----------|
|
|
36
|
-
| Document editor | Toolbar above content; `bg-muted/30` container; `Separator` between groups |
|
|
37
|
-
| Chart/settings | Label + inline controls; `rounded-lg border bg-muted/30 p-3` |
|
|
38
|
-
| Standalone | Inline with related UI |
|
|
36
|
+
| Document editor | Toolbar above content; `bg-muted/30` container; `Separator` between groups | `/catalog` → Toggle & ToggleGroup |
|
|
37
|
+
| Chart/settings | Label + inline controls; `rounded-lg border bg-muted/30 p-3` | `/catalog` → Chart settings |
|
|
38
|
+
| Standalone | Inline with related UI | `/catalog` → Standalone toggle |
|
|
39
39
|
|
|
40
|
-
**Canonical implementation:**
|
|
40
|
+
**Canonical implementation:** `/catalog` Toggle section, or full pages at `/patterns` and `/recipes/settings`.
|
|
41
|
+
|
|
42
|
+
## Composition (product UI)
|
|
43
|
+
|
|
44
|
+
Before picking components, read **`../COMPOSITION.md`** (or `docs/nqui-skills/COMPOSITION.md`). Dev app: **Recipes** at `/`, catalog at `/catalog`.
|
|
45
|
+
|
|
46
|
+
### Pre-ship checklist
|
|
47
|
+
|
|
48
|
+
- [ ] One user goal and primary action on the screen
|
|
49
|
+
- [ ] ≤3 major surfaces (chrome + primary + optional secondary)
|
|
50
|
+
- [ ] Toolbars use ToggleGroup in context (`bg-muted/30`), not isolated in Cards
|
|
51
|
+
- [ ] Forms use FieldSet + FieldGroup (not a card per field)
|
|
52
|
+
- [ ] Cards only for bounded topics, not every control
|
|
53
|
+
- [ ] Loading / empty / error states use Skeleton, Empty, Alert
|
|
41
54
|
|
|
42
55
|
## Quick Reference
|
|
43
56
|
|
|
44
|
-
1. **
|
|
45
|
-
2. **
|
|
46
|
-
3. **
|
|
47
|
-
4. **
|
|
57
|
+
1. **Composition:** `../COMPOSITION.md` – when to assemble, not just which component
|
|
58
|
+
2. **Main index:** `./README.md` – all components, use cases, prerequisites
|
|
59
|
+
3. **Per-component:** `./nqui-<name>.md` – import, examples, variants
|
|
60
|
+
4. **Design system:** `.cursor/skills/nqui-design-system/SKILL.md` – sizing, grouped controls, **Card + ScrollArea** (any bounded panel)
|
|
61
|
+
5. **Scroll / flex / overflow:** `docs/components/nqui-scroll-area.md` – **§0** symptom routing, §1–§6 pitfalls, **`viewportStyle`**, **`orientation`**
|
|
62
|
+
6. **Layout index:** `./README.md` – custom scroll container, sticky z-index, momentum scroll prevention
|
|
48
63
|
|
|
49
64
|
## Key Conventions
|
|
50
65
|
|
|
51
66
|
- React 18+ and 19 supported
|
|
67
|
+
- **cmdk list rows:** nqui ≥ 0.6.1 uses `aria-selected:bg-accent` in `floatingListItemInteractive`. Do not add custom `data-selected:bg-accent` on `CommandItem` (React 19 + `[data-selected]` highlights every row). See `docs/components/nqui-command-palette.md`.
|
|
52
68
|
- Control sizes: sm=h-6, default=h-7, lg=h-8
|
|
53
69
|
- Enhanced vs Core: default is enhanced; use Core* for plain
|
|
54
70
|
- Z-index: CSS vars from elevation.css only
|
|
55
71
|
|
|
56
72
|
## Layout Pattern: Card + ScrollArea + flex min-h-0 scroll
|
|
57
73
|
|
|
58
|
-
When a component demo is placed inside a `Card` (which itself lives in a responsive grid), the card content must not overflow its boundary.
|
|
74
|
+
When a component demo is placed inside a `Card` (which itself lives in a responsive grid), the card content must not overflow its boundary. **If scroll is stuck, the footer overlaps, or `h-full` does nothing**, read **`docs/components/nqui-scroll-area.md` §0** (symptom routing) and **§1** — almost always a **`min-h-0`** / finite-height chain issue, not ScrollArea itself.
|
|
75
|
+
|
|
76
|
+
For **stubborn** Radix viewports in deep flex trees, add **`viewportStyle`** with **`position: "absolute"`, `inset: 0`, `minHeight: 0`, `minWidth: 0`** (see **§6**). For **wide** native tables or **`min-w-*`** grids, use **`orientation="both"`** (default vertical hides horizontal scroll).
|
|
77
|
+
|
|
78
|
+
Use this exact pattern for **simple** wide horizontal areas (pagination, etc.):
|
|
59
79
|
|
|
60
80
|
```tsx
|
|
61
81
|
<Card>
|
|
@@ -81,3 +101,7 @@ When a component demo is placed inside a `Card` (which itself lives in a respons
|
|
|
81
101
|
- `overflow-y-auto` — vertical scroll for tall content (logs, feeds, lists)
|
|
82
102
|
- `overflow-hidden` — when you want to clip visible overflow without scrolling
|
|
83
103
|
|
|
104
|
+
## Data tables (TanStack + ScrollArea)
|
|
105
|
+
|
|
106
|
+
For **bounded card tables** with sticky headers, **horizontal + vertical** scroll, flex height chain, and optional infinite scroll or paging, follow **`nqui-data-tables`** (`../nqui-data-tables/SKILL.md`) and read **`docs/components/nqui-scroll-area.md`** (**§0**–**§6**) first.
|
|
107
|
+
|