oh-my-opencode 4.13.0 → 4.14.0

package/packages/omo-codex/plugin/skills/frontend/references/designpowers/vendor/skills/design-system-alignment/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: design-system-alignment
+description: "Use when working with or building design systems — tokens, components, naming conventions, theming, or pattern libraries — ensures consistency, accessibility compliance, and systematic thinking"
+---
+
+# Design System Alignment
+
+A design system is a shared language. When components are consistent, accessible, and well-documented, every new screen starts from a strong foundation. This skill ensures design work aligns with existing systems or builds new ones with the right properties.
+
+## When to Use
+
+- A design system already exists and new work must align with it
+- Building new components for an existing system
+- Creating a new design system from scratch
+- Auditing an existing system for consistency or accessibility
+- Defining or modifying design tokens
+
+## Process
+
+### Step 1: Inventory the Existing System
+
+If a design system exists, catalogue:
+- **Tokens:** colours, spacing, typography, shadows, borders, motion
+- **Components:** what exists, what states are covered, accessibility status
+- **Patterns:** common layouts, form patterns, navigation patterns
+- **Documentation:** what is documented, what is tribal knowledge
+- **Gaps:** what is missing, inconsistent, or broken
+
+If no system exists, document what patterns are already in use (even informally).
+
+### Step 2: Token Architecture
+
+Design tokens are the atoms of the system. Structure them in layers:
+
+**Global tokens** — raw values
+```
+color-blue-500: #3B82F6
+spacing-4: 16px
+font-size-base: 1rem
+```
+
+**Semantic tokens** — purpose-driven aliases
+```
+color-primary: {color-blue-500}
+color-error: {color-red-600}
+spacing-element: {spacing-4}
+font-size-body: {font-size-base}
+```
+
+**Component tokens** — component-specific overrides
+```
+button-background: {color-primary}
+button-padding: {spacing-3} {spacing-4}
+input-border-color: {color-neutral-300}
+```
+
+Every token must meet accessibility requirements at the semantic level — if `color-primary` is used for text, it must have sufficient contrast against its background token.
+
+### Step 3: Component Specification
+
+For each component, document:
+
+```markdown
+## [Component Name]
+
+**Purpose:** [What this component is for]
+
+**Variants:** [e.g., primary, secondary, ghost, destructive]
+
+**States:** [default, hover, focus, active, disabled, error, loading]
+
+**Accessibility:**
+- Role: [ARIA role if not implicit]
+- Label: [How it is labelled — visible text, aria-label, aria-labelledby]
+- Keyboard: [How to interact via keyboard]
+- Screen reader: [What is announced in each state]
+- Focus: [Focus indicator style, focus order]
+
+**Tokens used:** [Which design tokens this component references]
+
+**Do:** [Correct usage examples]
+**Do not:** [Incorrect usage examples]
+```
+
+### Step 4: Naming Conventions
+
+Consistent naming makes a system learnable:
+
+- **Components:** PascalCase for components, kebab-case for tokens
+- **Descriptive names:** `AlertDialog` not `Modal2` or `PopupThing`
+- **State modifiers:** consistent pattern (e.g., `--disabled`, `--error`, `--active`)
+- **Size modifiers:** use a scale (sm, md, lg) or semantic names (compact, comfortable, spacious)
+
+### Step 5: Accessibility Audit
+
+For every component in the system, verify:
+
+| Check | Requirement |
+|-------|------------|
+| Colour contrast | All text/background pairings meet WCAG AA minimum |
+| Keyboard access | Every interactive component is reachable and operable via keyboard |
+| Screen reader | Every component announces its role, name, state, and value correctly |
+| Focus indicator | Every focusable element has a visible focus ring |
+| Touch targets | All interactive elements meet 44x44px minimum |
+| Motion | All animations respect prefers-reduced-motion |
+| Resize | Components function at 200% zoom |
+
+### Step 6: Document and Communicate
+
+A design system only works if people use it. Ensure:
+- Every component has usage documentation with examples
+- Accessibility requirements are documented per component, not in a separate "accessibility section"
+- Migration guides exist for any changes to existing components
+- The system is versioned so consumers know when changes occur
+
+## Integration
+
+- **Called by:** `ui-composition` (when components need to align with a system)
+- **Pairs with:** `ui-composition` (visual decisions), `accessible-content` (content patterns within components)
+- **Reviewed by:** `designpowers-critique`

