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
2026-04-02 09:59:11 -07:00
co-authored by Claude Opus 4.6
parent b5cd306e70
commit 3f7b5fd8bf
46 changed files with 2507 additions and 713 deletions
+97
View File
@@ -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.
+91
View File
@@ -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.