mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-11 21:57:14 +03:00
Redesign Antidote section: card stack gallery, tabbed patterns, new skills
Replace the sliding accordion with a 3D card stack for Gallery of Shame (bottom-right deck offset with scroll/button nav). Patterns now use clean pill tabs with single-column Don't/Do layout in a white container. Also scaffolds two new skills: /validate (fast visual validation after UI changes) and /craft (guided feature design through user interview). Fixes detection count from 25 to 24, changes badge from "Deterministic" to "New!". Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Paul Bakaus
co-authored by
Claude Opus 4.6
Claude Opus 4.6
parent
b5cd306e70
commit
3f7b5fd8bf
@@ -108,7 +108,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -127,7 +127,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
user-invocable: true
|
||||
argument-hint: "[feature to design]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -140,7 +140,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -205,7 +205,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
user-invocable: true
|
||||
argument-hint: "[area to validate]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -108,7 +108,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -127,7 +127,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
user-invocable: true
|
||||
argument-hint: "[feature to design]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. STOP and call the AskUserQuestion tool to clarify.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
STOP and call the AskUserQuestion tool to clarify. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -145,7 +145,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -210,7 +210,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
user-invocable: true
|
||||
argument-hint: "[area to validate]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, STOP and call the AskUserQuestion tool to clarify. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -107,7 +107,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: $animate, $quieter, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: $animate, $validate, $quieter, $craft, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -126,7 +126,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `$command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `$command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: $animate, $quieter, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive. Map findings to the most appropriate command. End with `$polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: $animate, $validate, $quieter, $craft, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive. Map findings to the most appropriate command. End with `$polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
argument-hint: "[feature to design]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke $impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run $impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use $impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run $validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -139,7 +139,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: $animate, $quieter, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive)
|
||||
- **Suggested command**: Which command could address this (from: $animate, $validate, $quieter, $craft, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -204,7 +204,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: $animate, $quieter, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive
|
||||
- Only recommend commands from: $animate, $validate, $quieter, $craft, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
argument-hint: "[area to validate]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke $impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run $impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run $validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → $arrange, copy issues → $clarify), suggest that command instead of fixing manually.
|
||||
@@ -106,7 +106,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -125,7 +125,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -138,7 +138,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -203,7 +203,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -106,7 +106,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -125,7 +125,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -138,7 +138,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -203,7 +203,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -106,7 +106,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -125,7 +125,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -138,7 +138,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -203,7 +203,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -108,7 +108,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -127,7 +127,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
user-invocable: true
|
||||
argument-hint: "[feature to design]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. STOP and call the `question` tool to clarify.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
STOP and call the `question` tool to clarify. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -145,7 +145,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -210,7 +210,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
user-invocable: true
|
||||
argument-hint: "[area to validate]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, STOP and call the `question` tool to clarify. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -106,7 +106,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -125,7 +125,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -143,7 +143,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -208,7 +208,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -108,7 +108,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -127,7 +127,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
user-invocable: true
|
||||
argument-hint: "[feature to design]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -140,7 +140,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -205,7 +205,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
user-invocable: true
|
||||
argument-hint: "[area to validate]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
@@ -108,7 +108,7 @@ For each issue, document:
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command to use (prefer: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
@@ -127,7 +127,7 @@ List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `/command-name`** — Brief description (specific context)
|
||||
|
||||
**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
**Rules**: Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: craft
|
||||
description: Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code.
|
||||
user-invocable: true
|
||||
argument-hint: "[feature to design]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. ask the user directly to clarify what you cannot infer.
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
ask the user directly to clarify what you cannot infer. -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use /impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run /validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -140,7 +140,7 @@ For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](refer
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
- **Suggested command**: Which command could address this (from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
@@ -205,7 +205,7 @@ List recommended commands in priority order, based on the user's answers:
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Only recommend commands from: /animate, /validate, /quieter, /craft, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: validate
|
||||
description: Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature.
|
||||
user-invocable: true
|
||||
argument-hint: "[area to validate]"
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke /impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run /impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run /validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, ask the user directly to clarify what you cannot infer. whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → /arrange, copy issues → /clarify), suggest that command instead of fixing manually.
|
||||
+59
-65
@@ -49,6 +49,9 @@ async function loadContent() {
|
||||
// Render commands (Glass Terminal)
|
||||
renderTerminalLayout(allCommands);
|
||||
|
||||
// Initialize gallery card stack
|
||||
initGalleryStack();
|
||||
|
||||
// Render patterns with tabbed navigation
|
||||
renderPatternsWithTabs(patternsData.patterns, patternsData.antipatterns);
|
||||
} catch (error) {
|
||||
@@ -89,6 +92,41 @@ function showLoadError(error) {
|
||||
}
|
||||
}
|
||||
|
||||
function initGalleryStack() {
|
||||
const container = document.querySelector('.gallery-stack-container');
|
||||
const stack = document.getElementById('gallery-stack');
|
||||
if (!stack || !container) return;
|
||||
|
||||
const cards = stack.querySelectorAll('.gallery-stack-card');
|
||||
const counter = container.querySelector('.gallery-stack-counter');
|
||||
const total = cards.length;
|
||||
let current = 0;
|
||||
let lastScroll = 0;
|
||||
|
||||
function update() {
|
||||
cards.forEach((card, i) => {
|
||||
const offset = (i - current + total) % total;
|
||||
card.dataset.offset = offset;
|
||||
});
|
||||
}
|
||||
|
||||
function next() { current = (current + 1) % total; update(); }
|
||||
function prev() { current = (current - 1 + total) % total; update(); }
|
||||
|
||||
container.querySelector('.gallery-stack-prev').addEventListener('click', prev);
|
||||
container.querySelector('.gallery-stack-next').addEventListener('click', next);
|
||||
|
||||
stack.addEventListener('wheel', (e) => {
|
||||
e.preventDefault();
|
||||
const now = Date.now();
|
||||
if (now - lastScroll < 350) return;
|
||||
lastScroll = now;
|
||||
if (e.deltaY > 0) next(); else prev();
|
||||
}, { passive: false });
|
||||
|
||||
update();
|
||||
}
|
||||
|
||||
function renderPatternsWithTabs(patterns, antipatterns) {
|
||||
const container = document.getElementById("patterns-categories");
|
||||
if (!container || !patterns || !antipatterns) return;
|
||||
@@ -96,77 +134,33 @@ function renderPatternsWithTabs(patterns, antipatterns) {
|
||||
const antipatternMap = {};
|
||||
antipatterns.forEach(cat => { antipatternMap[cat.name] = cat.items; });
|
||||
|
||||
const icons = ['Aa', '◉', '▦', '⧉', '⚙', '⎙', '✎', '✎'];
|
||||
const tabsHTML = patterns.map((cat, i) =>
|
||||
`<button class="patterns-tab${i === 0 ? ' is-active' : ''}" data-index="${i}">${escapeHtml(cat.name)}</button>`
|
||||
).join('');
|
||||
|
||||
const itemsHTML = patterns.map((category, i) => {
|
||||
const antiItems = antipatternMap[category.name] || [];
|
||||
const totalCount = antiItems.length + category.items.length;
|
||||
const panelsHTML = patterns.map((cat, i) => {
|
||||
const antiItems = antipatternMap[cat.name] || [];
|
||||
return `
|
||||
<li class="disclosure-item" data-active="${i === 0 ? 'true' : 'false'}" data-index="${i}">
|
||||
<button class="disclosure-tab" aria-expanded="${i === 0 ? 'true' : 'false'}">
|
||||
<span class="disclosure-tab-label">${escapeHtml(category.name)}</span>
|
||||
<span class="disclosure-tab-icon">${icons[i] || '•'}</span>
|
||||
</button>
|
||||
<div class="disclosure-content">
|
||||
<div class="disclosure-toggle">
|
||||
<button class="disclosure-toggle-btn disclosure-toggle-btn--anti is-active" data-show="anti">Don't</button>
|
||||
<button class="disclosure-toggle-btn disclosure-toggle-btn--do" data-show="do">Do</button>
|
||||
</div>
|
||||
<div class="disclosure-content-inner">
|
||||
<div class="disclosure-columns">
|
||||
<div class="disclosure-col" data-col="anti">
|
||||
<ul>${antiItems.map(item => `<li>${escapeHtml(item)}</li>`).join('')}</ul>
|
||||
</div>
|
||||
<div class="disclosure-col" data-col="do" hidden>
|
||||
<ul>${category.items.map(item => `<li>${escapeHtml(item)}</li>`).join('')}</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="patterns-content${i === 0 ? ' is-active' : ''}" data-index="${i}">
|
||||
<div class="patterns-col patterns-col--dont">
|
||||
<ul>${antiItems.map(item => `<li>${escapeHtml(item)}</li>`).join('')}</ul>
|
||||
</div>
|
||||
</li>`;
|
||||
<div class="patterns-col patterns-col--do">
|
||||
<ul>${cat.items.map(item => `<li>${escapeHtml(item)}</li>`).join('')}</ul>
|
||||
</div>
|
||||
</div>`;
|
||||
}).join('');
|
||||
|
||||
container.innerHTML = `<ul class="disclosure-list">${itemsHTML}</ul>`;
|
||||
container.innerHTML = `<div class="patterns-tabs">${tabsHTML}</div>${panelsHTML}`;
|
||||
|
||||
const list = container.querySelector('.disclosure-list');
|
||||
const items = list.querySelectorAll('.disclosure-item');
|
||||
|
||||
const activate = (event) => {
|
||||
const closest = event.target.closest('.disclosure-item');
|
||||
if (!closest) return;
|
||||
const index = [...items].indexOf(closest);
|
||||
const cols = [...items].map((item, i) => {
|
||||
item.dataset.active = (index === i).toString();
|
||||
item.querySelector('.disclosure-tab').setAttribute('aria-expanded', index === i ? 'true' : 'false');
|
||||
return index === i ? '10fr' : '1fr';
|
||||
}).join(' ');
|
||||
list.style.setProperty('grid-template-columns', cols);
|
||||
};
|
||||
|
||||
// Sync article width for content sizing
|
||||
const syncWidth = () => {
|
||||
const w = Math.max(...[...items].map(i => i.offsetWidth));
|
||||
list.style.setProperty('--dl-article-width', w);
|
||||
};
|
||||
window.addEventListener('resize', syncWidth);
|
||||
syncWidth();
|
||||
|
||||
list.addEventListener('pointermove', activate);
|
||||
list.addEventListener('click', activate);
|
||||
list.addEventListener('focus', activate, true);
|
||||
|
||||
// Don't/Do toggle within each card
|
||||
list.addEventListener('click', (e) => {
|
||||
const btn = e.target.closest('.disclosure-toggle-btn');
|
||||
if (!btn) return;
|
||||
e.stopPropagation();
|
||||
const item = btn.closest('.disclosure-item');
|
||||
const show = btn.dataset.show;
|
||||
item.querySelectorAll('.disclosure-toggle-btn').forEach(b => b.classList.remove('is-active'));
|
||||
btn.classList.add('is-active');
|
||||
item.querySelectorAll('.disclosure-col').forEach(col => {
|
||||
col.hidden = col.dataset.col !== show;
|
||||
});
|
||||
container.addEventListener('click', (e) => {
|
||||
const tab = e.target.closest('.patterns-tab');
|
||||
if (!tab) return;
|
||||
const index = tab.dataset.index;
|
||||
container.querySelectorAll('.patterns-tab').forEach(t => t.classList.remove('is-active'));
|
||||
container.querySelectorAll('.patterns-content').forEach(p => p.classList.remove('is-active'));
|
||||
tab.classList.add('is-active');
|
||||
container.querySelector(`.patterns-content[data-index="${index}"]`).classList.add('is-active');
|
||||
});
|
||||
}
|
||||
|
||||
|
||||
+177
-312
@@ -1947,170 +1947,211 @@ code {
|
||||
border-top: 1px solid var(--color-mist);
|
||||
}
|
||||
|
||||
/* Animated horizontal disclosure (inspired by jh3y/XJWNMOO) */
|
||||
.antidote-grid {
|
||||
/* Antidote row: patterns + gallery side by side */
|
||||
.antidote-row {
|
||||
display: flex;
|
||||
gap: var(--spacing-xl);
|
||||
align-items: stretch;
|
||||
margin-bottom: var(--spacing-xl);
|
||||
}
|
||||
|
||||
.disclosure-list {
|
||||
--dl-gap: 6px;
|
||||
--dl-base: 52px;
|
||||
--dl-speed: 0.5s;
|
||||
--dl-easing: linear(0 0%, 0.15 4%, 0.29 8%, 0.42 13%, 0.53 17%, 0.63 22%, 0.71 27%, 0.78 32%, 0.84 37%, 0.89 42%, 0.93 48%, 0.95 54%, 0.98 60%, 0.99 67%, 1 75%, 1 100%);
|
||||
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
display: grid;
|
||||
grid-template-columns: 10fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;
|
||||
gap: var(--dl-gap);
|
||||
height: clamp(320px, 38dvh, 420px);
|
||||
transition: grid-template-columns var(--dl-speed) var(--dl-easing);
|
||||
.antidote-row .patterns-tabbed {
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
.disclosure-item {
|
||||
/* Gallery of Shame — 3D card stack */
|
||||
.gallery-stack-container {
|
||||
flex: 0 0 clamp(320px, 34vw, 420px);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-xs);
|
||||
position: relative;
|
||||
overflow: hidden;
|
||||
min-width: var(--dl-base);
|
||||
border-radius: 8px;
|
||||
}
|
||||
|
||||
|
||||
/* Header: ← Gallery of Shame → */
|
||||
.gallery-stack-header {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: var(--spacing-xs);
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
.gallery-stack-title {
|
||||
font-family: var(--font-display);
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-ink);
|
||||
flex: 1;
|
||||
}
|
||||
|
||||
.gallery-stack-btn {
|
||||
width: 24px;
|
||||
height: 24px;
|
||||
border-radius: 50%;
|
||||
border: 1px solid var(--color-mist);
|
||||
background: white;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
/* Tab: label + icon inside each item, absolutely positioned */
|
||||
.disclosure-tab {
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
padding: 0;
|
||||
background: none;
|
||||
border: none;
|
||||
cursor: pointer;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
justify-content: center;
|
||||
font-size: 0.6875rem;
|
||||
color: var(--color-charcoal);
|
||||
flex-shrink: 0;
|
||||
transition: border-color var(--duration-fast), background var(--duration-fast);
|
||||
}
|
||||
|
||||
.disclosure-tab-label {
|
||||
position: absolute;
|
||||
top: var(--spacing-sm);
|
||||
left: calc(var(--dl-base) * 0.5);
|
||||
transform-origin: 0 50%;
|
||||
rotate: 90deg;
|
||||
font-family: var(--font-body);
|
||||
font-size: 0.8125rem;
|
||||
font-weight: 500;
|
||||
text-transform: uppercase;
|
||||
color: var(--color-ink);
|
||||
letter-spacing: 0.03em;
|
||||
white-space: nowrap;
|
||||
opacity: 0.5;
|
||||
transition: opacity calc(var(--dl-speed) * 1.2) var(--dl-easing);
|
||||
.gallery-stack-btn:hover {
|
||||
border-color: var(--color-charcoal);
|
||||
}
|
||||
|
||||
.disclosure-tab-icon {
|
||||
position: absolute;
|
||||
bottom: var(--spacing-sm);
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
font-size: 1rem;
|
||||
color: var(--color-accent);
|
||||
font-weight: 600;
|
||||
opacity: 0.5;
|
||||
transition: opacity calc(var(--dl-speed) * 1.2) var(--dl-easing);
|
||||
/* Card stack — stacked deck offset to bottom-right */
|
||||
.gallery-stack {
|
||||
position: relative;
|
||||
width: calc(100% - 20px);
|
||||
aspect-ratio: 3 / 2;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
|
||||
.disclosure-item[data-active='true'] .disclosure-tab-label {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
.disclosure-item[data-active='true'] .disclosure-tab-icon {
|
||||
opacity: 0;
|
||||
}
|
||||
|
||||
/* Expanded content: absolutely positioned, sized to article width */
|
||||
.disclosure-content {
|
||||
.gallery-stack-card {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: calc(var(--dl-article-width, 600) * 1px);
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
border-radius: 8px;
|
||||
overflow: hidden;
|
||||
opacity: 0;
|
||||
transition: opacity calc(var(--dl-speed) * 1.2) var(--dl-easing);
|
||||
}
|
||||
|
||||
.disclosure-item[data-active='true'] .disclosure-content {
|
||||
opacity: 1;
|
||||
transition-delay: calc(var(--dl-speed) * 0.2);
|
||||
}
|
||||
|
||||
.disclosure-content-inner {
|
||||
padding: var(--spacing-sm) var(--spacing-md) var(--spacing-md) calc(var(--dl-base) + var(--spacing-sm));
|
||||
flex: 1;
|
||||
overflow-y: auto;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
.disclosure-columns {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-sm);
|
||||
}
|
||||
|
||||
/* Toggle between don't/do — fixed header inside disclosure content */
|
||||
.disclosure-toggle {
|
||||
display: inline-flex;
|
||||
gap: 0;
|
||||
border: 1px solid var(--color-mist);
|
||||
border-radius: 5px;
|
||||
overflow: hidden;
|
||||
flex-shrink: 0;
|
||||
align-self: flex-end;
|
||||
margin: var(--spacing-sm) var(--spacing-sm) 0 0;
|
||||
text-decoration: none;
|
||||
background: white;
|
||||
transition: transform 0.45s cubic-bezier(0.16, 1, 0.3, 1), opacity 0.35s ease, box-shadow 0.35s ease;
|
||||
will-change: transform, opacity;
|
||||
}
|
||||
|
||||
.disclosure-toggle-btn {
|
||||
font-family: var(--font-body);
|
||||
font-size: 0.625rem;
|
||||
.gallery-stack-card img {
|
||||
flex: 1;
|
||||
min-height: 0;
|
||||
width: 100%;
|
||||
object-fit: cover;
|
||||
object-position: top left;
|
||||
}
|
||||
|
||||
.gallery-stack-label {
|
||||
padding: 6px 10px;
|
||||
font-size: 0.6875rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
border: none;
|
||||
padding: 3px 10px;
|
||||
cursor: pointer;
|
||||
background: none;
|
||||
color: var(--color-ash);
|
||||
transition: background var(--duration-fast), color var(--duration-fast);
|
||||
color: var(--color-charcoal);
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.disclosure-toggle-btn + .disclosure-toggle-btn {
|
||||
border-left: 1px solid var(--color-mist);
|
||||
/* Stack depth: cards peek behind at bottom-right */
|
||||
.gallery-stack-card[data-offset="0"] {
|
||||
z-index: 3;
|
||||
transform: translate(0, 0);
|
||||
opacity: 1;
|
||||
box-shadow: 0 2px 12px oklch(0.2 0 0 / 0.1);
|
||||
}
|
||||
|
||||
.disclosure-toggle-btn.is-active {
|
||||
background: oklch(97% 0.005 350);
|
||||
color: var(--color-ink);
|
||||
.gallery-stack-card[data-offset="1"] {
|
||||
z-index: 2;
|
||||
transform: translate(8px, 8px);
|
||||
opacity: 1;
|
||||
box-shadow: 0 1px 6px oklch(0.2 0 0 / 0.08);
|
||||
pointer-events: none;
|
||||
}
|
||||
|
||||
.disclosure-toggle-btn--anti.is-active {
|
||||
.gallery-stack-card[data-offset="2"] {
|
||||
z-index: 1;
|
||||
transform: translate(16px, 16px);
|
||||
opacity: 1;
|
||||
box-shadow: 0 1px 4px oklch(0.2 0 0 / 0.06);
|
||||
pointer-events: none;
|
||||
}
|
||||
|
||||
.gallery-stack-card:not([data-offset="0"]):not([data-offset="1"]):not([data-offset="2"]) {
|
||||
z-index: 0;
|
||||
transform: translate(20px, 20px);
|
||||
opacity: 0;
|
||||
pointer-events: none;
|
||||
}
|
||||
|
||||
.gallery-stack-link {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 500;
|
||||
color: var(--color-accent);
|
||||
text-decoration: none;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.disclosure-toggle-btn--do.is-active {
|
||||
color: var(--color-success, #22c55e);
|
||||
.gallery-stack-link:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
.disclosure-col[hidden] {
|
||||
@media (max-width: 900px) {
|
||||
.antidote-row {
|
||||
flex-direction: column;
|
||||
}
|
||||
|
||||
.gallery-stack-container {
|
||||
flex: none;
|
||||
width: 100%;
|
||||
max-width: 360px;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
/* ---- Pattern tabs ---- */
|
||||
.patterns-tabbed {
|
||||
margin-bottom: var(--spacing-xl);
|
||||
background: white;
|
||||
border-radius: 8px;
|
||||
padding: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.patterns-tabs {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 6px;
|
||||
margin-bottom: var(--spacing-md);
|
||||
}
|
||||
|
||||
.patterns-tab {
|
||||
font-family: var(--font-body);
|
||||
font-size: 0.6875rem;
|
||||
font-weight: 500;
|
||||
color: var(--color-charcoal);
|
||||
background: none;
|
||||
border: none;
|
||||
border-radius: 100px;
|
||||
padding: 6px 12px;
|
||||
cursor: pointer;
|
||||
transition: background 0.2s ease, color 0.2s ease;
|
||||
}
|
||||
|
||||
.patterns-tab:hover {
|
||||
background: var(--color-mist);
|
||||
}
|
||||
|
||||
.patterns-tab.is-active {
|
||||
background: var(--color-ink);
|
||||
color: var(--color-paper);
|
||||
}
|
||||
|
||||
.patterns-content {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.disclosure-col ul {
|
||||
.patterns-content.is-active {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
|
||||
.patterns-col ul {
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
@@ -2119,8 +2160,8 @@ code {
|
||||
gap: 6px;
|
||||
}
|
||||
|
||||
.disclosure-col li {
|
||||
font-size: 0.9375rem;
|
||||
.patterns-col li {
|
||||
font-size: 0.8125rem;
|
||||
line-height: 1.55;
|
||||
padding-left: var(--spacing-sm);
|
||||
position: relative;
|
||||
@@ -2129,19 +2170,7 @@ code {
|
||||
word-break: break-word;
|
||||
}
|
||||
|
||||
.disclosure-col-label {
|
||||
display: block;
|
||||
font-size: 0.625rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.1em;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
.disclosure-col-label--anti { color: var(--color-accent); }
|
||||
.disclosure-col-label--do { color: var(--color-success, #22c55e); }
|
||||
|
||||
.disclosure-col[data-col='anti'] li::before {
|
||||
.patterns-col--dont li::before {
|
||||
content: '\00d7';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
@@ -2149,7 +2178,7 @@ code {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.disclosure-col[data-col='do'] li::before {
|
||||
.patterns-col--do li::before {
|
||||
content: '\2713';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
@@ -2157,137 +2186,6 @@ code {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
/* Mobile: vertical stack */
|
||||
@media (max-width: 768px) {
|
||||
.disclosure-list {
|
||||
grid-template-columns: 1fr;
|
||||
grid-template-rows: 10fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;
|
||||
height: auto;
|
||||
min-height: 500px;
|
||||
transition: grid-template-rows var(--dl-speed) var(--dl-easing);
|
||||
}
|
||||
|
||||
.disclosure-item {
|
||||
min-width: 0;
|
||||
min-height: var(--dl-base);
|
||||
}
|
||||
|
||||
.disclosure-tab-label {
|
||||
rotate: none;
|
||||
top: 50%;
|
||||
left: var(--spacing-md);
|
||||
transform: translateY(-50%);
|
||||
}
|
||||
|
||||
.disclosure-tab-icon {
|
||||
bottom: 50%;
|
||||
left: auto;
|
||||
right: var(--spacing-md);
|
||||
transform: translateY(50%);
|
||||
}
|
||||
|
||||
.disclosure-content-inner {
|
||||
padding: calc(var(--dl-base) + var(--spacing-sm)) var(--spacing-md) var(--spacing-md);
|
||||
}
|
||||
|
||||
.disclosure-columns {
|
||||
grid-template-columns: 1fr;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
}
|
||||
|
||||
/* Antidote row: cards + gallery sidebar */
|
||||
.antidote-row {
|
||||
display: flex;
|
||||
gap: var(--spacing-lg);
|
||||
align-items: stretch;
|
||||
margin-bottom: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.antidote-row .antidote-grid {
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
/* Gallery sidebar */
|
||||
.gallery-sidebar {
|
||||
flex: 0 0 32%;
|
||||
min-width: 0;
|
||||
max-width: 400px;
|
||||
border: 1px solid var(--color-mist);
|
||||
border-radius: 12px;
|
||||
padding: var(--spacing-sm);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-xs);
|
||||
overflow: hidden;
|
||||
max-height: clamp(320px, 38dvh, 420px);
|
||||
}
|
||||
|
||||
.gallery-sidebar-title {
|
||||
font-family: var(--font-display);
|
||||
font-size: 1.125rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-ink);
|
||||
padding: var(--spacing-xs) var(--spacing-xs) 0;
|
||||
}
|
||||
|
||||
.gallery-sidebar-scroll {
|
||||
flex: 1;
|
||||
overflow-y: auto;
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 6px;
|
||||
scrollbar-width: none;
|
||||
}
|
||||
|
||||
.gallery-sidebar-scroll::-webkit-scrollbar { display: none; }
|
||||
|
||||
.gallery-sidebar-card {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 4px;
|
||||
padding: 4px;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
overflow: hidden;
|
||||
transition: background var(--duration-fast) var(--ease-out);
|
||||
}
|
||||
|
||||
.gallery-sidebar-card:hover {
|
||||
background: oklch(97% 0.005 350);
|
||||
}
|
||||
|
||||
.gallery-sidebar-card img {
|
||||
width: 100%;
|
||||
height: 72px;
|
||||
object-fit: cover;
|
||||
object-position: top left;
|
||||
border-radius: 6px;
|
||||
border: 1px solid var(--color-mist);
|
||||
}
|
||||
|
||||
.gallery-sidebar-label {
|
||||
font-size: 0.6875rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-charcoal);
|
||||
padding: 0 2px;
|
||||
}
|
||||
|
||||
.gallery-sidebar-link {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 500;
|
||||
color: var(--color-accent);
|
||||
text-decoration: none;
|
||||
text-align: center;
|
||||
padding: var(--spacing-xs) 0 0;
|
||||
border-top: 1px solid var(--color-mist);
|
||||
}
|
||||
|
||||
.gallery-sidebar-link:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
/* Detection callout — horizontal below cards */
|
||||
.detection-callout {
|
||||
@@ -2347,31 +2245,6 @@ code {
|
||||
color: var(--color-accent);
|
||||
}
|
||||
|
||||
@media (max-width: 1060px) {
|
||||
.antidote-row {
|
||||
flex-direction: column;
|
||||
}
|
||||
|
||||
.gallery-sidebar {
|
||||
flex: none;
|
||||
width: 100%;
|
||||
max-width: none;
|
||||
max-height: none;
|
||||
}
|
||||
|
||||
.gallery-sidebar-scroll {
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 600px) {
|
||||
.gallery-sidebar-scroll {
|
||||
grid-template-columns: 1fr 1fr;
|
||||
}
|
||||
}
|
||||
|
||||
/* (gallery teaser styles moved to gallery-sidebar above) */
|
||||
|
||||
/* Antidote footer */
|
||||
.antidote-footer {
|
||||
text-align: center;
|
||||
@@ -2504,14 +2377,10 @@ code {
|
||||
flex-direction: column;
|
||||
}
|
||||
|
||||
.install-path:first-child {
|
||||
border-right: 1px solid var(--color-mist);
|
||||
padding-right: var(--spacing-xl);
|
||||
}
|
||||
|
||||
.install-path-secondary {
|
||||
border-right: 1px solid var(--color-mist);
|
||||
padding-right: var(--spacing-xl);
|
||||
.install-path-primary {
|
||||
background: white;
|
||||
border-radius: 16px;
|
||||
padding: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.install-path-label {
|
||||
@@ -2523,6 +2392,10 @@ code {
|
||||
color: var(--color-accent);
|
||||
}
|
||||
|
||||
.install-path:not(.install-path-primary) {
|
||||
padding-top: var(--spacing-lg);
|
||||
}
|
||||
|
||||
.install-path-secondary .install-path-label {
|
||||
color: var(--color-ash);
|
||||
}
|
||||
@@ -2780,12 +2653,8 @@ a.install-updated-ref:hover {
|
||||
gap: var(--spacing-xl);
|
||||
}
|
||||
|
||||
.install-path:first-child,
|
||||
.install-path-secondary {
|
||||
border-right: none;
|
||||
padding-right: 0;
|
||||
padding-bottom: var(--spacing-xl);
|
||||
border-bottom: 1px solid var(--color-mist);
|
||||
.install-path-primary {
|
||||
margin-bottom: var(--spacing-sm);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -2965,10 +2834,6 @@ a.install-updated-ref:hover {
|
||||
}
|
||||
|
||||
.install-alternatives-content {
|
||||
border: 1px solid var(--color-mist);
|
||||
border-radius: 8px;
|
||||
background: var(--color-paper);
|
||||
overflow: hidden;
|
||||
animation: altFadeIn 0.2s var(--ease-out);
|
||||
}
|
||||
|
||||
|
||||
+154
-276
@@ -3928,146 +3928,177 @@ code {
|
||||
padding: var(--spacing-2xl) 0;
|
||||
border-top: 1px solid var(--color-mist);
|
||||
}
|
||||
.antidote-grid {
|
||||
.antidote-row {
|
||||
display: flex;
|
||||
gap: var(--spacing-xl);
|
||||
align-items: stretch;
|
||||
margin-bottom: var(--spacing-xl);
|
||||
}
|
||||
.disclosure-list {
|
||||
--dl-gap: 6px;
|
||||
--dl-base: 52px;
|
||||
--dl-speed: 0.5s;
|
||||
--dl-easing: linear(0 0%, 0.15 4%, 0.29 8%, 0.42 13%, 0.53 17%, 0.63 22%, 0.71 27%, 0.78 32%, 0.84 37%, 0.89 42%, 0.93 48%, 0.95 54%, 0.98 60%, 0.99 67%, 1 75%, 1 100%);
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
display: grid;
|
||||
grid-template-columns: 10fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;
|
||||
gap: var(--dl-gap);
|
||||
height: clamp(320px, 38dvh, 420px);
|
||||
transition: grid-template-columns var(--dl-speed) var(--dl-easing);
|
||||
.antidote-row .patterns-tabbed {
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
margin-bottom: 0;
|
||||
}
|
||||
.disclosure-item {
|
||||
.gallery-stack-container {
|
||||
flex: 0 0 clamp(320px, 34vw, 420px);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-xs);
|
||||
position: relative;
|
||||
overflow: hidden;
|
||||
min-width: var(--dl-base);
|
||||
border-radius: 8px;
|
||||
}
|
||||
.gallery-stack-header {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: var(--spacing-xs);
|
||||
white-space: nowrap;
|
||||
}
|
||||
.gallery-stack-title {
|
||||
font-family: var(--font-display);
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-ink);
|
||||
flex: 1;
|
||||
}
|
||||
.gallery-stack-btn {
|
||||
width: 24px;
|
||||
height: 24px;
|
||||
border-radius: 50%;
|
||||
border: 1px solid var(--color-mist);
|
||||
background: white;
|
||||
cursor: pointer;
|
||||
}
|
||||
.disclosure-tab {
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
padding: 0;
|
||||
background: none;
|
||||
border: none;
|
||||
cursor: pointer;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
justify-content: center;
|
||||
font-size: 0.6875rem;
|
||||
color: var(--color-charcoal);
|
||||
flex-shrink: 0;
|
||||
transition: border-color var(--duration-fast), background var(--duration-fast);
|
||||
}
|
||||
.disclosure-tab-label {
|
||||
position: absolute;
|
||||
top: var(--spacing-sm);
|
||||
left: calc(var(--dl-base) * 0.5);
|
||||
transform-origin: 0 50%;
|
||||
rotate: 90deg;
|
||||
font-family: var(--font-body);
|
||||
font-size: 0.8125rem;
|
||||
font-weight: 500;
|
||||
text-transform: uppercase;
|
||||
color: var(--color-ink);
|
||||
letter-spacing: 0.03em;
|
||||
white-space: nowrap;
|
||||
opacity: 0.5;
|
||||
transition: opacity calc(var(--dl-speed) * 1.2) var(--dl-easing);
|
||||
.gallery-stack-btn:hover {
|
||||
border-color: var(--color-charcoal);
|
||||
}
|
||||
.disclosure-tab-icon {
|
||||
position: absolute;
|
||||
bottom: var(--spacing-sm);
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
font-size: 1rem;
|
||||
color: var(--color-accent);
|
||||
font-weight: 600;
|
||||
opacity: 0.5;
|
||||
transition: opacity calc(var(--dl-speed) * 1.2) var(--dl-easing);
|
||||
.gallery-stack {
|
||||
position: relative;
|
||||
width: calc(100% - 20px);
|
||||
aspect-ratio: 3 / 2;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
.disclosure-item[data-active='true'] .disclosure-tab-label {
|
||||
opacity: 1;
|
||||
}
|
||||
.disclosure-item[data-active='true'] .disclosure-tab-icon {
|
||||
opacity: 0;
|
||||
}
|
||||
.disclosure-content {
|
||||
.gallery-stack-card {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: calc(var(--dl-article-width, 600) * 1px);
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
border-radius: 8px;
|
||||
overflow: hidden;
|
||||
opacity: 0;
|
||||
transition: opacity calc(var(--dl-speed) * 1.2) var(--dl-easing);
|
||||
}
|
||||
.disclosure-item[data-active='true'] .disclosure-content {
|
||||
opacity: 1;
|
||||
transition-delay: calc(var(--dl-speed) * 0.2);
|
||||
}
|
||||
.disclosure-content-inner {
|
||||
padding: var(--spacing-sm) var(--spacing-md) var(--spacing-md) calc(var(--dl-base) + var(--spacing-sm));
|
||||
flex: 1;
|
||||
overflow-y: auto;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
.disclosure-columns {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-sm);
|
||||
}
|
||||
.disclosure-toggle {
|
||||
display: inline-flex;
|
||||
gap: 0;
|
||||
border: 1px solid var(--color-mist);
|
||||
border-radius: 5px;
|
||||
overflow: hidden;
|
||||
flex-shrink: 0;
|
||||
align-self: flex-end;
|
||||
margin: var(--spacing-sm) var(--spacing-sm) 0 0;
|
||||
text-decoration: none;
|
||||
background: white;
|
||||
transition: transform 0.45s cubic-bezier(0.16, 1, 0.3, 1), opacity 0.35s ease, box-shadow 0.35s ease;
|
||||
will-change: transform, opacity;
|
||||
}
|
||||
.disclosure-toggle-btn {
|
||||
font-family: var(--font-body);
|
||||
font-size: 0.625rem;
|
||||
.gallery-stack-card img {
|
||||
flex: 1;
|
||||
min-height: 0;
|
||||
width: 100%;
|
||||
object-fit: cover;
|
||||
object-position: top left;
|
||||
}
|
||||
.gallery-stack-label {
|
||||
padding: 6px 10px;
|
||||
font-size: 0.6875rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
border: none;
|
||||
padding: 3px 10px;
|
||||
cursor: pointer;
|
||||
background: none;
|
||||
color: var(--color-ash);
|
||||
transition: background var(--duration-fast), color var(--duration-fast);
|
||||
color: var(--color-charcoal);
|
||||
flex-shrink: 0;
|
||||
}
|
||||
.disclosure-toggle-btn + .disclosure-toggle-btn {
|
||||
border-left: 1px solid var(--color-mist);
|
||||
.gallery-stack-card[data-offset="0"] {
|
||||
z-index: 3;
|
||||
transform: translate(0, 0);
|
||||
opacity: 1;
|
||||
box-shadow: 0 2px 12px oklch(0.2 0 0 / 0.1);
|
||||
}
|
||||
.disclosure-toggle-btn.is-active {
|
||||
background: oklch(97% 0.005 350);
|
||||
color: var(--color-ink);
|
||||
.gallery-stack-card[data-offset="1"] {
|
||||
z-index: 2;
|
||||
transform: translate(8px, 8px);
|
||||
opacity: 1;
|
||||
box-shadow: 0 1px 6px oklch(0.2 0 0 / 0.08);
|
||||
pointer-events: none;
|
||||
}
|
||||
.disclosure-toggle-btn--anti.is-active {
|
||||
.gallery-stack-card[data-offset="2"] {
|
||||
z-index: 1;
|
||||
transform: translate(16px, 16px);
|
||||
opacity: 1;
|
||||
box-shadow: 0 1px 4px oklch(0.2 0 0 / 0.06);
|
||||
pointer-events: none;
|
||||
}
|
||||
.gallery-stack-card:not([data-offset="0"]):not([data-offset="1"]):not([data-offset="2"]) {
|
||||
z-index: 0;
|
||||
transform: translate(20px, 20px);
|
||||
opacity: 0;
|
||||
pointer-events: none;
|
||||
}
|
||||
.gallery-stack-link {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 500;
|
||||
color: var(--color-accent);
|
||||
text-decoration: none;
|
||||
text-align: center;
|
||||
}
|
||||
.disclosure-toggle-btn--do.is-active {
|
||||
color: var(--color-success, #22c55e);
|
||||
.gallery-stack-link:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
.disclosure-col[hidden] {
|
||||
@media (max-width: 900px) {
|
||||
.antidote-row {
|
||||
flex-direction: column;
|
||||
}
|
||||
.gallery-stack-container {
|
||||
flex: none;
|
||||
width: 100%;
|
||||
max-width: 360px;
|
||||
}
|
||||
}
|
||||
.patterns-tabbed {
|
||||
margin-bottom: var(--spacing-xl);
|
||||
background: white;
|
||||
border-radius: 8px;
|
||||
padding: var(--spacing-lg);
|
||||
}
|
||||
.patterns-tabs {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 6px;
|
||||
margin-bottom: var(--spacing-md);
|
||||
}
|
||||
.patterns-tab {
|
||||
font-family: var(--font-body);
|
||||
font-size: 0.6875rem;
|
||||
font-weight: 500;
|
||||
color: var(--color-charcoal);
|
||||
background: none;
|
||||
border: none;
|
||||
border-radius: 100px;
|
||||
padding: 6px 12px;
|
||||
cursor: pointer;
|
||||
transition: background 0.2s ease, color 0.2s ease;
|
||||
}
|
||||
.patterns-tab:hover {
|
||||
background: var(--color-mist);
|
||||
}
|
||||
.patterns-tab.is-active {
|
||||
background: var(--color-ink);
|
||||
color: var(--color-paper);
|
||||
}
|
||||
.patterns-content {
|
||||
display: none;
|
||||
}
|
||||
.disclosure-col ul {
|
||||
.patterns-content.is-active {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
.patterns-col ul {
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
@@ -4075,8 +4106,8 @@ code {
|
||||
flex-direction: column;
|
||||
gap: 6px;
|
||||
}
|
||||
.disclosure-col li {
|
||||
font-size: 0.9375rem;
|
||||
.patterns-col li {
|
||||
font-size: 0.8125rem;
|
||||
line-height: 1.55;
|
||||
padding-left: var(--spacing-sm);
|
||||
position: relative;
|
||||
@@ -4084,147 +4115,20 @@ code {
|
||||
overflow-wrap: break-word;
|
||||
word-break: break-word;
|
||||
}
|
||||
.disclosure-col-label {
|
||||
display: block;
|
||||
font-size: 0.625rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.1em;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.disclosure-col-label--anti {
|
||||
color: var(--color-accent);
|
||||
}
|
||||
.disclosure-col-label--do {
|
||||
color: var(--color-success, #22c55e);
|
||||
}
|
||||
.disclosure-col[data-col='anti'] li::before {
|
||||
.patterns-col--dont li::before {
|
||||
content: '\00d7';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
color: var(--color-accent);
|
||||
font-weight: 600;
|
||||
}
|
||||
.disclosure-col[data-col='do'] li::before {
|
||||
.patterns-col--do li::before {
|
||||
content: '\2713';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
color: var(--color-success, #22c55e);
|
||||
font-weight: 600;
|
||||
}
|
||||
@media (max-width: 768px) {
|
||||
.disclosure-list {
|
||||
grid-template-columns: 1fr;
|
||||
grid-template-rows: 10fr 1fr 1fr 1fr 1fr 1fr 1fr 1fr;
|
||||
height: auto;
|
||||
min-height: 500px;
|
||||
transition: grid-template-rows var(--dl-speed) var(--dl-easing);
|
||||
}
|
||||
.disclosure-item {
|
||||
min-width: 0;
|
||||
min-height: var(--dl-base);
|
||||
}
|
||||
.disclosure-tab-label {
|
||||
rotate: none;
|
||||
top: 50%;
|
||||
left: var(--spacing-md);
|
||||
transform: translateY(-50%);
|
||||
}
|
||||
.disclosure-tab-icon {
|
||||
bottom: 50%;
|
||||
left: auto;
|
||||
right: var(--spacing-md);
|
||||
transform: translateY(50%);
|
||||
}
|
||||
.disclosure-content-inner {
|
||||
padding: calc(var(--dl-base) + var(--spacing-sm)) var(--spacing-md) var(--spacing-md);
|
||||
}
|
||||
.disclosure-columns {
|
||||
grid-template-columns: 1fr;
|
||||
gap: var(--spacing-md);
|
||||
}
|
||||
}
|
||||
.antidote-row {
|
||||
display: flex;
|
||||
gap: var(--spacing-lg);
|
||||
align-items: stretch;
|
||||
margin-bottom: var(--spacing-lg);
|
||||
}
|
||||
.antidote-row .antidote-grid {
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
margin-bottom: 0;
|
||||
}
|
||||
.gallery-sidebar {
|
||||
flex: 0 0 32%;
|
||||
min-width: 0;
|
||||
max-width: 400px;
|
||||
border: 1px solid var(--color-mist);
|
||||
border-radius: 12px;
|
||||
padding: var(--spacing-sm);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: var(--spacing-xs);
|
||||
overflow: hidden;
|
||||
max-height: clamp(320px, 38dvh, 420px);
|
||||
}
|
||||
.gallery-sidebar-title {
|
||||
font-family: var(--font-display);
|
||||
font-size: 1.125rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-ink);
|
||||
padding: var(--spacing-xs) var(--spacing-xs) 0;
|
||||
}
|
||||
.gallery-sidebar-scroll {
|
||||
flex: 1;
|
||||
overflow-y: auto;
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 6px;
|
||||
scrollbar-width: none;
|
||||
}
|
||||
.gallery-sidebar-scroll::-webkit-scrollbar {
|
||||
display: none;
|
||||
}
|
||||
.gallery-sidebar-card {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 4px;
|
||||
padding: 4px;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
overflow: hidden;
|
||||
transition: background var(--duration-fast) var(--ease-out);
|
||||
}
|
||||
.gallery-sidebar-card:hover {
|
||||
background: oklch(97% 0.005 350);
|
||||
}
|
||||
.gallery-sidebar-card img {
|
||||
width: 100%;
|
||||
height: 72px;
|
||||
object-fit: cover;
|
||||
object-position: top left;
|
||||
border-radius: 6px;
|
||||
border: 1px solid var(--color-mist);
|
||||
}
|
||||
.gallery-sidebar-label {
|
||||
font-size: 0.6875rem;
|
||||
font-weight: 600;
|
||||
color: var(--color-charcoal);
|
||||
padding: 0 2px;
|
||||
}
|
||||
.gallery-sidebar-link {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 500;
|
||||
color: var(--color-accent);
|
||||
text-decoration: none;
|
||||
text-align: center;
|
||||
padding: var(--spacing-xs) 0 0;
|
||||
border-top: 1px solid var(--color-mist);
|
||||
}
|
||||
.gallery-sidebar-link:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
.detection-callout {
|
||||
margin-bottom: var(--spacing-xl);
|
||||
border: 1px solid var(--color-mist);
|
||||
@@ -4275,25 +4179,6 @@ code {
|
||||
content: '\279C ';
|
||||
color: var(--color-accent);
|
||||
}
|
||||
@media (max-width: 1060px) {
|
||||
.antidote-row {
|
||||
flex-direction: column;
|
||||
}
|
||||
.gallery-sidebar {
|
||||
flex: none;
|
||||
width: 100%;
|
||||
max-width: none;
|
||||
max-height: none;
|
||||
}
|
||||
.gallery-sidebar-scroll {
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
}
|
||||
}
|
||||
@media (max-width: 600px) {
|
||||
.gallery-sidebar-scroll {
|
||||
grid-template-columns: 1fr 1fr;
|
||||
}
|
||||
}
|
||||
.antidote-footer {
|
||||
text-align: center;
|
||||
}
|
||||
@@ -4395,13 +4280,10 @@ code {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
}
|
||||
.install-path:first-child {
|
||||
border-right: 1px solid var(--color-mist);
|
||||
padding-right: var(--spacing-xl);
|
||||
}
|
||||
.install-path-secondary {
|
||||
border-right: 1px solid var(--color-mist);
|
||||
padding-right: var(--spacing-xl);
|
||||
.install-path-primary {
|
||||
background: white;
|
||||
border-radius: 16px;
|
||||
padding: var(--spacing-lg);
|
||||
}
|
||||
.install-path-label {
|
||||
font-family: var(--font-mono);
|
||||
@@ -4411,6 +4293,9 @@ code {
|
||||
letter-spacing: 0.14em;
|
||||
color: var(--color-accent);
|
||||
}
|
||||
.install-path:not(.install-path-primary) {
|
||||
padding-top: var(--spacing-lg);
|
||||
}
|
||||
.install-path-secondary .install-path-label {
|
||||
color: var(--color-ash);
|
||||
}
|
||||
@@ -4627,11 +4512,8 @@ a.install-updated-ref:hover {
|
||||
grid-template-columns: 1fr;
|
||||
gap: var(--spacing-xl);
|
||||
}
|
||||
.install-path:first-child, .install-path-secondary {
|
||||
border-right: none;
|
||||
padding-right: 0;
|
||||
padding-bottom: var(--spacing-xl);
|
||||
border-bottom: 1px solid var(--color-mist);
|
||||
.install-path-primary {
|
||||
margin-bottom: var(--spacing-sm);
|
||||
}
|
||||
}
|
||||
.install-terminal {
|
||||
@@ -4781,10 +4663,6 @@ a.install-updated-ref:hover {
|
||||
color: var(--color-charcoal);
|
||||
}
|
||||
.install-alternatives-content {
|
||||
border: 1px solid var(--color-mist);
|
||||
border-radius: 8px;
|
||||
background: var(--color-paper);
|
||||
overflow: hidden;
|
||||
animation: altFadeIn 0.2s var(--ease-out);
|
||||
}
|
||||
@keyframes altFadeIn {
|
||||
|
||||
+27
-20
@@ -165,48 +165,55 @@
|
||||
<div class="antidote-content">
|
||||
<p class="section-lead" data-reveal>Every AI model learned from the same templates. Without intervention, they all produce the same predictable mistakes. Impeccable names them, detects them, and teaches the AI to avoid them.</p>
|
||||
|
||||
<!-- Anti-pattern cards + gallery teaser side by side -->
|
||||
<!-- Patterns + Gallery side by side -->
|
||||
<div class="antidote-row" data-reveal>
|
||||
<div class="antidote-grid" id="patterns-categories">
|
||||
<!-- Pattern reference — tabbed categories -->
|
||||
<div class="patterns-tabbed" id="patterns-categories">
|
||||
<!-- Rendered by JS -->
|
||||
</div>
|
||||
<div class="gallery-sidebar">
|
||||
<h3 class="gallery-sidebar-title">Gallery of Shame</h3>
|
||||
<div class="gallery-sidebar-scroll">
|
||||
<a href="/antipattern-examples/purple-gradients.html" class="gallery-sidebar-card">
|
||||
|
||||
<!-- Gallery of Shame — 3D card stack -->
|
||||
<div class="gallery-stack-container">
|
||||
<div class="gallery-stack-header">
|
||||
<h3 class="gallery-stack-title">Gallery of Shame</h3>
|
||||
<button class="gallery-stack-btn gallery-stack-prev" aria-label="Previous">←</button>
|
||||
<button class="gallery-stack-btn gallery-stack-next" aria-label="Next">→</button>
|
||||
</div>
|
||||
<div class="gallery-stack" id="gallery-stack">
|
||||
<a href="/antipattern-examples/purple-gradients.html" class="gallery-stack-card">
|
||||
<img src="antipattern-images/purple-gradients.png" alt="Purple gradient UI" loading="lazy">
|
||||
<span class="gallery-sidebar-label">Purple Gradients</span>
|
||||
<span class="gallery-stack-label">Purple Gradients</span>
|
||||
</a>
|
||||
<a href="/antipattern-examples/thick-border-cards.html" class="gallery-sidebar-card">
|
||||
<a href="/antipattern-examples/thick-border-cards.html" class="gallery-stack-card">
|
||||
<img src="antipattern-images/thick-border-cards.png" alt="Thick border accent cards" loading="lazy">
|
||||
<span class="gallery-sidebar-label">Side-Tab Cards</span>
|
||||
<span class="gallery-stack-label">Side-Tab Cards</span>
|
||||
</a>
|
||||
<a href="/antipattern-examples/cardocalypse.html" class="gallery-sidebar-card">
|
||||
<a href="/antipattern-examples/cardocalypse.html" class="gallery-stack-card">
|
||||
<img src="antipattern-images/cardocalypse.png" alt="Cards nested inside cards" loading="lazy">
|
||||
<span class="gallery-sidebar-label">Cardocalypse</span>
|
||||
<span class="gallery-stack-label">Cardocalypse</span>
|
||||
</a>
|
||||
<a href="/antipattern-examples/inter-everywhere.html" class="gallery-sidebar-card">
|
||||
<a href="/antipattern-examples/inter-everywhere.html" class="gallery-stack-card">
|
||||
<img src="antipattern-images/inter-everywhere.png" alt="Inter font everywhere" loading="lazy">
|
||||
<span class="gallery-sidebar-label">Inter Everywhere</span>
|
||||
<span class="gallery-stack-label">Inter Everywhere</span>
|
||||
</a>
|
||||
<a href="/antipattern-examples/layout-templates.html" class="gallery-sidebar-card">
|
||||
<a href="/antipattern-examples/layout-templates.html" class="gallery-stack-card">
|
||||
<img src="antipattern-images/layout-templates.png" alt="Generic layout templates" loading="lazy">
|
||||
<span class="gallery-sidebar-label">Template Layouts</span>
|
||||
<span class="gallery-stack-label">Template Layouts</span>
|
||||
</a>
|
||||
<a href="/antipattern-examples/bad-contrast.html" class="gallery-sidebar-card">
|
||||
<a href="/antipattern-examples/bad-contrast.html" class="gallery-stack-card">
|
||||
<img src="antipattern-images/bad-contrast.png" alt="Low contrast text" loading="lazy">
|
||||
<span class="gallery-sidebar-label">Bad Contrast</span>
|
||||
<span class="gallery-stack-label">Bad Contrast</span>
|
||||
</a>
|
||||
</div>
|
||||
<a href="/gallery" class="gallery-sidebar-link">View all →</a>
|
||||
<a href="/gallery" class="gallery-stack-link">View full gallery →</a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Detection callout (full width below) -->
|
||||
<div class="detection-callout" data-reveal>
|
||||
<div class="detection-callout-inner">
|
||||
<span class="detection-badge">Deterministic</span>
|
||||
<p class="detection-desc">25 patterns are caught automatically by the CLI and browser overlay -- no LLM needed. The rest are caught by <code>/critique</code> through design analysis.</p>
|
||||
<span class="detection-badge">New!</span>
|
||||
<p class="detection-desc">24 patterns are caught automatically by the CLI and browser overlay -- no LLM needed. The rest are caught by <code>/critique</code> through design analysis.</p>
|
||||
<code class="detection-cmd">npx impeccable detect src/</code>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: craft
|
||||
description: "Design and build ideal UX+UI for a feature through guided discovery. Interviews the user about purpose, audience, and design goals before implementing. Use when building a new feature, redesigning an existing one, or when the user wants a thoughtful, user-centered design process rather than jumping straight to code."
|
||||
argument-hint: "[feature to design]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke {{command_prefix}}impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run {{command_prefix}}impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
Build the ideal UX and UI for a feature. This skill is about getting the design RIGHT before writing code -- through structured discovery, not guesswork.
|
||||
|
||||
**Scope**: UX + UI design and implementation. Out of scope: building the underlying business logic, backend, or data layer. If the feature needs backend work, note what's needed but focus on the interface.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply, then build precisely.
|
||||
|
||||
## Phase 1: Discovery Interview
|
||||
|
||||
**Do NOT write any code during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions.
|
||||
|
||||
Ask these questions in conversation, adapting based on answers. Don't dump them all at once -- have a natural dialogue. {{ask_instruction}}
|
||||
|
||||
### Purpose & Context
|
||||
- What is this feature for? What problem does it solve?
|
||||
- Who specifically will use it? (Not "users" -- be specific: role, context, frequency)
|
||||
- What does success look like? How will you know this feature is working?
|
||||
- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
|
||||
|
||||
### Content & Data
|
||||
- What content or data does this feature display or collect?
|
||||
- What are the realistic ranges? (Minimum, typical, maximum -- e.g., 0 items, 5 items, 500 items)
|
||||
- What are the edge cases? (Empty state, error state, first-time use, power user)
|
||||
- Is any content dynamic? What changes and how often?
|
||||
|
||||
### Design Goals
|
||||
- What's the single most important thing a user should do or understand here?
|
||||
- What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
|
||||
- Are there existing patterns in the product this should be consistent with?
|
||||
- Are there specific examples (inside or outside the product) that capture what you're going for?
|
||||
|
||||
### Constraints
|
||||
- Are there technical constraints? (Framework, performance budget, browser support)
|
||||
- Are there content constraints? (Localization, dynamic text length, user-generated content)
|
||||
- Mobile/responsive requirements?
|
||||
- Accessibility requirements beyond WCAG AA?
|
||||
|
||||
### Anti-Goals
|
||||
- What should this NOT be? What would be a wrong direction?
|
||||
- What's the biggest risk of getting this wrong?
|
||||
|
||||
## Phase 2: Design Synthesis
|
||||
|
||||
After the interview, synthesize your understanding before touching code. Present this back to the user for confirmation:
|
||||
|
||||
1. **Feature brief** (2-3 sentences): What this is, who it's for, what it needs to accomplish
|
||||
2. **Primary user action**: The one thing that matters most
|
||||
3. **Design direction**: How this should feel, what aesthetic approach fits
|
||||
4. **Key states**: List every state the feature needs (default, empty, loading, error, success, edge cases)
|
||||
5. **Open questions**: Anything unresolved that might change the approach
|
||||
|
||||
{{ask_instruction}} -- get explicit confirmation before proceeding. If the user disagrees with your synthesis, revisit the relevant discovery questions.
|
||||
|
||||
## Phase 3: Implementation
|
||||
|
||||
Now build it. Use {{command_prefix}}impeccable as your design engine -- follow its principles, consult its references, avoid its anti-patterns.
|
||||
|
||||
### Implementation Order
|
||||
1. **Structure first**: HTML/semantic structure for the primary state. No styling yet.
|
||||
2. **Layout and spacing**: Establish the spatial rhythm and visual hierarchy.
|
||||
3. **Typography and color**: Apply the type scale and color system.
|
||||
4. **Interactive states**: Hover, focus, active, disabled.
|
||||
5. **Edge case states**: Empty, loading, error, overflow, first-run.
|
||||
6. **Motion**: Purposeful transitions and animations (if appropriate).
|
||||
7. **Responsive**: Adapt for different viewports -- don't just shrink, redesign for the context.
|
||||
|
||||
### During Implementation
|
||||
- Test with real (or realistic) data at every step, not placeholder text
|
||||
- Check each state as you build it, not all at the end
|
||||
- If you discover a design question during implementation, stop and ask rather than guessing
|
||||
- Every visual choice should trace back to something learned in discovery
|
||||
|
||||
## Phase 4: Validation
|
||||
|
||||
After implementation, run {{command_prefix}}validate on your work. Fix any P0 or P1 issues before presenting to the user.
|
||||
|
||||
Then present the result:
|
||||
- Show the feature in its primary state
|
||||
- Walk through the key states (empty, error, responsive)
|
||||
- Explain design decisions that connect back to what you learned in discovery
|
||||
- Ask for feedback: "What's working? What isn't?"
|
||||
|
||||
Iterate based on feedback. Good design is rarely right on the first pass.
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: validate
|
||||
description: "Fast visual validation after UX/UI changes. Checks anti-patterns, spacing consistency, design system adherence, and copy quality in a single pass. Use after completing any UI work, when the user wants a quick quality check, or proactively after implementing a feature."
|
||||
argument-hint: "[area to validate]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Invoke {{command_prefix}}impeccable -- it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding -- if no design context exists yet, you MUST run {{command_prefix}}impeccable teach first.
|
||||
|
||||
---
|
||||
|
||||
A fast, focused quality gate. Not a full audit or critique -- this is the 2-minute check you run after every UI change to catch the most common and damaging issues before they ship.
|
||||
|
||||
Think of this as a design linter: opinionated, fast, and actionable. Flag what's wrong, say how to fix it, move on.
|
||||
|
||||
## When to Run
|
||||
|
||||
Run {{command_prefix}}validate after:
|
||||
- Implementing or modifying any UI component
|
||||
- Completing a feature's visual design
|
||||
- Before requesting a design review from a human
|
||||
- Any time you're about to mark UI work as "done"
|
||||
|
||||
## Validation Pass
|
||||
|
||||
Read the changed files. If browser automation is available, take a screenshot for visual inspection. Then run through ALL of the following checks in a single pass. Be fast and direct.
|
||||
|
||||
### 1. Anti-Pattern Scan
|
||||
|
||||
Check against ALL **DON'T** guidelines in the impeccable skill. The most common offenders:
|
||||
- AI color palette (purple gradients, cyan-on-dark, neon glows)
|
||||
- Identical card grids, hero metric layouts
|
||||
- Overused fonts (Inter, Roboto, system defaults)
|
||||
- Glassmorphism, gradient text, dark-mode-by-default
|
||||
- Cards inside cards, everything centered, modals for everything
|
||||
|
||||
**The test**: Would someone immediately guess an AI made this?
|
||||
|
||||
### 2. Spacing & Rhythm
|
||||
|
||||
- Are margins, paddings, and gaps consistent within the same visual context?
|
||||
- Is there varied rhythm (tight groupings vs generous separations), or is everything evenly spaced?
|
||||
- Do similar elements at the same hierarchy level use the same spacing?
|
||||
- Are spacing values from the design system tokens, or are there magic numbers?
|
||||
|
||||
### 3. Design System Adherence
|
||||
|
||||
- Are colors from the project's palette/tokens, or are there one-off hex values?
|
||||
- Are font sizes, weights, and families from the type scale?
|
||||
- Do border radii, shadows, and transitions match existing patterns?
|
||||
- Are interactive elements styled consistently with others of the same type?
|
||||
|
||||
### 4. Visual Consistency
|
||||
|
||||
- Do elements that should look the same actually look the same?
|
||||
- Is the visual hierarchy clear? (One primary action, clear reading order)
|
||||
- Are alignment and grid lines maintained across the section?
|
||||
- Do hover/focus/active states exist and feel consistent?
|
||||
|
||||
### 5. Copy Quality
|
||||
|
||||
- Is any text redundant with what's already visible? (Headers restating the page title, labels repeating obvious context)
|
||||
- Are labels, buttons, and messages concise? Every word should earn its place.
|
||||
- Is the tone consistent with the rest of the interface?
|
||||
- Are error/empty/loading states handled with helpful copy?
|
||||
|
||||
## Output Format
|
||||
|
||||
Report findings as a flat list, grouped by severity:
|
||||
|
||||
**Severity levels:**
|
||||
- **P0 -- Broken**: Visually broken, inaccessible, or fundamentally wrong. Fix before shipping.
|
||||
- **P1 -- Anti-pattern**: Clear design anti-pattern that undermines quality. Fix now.
|
||||
- **P2 -- Inconsistency**: Spacing, token, or style drift from the design system. Fix soon.
|
||||
- **P3 -- Polish**: Minor refinement opportunity. Fix if time allows.
|
||||
|
||||
For each finding:
|
||||
```
|
||||
[P0-P3] [Category] Short description of what's wrong
|
||||
→ Fix: Concrete action to take (file:line if applicable)
|
||||
```
|
||||
|
||||
Keep the total list short. If everything looks good, say so -- don't invent issues.
|
||||
|
||||
## After Validation
|
||||
|
||||
If P0 or P1 issues are found, fix them immediately. For P2/P3 issues, {{ask_instruction}} whether the user wants them addressed now or noted for later.
|
||||
|
||||
If the issues map cleanly to an existing command (e.g., spacing issues → {{command_prefix}}arrange, copy issues → {{command_prefix}}clarify), suggest that command instead of fixing manually.
|
||||
Reference in New Issue
Block a user