package/packages/omo-codex/plugin/skills/frontend/references/designpowers/vendor/skills/designpowers-critique/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: designpowers-critique
+description: "Use when reviewing design work against a plan, design principles, or quality standards — provides structured critique covering design intent, accessibility, consistency, and user impact. This is the Designpowers critique skill — use this instead of the Superpowers design-critique when working within a Designpowers workflow"
+---
+
+# Design Critique
+
+Critique is a structured evaluation of whether the design achieves what it set out to do, for the people it set out to serve — and whether it does so with the craft quality the project demands. This skill ensures review is rigorous, specific, and constructive. When a taste profile exists, critique includes aesthetic evaluation against that profile — not arbitrary personal preference, but the specific emotional target, craft standards, and quality bar the team agreed on.
+
+## When to Use
+
+- After completing a design task or set of tasks
+- Before handoff to engineering
+- When a design decision feels uncertain
+- At scheduled review points in a design plan
+
+## Process
+
+### Step 1: Gather Review Inputs
+
+Before critiquing, assemble:
+- The design brief (from design-discovery)
+- The design plan (from writing-design-plans)
+- The design principles (from design-strategy)
+- The personas (from inclusive-personas)
+- The current design artefacts (mockups, code, prototypes)
+
+### Step 2: Evaluate Against Intent
+
+For each design decision, ask:
+1. **Does it solve the stated problem?** Refer to the design brief
+2. **Does it serve the identified personas?** All of them, not just the primary user
+3. **Does it follow the design principles?** Specifically which principles it upholds or violates
+4. **Does it align with the design system?** If applicable
+
+### Step 3: Craft and Taste Evaluation
+
+If a taste profile exists (from `design-taste`), evaluate the design against it:
+
+**Emotional target:**
+- [ ] Does the design evoke the intended feeling? (Reference the taste profile's emotional target)
+- [ ] Would the user describe this experience with the words in the emotional target?
+
+**Craft standards:**
+- [ ] Spacing has intentional rhythm — not just "correct," but considered
+- [ ] Colour usage follows the restraint/vibrancy rules in the taste profile
+- [ ] Shadows, borders, and radii use a consistent vocabulary
+- [ ] Typography choices serve both readability and personality
+- [ ] The overall composition feels cohesive — like one designer, not a committee
+
+**Reference benchmark:**
+- [ ] This design would sit comfortably next to the taste references
+- [ ] The quality level matches what was agreed (prototype/production/flagship)
+
+**Craft findings format:**
+| Element | Taste expectation | Current state | Gap |
+|---------|------------------|---------------|-----|
+| [Element] | [What the taste profile calls for] | [What exists] | [Specific difference] |
+
+If no taste profile exists, note this as an observation: "No taste profile was created for this project. Craft evaluation is based on general quality standards only."
+
+### Step 4: Accessibility Review
+
+Every critique includes an accessibility evaluation:
+
+**Perceivable:**
+- [ ] All content is available to screen readers
+- [ ] Colour is not the sole indicator of meaning
+- [ ] Contrast ratios meet WCAG AA minimum
+- [ ] Text is resizable to 200% without loss of function
+- [ ] Alt text is present and appropriate
+
+**Operable:**
+- [ ] All interactions are keyboard accessible
+- [ ] Focus order is logical
+- [ ] Focus indicators are visible
+- [ ] Touch targets meet 44x44px minimum
+- [ ] Motion respects prefers-reduced-motion
+- [ ] No keyboard traps
+
+**Understandable:**
+- [ ] Language is plain and clear
+- [ ] Navigation is consistent
+- [ ] Error messages explain the problem and the solution
+- [ ] Form labels are visible and associated
+- [ ] Behaviour is predictable
+
+**Robust:**
+- [ ] Semantic HTML is used correctly
+- [ ] ARIA is used only when necessary and correctly
+- [ ] The design works across supported browsers and assistive technology
+
+### Step 5: Classify Issues
+
+Rate each finding:
+
+| Severity | Definition | Action |
+|----------|-----------|--------|
+| **Critical** | Blocks access for some users or violates the design intent | Must fix before proceeding |
+| **Major** | Degrades experience significantly but does not block access | Should fix before handoff |
+| **Minor** | Improvement opportunity, does not block or significantly degrade | Fix if time allows |
+| **Note** | Observation or suggestion for future iteration | Document for next cycle |
+
+### Step 6: Write the Critique
+
+```markdown
+# Design Critique: [Feature/Task Name]
+
+**Reviewed against:** [Design brief, plan, principles — with references]
+
+**Date:** [YYYY-MM-DD]
+
+## Summary
+[2-3 sentences: overall assessment]
+
+## Craft Assessment
+[Does the design meet the taste profile's quality bar? Emotional target alignment? Reference benchmark?]
+
+## Findings
+
+### Critical
+- [Finding]: [Explanation] → [Recommended action]
+
+### Major
+- [Finding]: [Explanation] → [Recommended action]
+
+### Minor
+- [Finding]: [Explanation] → [Recommended action]
+
+### Notes
+- [Observation]
+
+## Accessibility Status
+[Pass/Fail against WCAG AA with specific gaps]
+
+## Recommendation
+[Proceed / Revise and re-review / Rethink approach]
+```
+
+### Step 7: Present and Discuss
+
+Present findings to the user. For each critical or major issue, explain:
+- What the issue is
+- Who it affects (reference specific personas)
+- What the recommended fix is
+- Why it matters
+
+Critical issues block progress. They must be resolved before moving to handoff.
+
+### Step 8: Record Design Debt
+
+After the critique is complete and the fix round is determined:
+
+1. Identify all **Minor** and **Note** severity findings that will NOT be fixed in this round
+2. Invoke `design-debt-tracker` to capture these as debt items in the Design Debt Register
+3. Each deferred item must include: who is affected, suggested fix, and why it was deferred
+
+Do not silently drop Minor findings. They either get fixed or they get tracked.
+
+## Integration
+
+- **Called by:** `writing-design-plans` (at review checkpoints)
+- **Reviews output from:** `ui-composition`, `interaction-design`, `accessible-content`, `cognitive-accessibility`, `adaptive-interfaces`, `design-system-alignment`
+- **Calls:** Relevant design skills for fixes, `design-debt-tracker` for deferred findings, then `design-handoff` when critique passes

package/packages/omo-codex/plugin/skills/frontend/references/designpowers/vendor/skills/heuristic-evaluation/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: heuristic-evaluation
+description: "Use after a build to evaluate usability against Nielsen's 10 heuristics and run cognitive walkthroughs of every key task. Dispatches the heuristic-evaluator agent in parallel with design-critic and accessibility-reviewer, then feeds findings into the reconciliation protocol. This is the usability lens — \"will people actually be able to use this?\" — distinct from craft critique and accessibility audit"
+---
+
+# Heuristic Evaluation
+
+Heuristic evaluation is the usability lens on a build. Where `designpowers-critique` asks "does this match the plan?" and the accessibility review asks "can everyone access this?", heuristic evaluation asks "will people actually be able to use this without getting lost, confused, or stuck?" This skill dispatches the **heuristic-evaluator** agent and integrates its findings with the other reviewers.
+
+## When to Use
+
+- **After `design-builder` completes a build** — run alongside `designpowers-critique` and the accessibility review, not after them
+- Before a fix round, so usability findings are reconciled with craft and accessibility findings together
+- When a flow feels confusing but you can't articulate why — the heuristics name the problem
+- When evaluating an existing design (see `using-designpowers` → Review Mode), not just freshly built work
+
+This skill is **not optional after a build.** Skipping it is a Red Flag (see `using-designpowers`). Usability problems that craft critique and accessibility audits both miss are exactly what this catches.
+
+## Process
+
+### Step 1: Confirm Inputs Exist
+
+Before dispatching, assemble:
+- The **build** to evaluate (running app, prototype, or screenshots — test what was built, not the spec)
+- The **design brief** (from `design-discovery`) — for the key tasks to walk through
+- The **personas** (from `inclusive-personas`) — each persona's primary task gets a cognitive walkthrough
+- `design-state.md` — the shared state the agent will read and update
+
+If there is no brief or no list of key tasks, the cognitive walkthrough has nothing to walk through. Go back and capture the key tasks first.
+
+### Step 2: Dispatch the heuristic-evaluator Agent
+
+Dispatch the `heuristic-evaluator` agent (see `agents/heuristic-evaluator.md`). It will:
+
+1. Evaluate the interface against **Nielsen's 10 heuristics**, citing specific violations with evidence (H1–H10)
+2. Run a **cognitive walkthrough** of every key task — four questions per step
+3. Analyse **error paths**, not just happy paths — recovery, undo, back navigation, dead ends
+4. Assess **learnability** (first-time user) and **efficiency** (repeat user)
+5. Acknowledge what works well, not only what fails
+
+The agent narrates at three moments (arrival, working, departure) per the Agent Transparency protocol in `using-designpowers`.
+
+### Step 3: Run in Parallel and Reconcile
+
+Per the **Reconciliation Protocol** in `using-designpowers`, the heuristic-evaluator runs **simultaneously** with `design-critic` and the accessibility-reviewer:
+
+```
+design-builder finishes
+        |
+   ┌────┼────────┐
+   v    v        v
+critic  reviewer  heuristic    (run simultaneously)
+   |    |        |
+   └────┼────────┘
+        v
+  reconciliation
+```
+
+When findings overlap or conflict, classify them (Aligned / Complementary / Conflicting) and resolve using the protocol's priority rules. Remember: **usability wins over style** — a beautiful interface that confuses people has failed.
+
+### Step 4: Honour the Auto-Mode Safeguard
+
+Even in auto mode, the pipeline **must pause** if the heuristic-evaluator finds a critical **H3 violation** (no undo on a destructive action) or **H1 violation** (user is completely lost). These indicate structural problems, not polish issues, and the user should decide how to resolve them.
+
+> ⚠️ **Auto paused:** heuristic-evaluator found a critical usability issue (H3 — no undo on delete) that needs your decision. [details]
+
+### Step 5: Feed the Fix Round
+
+After reconciliation:
+1. The agent's findings join the single prioritised fix list (critical first)
+2. Note which findings the heuristic-evaluator sourced and whether any were reconciled with other reviewers
+3. **Record deferred Minor findings** in the Design Debt Register via `design-debt-tracker` — promises don't disappear because severity is low
+4. Re-run the heuristic-evaluator only on critical fixes after the build round, not the full evaluation
+
+## What You Get
+
+A structured heuristic evaluation report (see the agent definition for the full format): a heuristic findings table (H1–H10 with verdicts), cognitive walkthrough results per task, findings grouped by severity, what works well, and a recommendation (Proceed / Revise / Rethink).
+
+## Integration
+
+- **Runs after:** `design-builder` (build complete) — or against an existing design in Review Mode
+- **Runs alongside:** `designpowers-critique`, accessibility review (parallel, then reconciled)
+- **Feeds:** the reconciliation protocol → `design-builder` fix round → `synthetic-user-testing`
+- **Calls:** `design-debt-tracker` for deferred Minor findings
+- **Records to:** `design-state.md` (Decisions Log, Handoff Chain, Open Questions)

package/packages/omo-codex/plugin/skills/frontend/references/designpowers/vendor/skills/inclusive-personas/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: inclusive-personas
+description: "Use when defining who a design serves — creating personas, user stories, or scenarios — ensures the full ability spectrum and situational contexts are represented from the start, not retrofitted"
+---
+
+# Inclusive Personas
+
+Personas shape every design decision that follows. If your personas only represent able-bodied, neurotypical, tech-savvy adults with fast internet, your design will only work for those people. This skill ensures the full range of human experience is represented from the beginning.
+
+## The Principle
+
+"Nothing About Us Without Us." Design for the margins and the centre benefits. Design for the centre and the margins get excluded.
+
+## Process
+
+### Step 1: Map the Ability Spectrum
+
+For the design context, identify the relevant spectrum across:
+
+**Permanent conditions:**
+- Vision: blind, low vision, colour blind
+- Hearing: deaf, hard of hearing
+- Motor: limited fine motor, limited reach, tremor, paralysis
+- Cognitive: learning differences, memory challenges, attention differences
+- Speech: non-verbal, speech differences
+
+**Temporary conditions:**
+- Broken arm, ear infection, concussion, medication effects, post-surgery
+
+**Situational conditions:**
+- Bright sunlight, noisy environment, one hand occupied, driving, multitasking, emotional distress, unfamiliar language, slow connection
+
+### Step 2: Identify Relevant Personas
+
+Not every project needs every persona. Select 4-6 personas that represent:
+- **2-3 primary users** — the most common use cases
+- **1-2 edge case users** — people at the margins whose needs reveal design weaknesses
+- **1 stress case user** — someone using the design under difficult circumstances
+
+### Step 3: Build Each Persona
+
+For each persona, document:
+
+```markdown
+## [Name]
+
+**Context:** [Who they are, what they do, their relationship to this product]
+
+**Abilities and conditions:** [Permanent, temporary, or situational factors that affect how they interact with interfaces]
+
+**Technology:** [Devices, assistive technology, connection speed, technical confidence]
+
+**Goals:** [What they need to accomplish]
+
+**Frustrations:** [What typically goes wrong for them with similar products]
+
+**Environment:** [Where and when they use this — lighting, noise, distractions, time pressure]
+```
+
+### Step 4: Write Inclusive User Stories
+
+For each persona, write stories that capture:
+- The standard path: "As [persona], I want to [goal] so that [outcome]"
+- The assisted path: "As [persona] using [assistive technology], I want to [goal] so that [outcome]"
+- The stress path: "As [persona] under [stressful condition], I need to [goal] without [negative outcome]"
+
+### Step 5: Identify Scenario Intersections
+
+Map where personas overlap in unexpected ways:
+- A sighted user in bright sunlight has similar needs to a low-vision user
+- A stressed parent holding a baby has similar motor constraints to someone with limited hand mobility
+- A non-native speaker has similar needs to someone with a cognitive processing difference
+
+These intersections reveal universal design opportunities.
+
+### Step 6: Present and Validate
+
+Present personas to the user. Ask:
+- Who is missing from this set?
+- Do these feel like real people or cardboard cutouts?
+- Which persona makes you most uncomfortable? (That one probably needs the most attention)
+
+Save to: `docs/designpowers/personas/YYYY-MM-DD-<project>-personas.md`
+
+## Integration
+
+- **Called by:** `research-planning`, `design-discovery`
+- **Informs:** Every subsequent design skill — personas should be referenced when making any design decision
+- **Pairs with:** `cognitive-accessibility`, `adaptive-interfaces`
+
+## Anti-Patterns
+
+| Pattern | Problem |
+|---------|---------|
+| "Our users are everyone" | If everyone is your user, nobody is. Define specific people |
+| Personas without disabilities | You have excluded a quarter of the population |
+| Edge cases treated as afterthoughts | Edge cases reveal the quality of your design. They come first, not last |
+| Personas based on demographics alone | Age and job title do not determine how someone uses an interface. Focus on behaviour, ability, and context |

package/packages/omo-codex/plugin/skills/frontend/references/designpowers/vendor/skills/inspiration-scouting/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: inspiration-scouting
+description: "Use when the team needs aesthetic references, interaction examples, or visual inspiration beyond competitive research — finds design patterns, UI references, and creative approaches that match the brief and taste profile"
+---
+
+# Inspiration Scouting
+
+The design-scout does competitive research — who else solves this problem and how. Inspiration scouting is different. It finds aesthetic and interaction references that shape the *feel* of the design, even when they come from completely different domains. A banking app can be inspired by a meditation app's calm. A children's education tool can borrow pacing from a well-designed game.
+
+## When to Use
+
+- After design-discovery and design-strategy, before visual design begins
+- When the design-lead needs a visual direction and wants reference material
+- When the user says "show me some inspiration" or "what could this look like?"
+- When the taste profile exists but the project needs a fresh direction within it
+- When the team is stuck and needs outside input to break a creative block
+
+## Do Not Use When
+
+- The user has already provided specific visual references — use those directly
+- The design system is locked and visual direction is predetermined
+- The task is a fix or iteration, not a new direction
+
+## Process
+
+### Step 1: Define the Inspiration Brief
+
+Before searching, define what you're looking for:
+
+```markdown
+## Inspiration Brief
+
+**Project:** [Name and one-line description]
+**Feel we're going for:** [2-3 adjectives — e.g., "calm, confident, playful"]
+**Feel we're avoiding:** [2-3 adjectives — e.g., "clinical, childish, corporate"]
+**Taste constraints:** [From taste profile — known preferences and anti-patterns]
+**Domain:** [The project's domain — e.g., "pet care", "fintech", "education"]
+**Cross-domain openness:** [How far outside the domain to look — same domain / adjacent / anywhere]
+**Specific needs:** [e.g., "onboarding flow inspiration", "dashboard layout patterns", "empty state ideas"]
+```
+
+### Step 2: Search Across Layers
+
+Inspiration operates at multiple layers. Search each:
+
+#### Visual Layer
+- **Colour:** Palette approaches, colour psychology, brand colour usage
+- **Typography:** Type pairing, scale, weight distribution, editorial vs UI
+- **Layout:** Grid systems, density, whitespace philosophy, asymmetry
+- **Imagery:** Photography style, illustration approach, iconography
+- **Surface:** Texture, depth, glassmorphism, neumorphism, flat — what's appropriate
+
+#### Interaction Layer
+- **Navigation:** Patterns, transitions between views, wayfinding
+- **Feedback:** How the interface responds — micro-interactions, loading, success, error
+- **Onboarding:** First-run experiences, progressive disclosure, tutorials
+- **Data entry:** Form patterns, input methods, validation approaches
+- **Empty states:** What the app feels like before there's content
+
+#### Emotional Layer
+- **Personality:** How the interface expresses character through details
+- **Pacing:** Fast and efficient vs slow and contemplative
+- **Trust signals:** How the interface builds confidence
+- **Delight moments:** Where and how the interface surprises positively
+- **Restraint:** What the interface deliberately does *not* do
+
+### Step 3: Curate a Mood Board
+
+Compile findings into a structured mood board. Quality over quantity — 5 excellent references beat 20 mediocre ones.
+
+For each reference:
+
+```markdown
+### [Reference Name]
+**Source:** [App/site/product name and what it does]
+**Why it's relevant:** [1-2 sentences connecting this to the project brief]
+**What to take:** [The specific element or quality to learn from]
+**What to leave:** [What doesn't apply — this prevents wholesale copying]
+**Taste alignment:** [How it connects to the user's taste profile]
+**Layer:** Visual / Interaction / Emotional
+```
+
+### Step 4: Cross-Domain Connections
+
+The best inspiration often comes from outside the project's domain. Actively seek cross-domain references:
+
+| Project Domain | Look At |
+|---------------|---------|
+| Healthcare | Meditation apps (calm), fitness apps (motivation), journaling apps (reflection) |
+| Finance | Productivity tools (clarity), weather apps (data viz), news apps (hierarchy) |
+| Education | Games (engagement), music apps (progression), social apps (community) |
+| E-commerce | Editorial sites (storytelling), gallery apps (browsing), travel apps (discovery) |
+| Enterprise | Consumer apps (polish), design tools (power + clarity), documentation sites (wayfinding) |
+
+Don't force connections — but don't limit yourself to competitors either.
+
+### Step 5: Present the Board
+
+Present inspiration to the user and the design-lead as a curated collection:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  INSPIRATION BOARD
+  For: [Project Name]
+  Feel: [target adjectives]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  VISUAL DIRECTION
+  ◆ [Reference 1] — [what to take]
+  ◆ [Reference 2] — [what to take]
+
+  INTERACTION PATTERNS
+  ◆ [Reference 3] — [what to take]
+  ◆ [Reference 4] — [what to take]
+
+  EMOTIONAL TONE
+  ◆ [Reference 5] — [what to take]
+
+  CROSS-DOMAIN WILD CARD
+  ◆ [Reference 6] — [unexpected connection]
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Does any of this resonate? I can dig deeper
+  into any direction or find more references.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Step 6: Refine Based on Response
+
+The user's reaction to inspiration is a powerful taste signal:
+
+| Reaction | What to Do | Taste Signal |
+|----------|-----------|--------------|
+| "Love that" | Dig deeper into similar references | Strong positive — record in design-memory |
+| "Not quite" | Ask what's off — too bold? too safe? wrong tone? | Soft negative — refine search |
+| "That but calmer" | The direction is right, the intensity is wrong | Record the adjustment as a taste nuance |
+| "None of these" | Go back to Step 1 and redefine the feel | The inspiration brief needs rewriting |
+| "Number 3, but for the layout, not the colour" | User is compositing — they see the design in pieces | Record which layers resonate separately |
+
+After refinement, update the inspiration brief with what resonated and pass it to design-lead as part of their brief.
+
+## Integration With Taste Profile
+
+Inspiration is driven by **this project's** direction — the brief and the live taste calibration from `design-taste` — not by the cross-project design record. The `design-memory` record is observational and is **not** used to pre-filter or steer references; doing so would silently apply one project's habits to another. (If the user themselves says "I usually avoid gradients," that's live direction for this project — honour it because they said it now, not because a record predicted it.)
+
+You may still **record** new signals into `design-memory` as observations after the fact (see below) — that's watching, not steering.
+
+## Integration
+
+- **Called by:** `design-discovery` (to set visual direction), `design-strategy` (for positioning references), `using-designpowers` (when user requests inspiration)
+- **Calls:** `design-memory` (only to record new observations after the fact — never to read constraints that steer the scouting)
+- **Hands off to:** `design-lead` (with curated references as visual brief), `design-strategist` (with emotional/UX references)
+- **Pairs with:** `design-memory`, `design-debate` (inspiration can trigger a debate on direction)
+- **Updated by:** User reactions — every "love it" or "not for me" is a taste data point
+
+## Anti-Patterns
+
+| Pattern | Why It Fails |
+|---------|-------------|
+| Dumping 20 references without curation | Overwhelms. 5 excellent references with clear "what to take" beats 20 screenshots |
+| Only looking at competitors | Competitors solve the same problem the same way. Cross-domain references unlock fresh approaches |
+| Showing inspiration that violates accessibility | A beautiful reference with 2:1 contrast ratios is not inspiration — it's a cautionary tale. Flag accessibility issues in references |
+| Copying instead of being inspired | Inspiration means "take the quality, not the pixels." Always specify what to take and what to leave |
+| Ignoring this project's stated direction | If the user has said (now) they want a calm, gradient-free look, showing gradient-heavy references wastes their time. Drive from `design-taste`, not from the cross-project record |
+| Presenting without "what to take" | A reference without a clear lesson is decoration. Every reference needs a reason |