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>

.opencode/skills/audit/SKILL.md

@@ -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:
 

.opencode/skills/craft/SKILL.md

@@ -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.

.opencode/skills/critique/SKILL.md

@@ -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

.opencode/skills/validate/SKILL.md

@@ -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.