oh-my-opencode 4.13.0 → 4.14.1

package/dist/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 |

package/dist/skills/frontend/references/designpowers/vendor/skills/interaction-design/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: interaction-design
+description: "Use when designing states, transitions, animations, error handling, loading patterns, feedback, or any behaviour that responds to user action — ensures interactions are perceivable, operable, and inclusive"
+---
+
+# Interaction Design
+
+Interactions are promises. Every button says "click me and something will happen." Every loading spinner says "wait, it is coming." This skill ensures those promises are kept for everyone, regardless of how they interact with the interface.
+
+## When to Use
+
+- Designing component states (default, hover, active, focus, disabled, error)
+- Creating transitions or animations
+- Handling errors, empty states, or edge cases
+- Designing loading and progress patterns
+- Defining feedback mechanisms (success, warning, error confirmations)
+- Designing gesture or touch interactions
+
+## Process
+
+### Step 1: Map All States
+
+For every interactive element, define:
+
+| State | Visual | Screen Reader | Keyboard | Touch |
+|-------|--------|--------------|----------|-------|
+| Default | [appearance] | [announcement] | [behaviour] | [behaviour] |
+| Hover | [appearance] | n/a | n/a | n/a |
+| Focus | [appearance + focus ring] | [announcement] | [how to reach] | n/a |
+| Active/Pressed | [appearance] | [announcement] | [trigger key] | [gesture] |
+| Disabled | [appearance, not just greyed] | [announcement + reason] | [skip in tab order?] | [behaviour] |
+| Error | [appearance + message] | [announcement + guidance] | [focus moved?] | [behaviour] |
+| Loading | [appearance] | [live region update] | [interaction blocked?] | [behaviour] |
+| Success | [appearance] | [announcement] | [next focus target] | [behaviour] |
+
+### Step 2: Design Feedback Patterns
+
+Every user action deserves a response. Map the feedback:
+
+**Immediate feedback (< 100ms):**
+- Visual state change on interaction (button press, toggle flip)
+- Must be perceivable without relying on colour alone
+
+**Short wait feedback (100ms - 1s):**
+- Loading indicator or skeleton screen
+- ARIA live region announcement: "Loading..."
+
+**Long wait feedback (> 1s):**
+- Progress indicator with estimated time or progress percentage
+- Ability to cancel or navigate away
+- ARIA live region updates at intervals
+
+**Completion feedback:**
+- Clear success or error state
+- Screen reader announcement of outcome
+- Logical next focus target
+
+### Step 3: Error Handling
+
+Errors are not edge cases — they are guaranteed states. Design for them:
+
+1. **Prevention first** — inline validation, clear constraints, sensible defaults
+2. **Clear identification** — what went wrong, in plain language
+3. **Specific guidance** — what the person should do next
+4. **Accessible delivery** — errors announced to screen readers, focus moved to the error, not just a colour change
+5. **Recovery path** — preserve user input, allow correction without starting over
+
+Error message format: **[What happened] + [What to do about it]**
+- Yes: "That email address is already registered. Try signing in instead, or use a different email."
+- No: "Error: invalid input"
+
+### Step 4: Animation and Motion
+
+Animations serve a purpose or they serve nobody:
+
+**When to animate:**
+- To show a relationship between elements (a panel sliding in from its trigger)
+- To maintain spatial orientation (a page transition showing direction)
+- To provide feedback (a subtle bounce on a successful action)
+
+**When NOT to animate:**
+- Decoration without function
+- Anything that delays the user from completing their task
+- Anything that loops indefinitely
+
+**Inclusive motion:**
+- Respect `prefers-reduced-motion` — always provide a reduced or no-motion alternative
+- Keep durations short: 150-300ms for micro-interactions, 300-500ms for transitions
+- Avoid parallax, auto-playing video, flashing content (3 flashes per second maximum per WCAG)
+- Provide pause/stop controls for any animation longer than 5 seconds
+
+### Step 5: Gesture and Input Design
+
+If the design includes gesture interactions:
+- Every gesture must have a non-gesture alternative (button, keyboard shortcut)
+- Swipe actions must be discoverable without trial-and-error
+- Drag-and-drop must have a keyboard-accessible alternative
+- Touch targets: 44x44px minimum, with adequate spacing between targets
+
+### Step 6: Document the Interaction Spec
+
+For each interaction, document:
+- Trigger (what initiates the interaction)
+- Behaviour (what happens, step by step)
+- States (all states the element passes through)
+- Feedback (what the user perceives at each stage)
+- Accessibility (screen reader announcements, keyboard behaviour, motion reduction)
+
+## Integration
+
+- **Called by:** `writing-design-plans` (as part of plan execution)
+- **Pairs with:** `ui-composition` (visual states), `cognitive-accessibility` (interaction complexity), `accessible-content` (error messages)
+- **Reviewed by:** `designpowers-critique`
+
+## Red Flags
+
+| Flag | Response |
+|------|----------|
+| Component with only default and hover states | Map ALL states including focus, error, loading, disabled |
+| Animation without prefers-reduced-motion support | Add motion reduction. This is not optional |
+| Error state that only changes colour | Add text, icon, and screen reader announcement |
+| Gesture without alternative input method | Add keyboard and/or button alternative |

package/dist/skills/frontend/references/designpowers/vendor/skills/motion-choreography/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: motion-choreography
+description: "Use when designing animation sequences, page transitions, micro-interactions, loading states, or any motion that communicates meaning — ensures motion is purposeful, performant, and safe for motion-sensitive users"
+---
+
+# Motion Choreography
+
+Motion is communication. Every animation answers a question the user didn't know they had. If it doesn't answer one, cut it.
+
+## The Three Questions
+
+Before adding any animation:
+1. **What changed?** — the animation makes it visible
+2. **What should I look at next?** — directs attention
+3. **How are these related?** — shows spatial/hierarchical relationship
+
+Can't answer at least one? The animation is decoration. Cut it.
+
+## Duration Guide
+
+| Context | Duration |
+|---------|----------|
+| Micro-interaction (button, toggle) | 100-200ms |
+| State change (card expand, tab) | 200-300ms |
+| Screen transition | 250-400ms |
+| Complex choreography | 400-700ms total |
+
+Nothing over 1 second unless it's a loading indicator.
+
+## Easing Reference
+
+| Context | Easing |
+|---------|--------|
+| Entering | ease-out (decelerate) |
+| Leaving | ease-in (accelerate) |
+| State change | ease-in-out |
+| Micro-interaction | spring (stiffness 300-500) |
+
+## Stagger Patterns
+
+- 50-80ms delay between items
+- Maximum 5 items staggered, rest appear instantly
+- Follow reading order
+- Reveal hierarchy — important items first
+
+## Reduced Motion
+
+`prefers-reduced-motion: reduce` means reduce, not remove.
+
+| Standard | Reduced alternative |
+|----------|-------------------|
+| Slide in | Fade in |
+| Scale with bounce | Instant appearance |
+| Parallax scroll | Static |
+| Staggered reveal | Simultaneous fade |
+| Continuous pulse | Static state |
+
+**Every animation must have a reduced-motion alternative. No exceptions.**
+
+## What NOT to Animate
+
+- Text colour changes (photosensitive risk)
+- Layout properties in performance paths (use transform)
+- Anything that delays task completion
+- Decorative loops without user control
+
+## Performance
+
+Only animate: `transform`, `opacity`, `filter`. These are GPU-composited.
+
+## What You Deliver
+
+- Animation specs with durations, easings, triggers
+- Reduced-motion alternatives for every animation
+- Performance annotations
+- Sequence diagrams for complex choreography
+
+## Integration
+
+- **Informed by:** `design-lead`, `interaction-design`
+- **Feeds into:** `motion-designer` agent, `accessibility-reviewer`, `design-builder`

package/dist/skills/frontend/references/designpowers/vendor/skills/research-planning/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: research-planning
+description: "Use when user needs are unclear, assumptions need validation, or the design brief identifies gaps in understanding — plans what to learn, which methods to use, and from whom"
+---
+
+# Research Planning
+
+Research is how we replace assumptions with evidence. This skill structures what you need to learn before committing to a design direction.
+
+## When to Use
+
+- The design brief identifies unknowns about users, context, or behaviour
+- The team is making decisions based on assumptions rather than evidence
+- A design is being created for a new audience or unfamiliar context
+- Stakeholders disagree about user needs
+
+## Process
+
+### Step 1: Identify Knowledge Gaps
+
+Review the design brief and list:
+- What do we **know** about the people who will use this? (Evidence-backed)
+- What do we **assume**? (Believed but unverified)
+- What do we **not know**? (Acknowledged gaps)
+
+Present this to the user. Assumptions and unknowns become research questions.
+
+### Step 2: Frame Research Questions
+
+Convert gaps into answerable questions. Good research questions are:
+- **Specific** — "How do users with screen readers navigate multi-step forms?" not "Is the form accessible?"
+- **Observable** — focused on behaviour, not opinion
+- **Actionable** — the answer will change a design decision
+
+Aim for 3-5 research questions. More than that means you need to narrow scope.
+
+### Step 3: Select Methods
+
+Match methods to questions:
+
+| Question Type | Recommended Methods |
+|--------------|-------------------|
+| "What do people currently do?" | Journey mapping, diary studies, contextual inquiry |
+| "Why do people struggle with X?" | Usability testing, think-aloud protocols |
+| "What do people need?" | Interviews, jobs-to-be-done analysis |
+| "Which approach works better?" | A/B testing, preference testing, card sorting |
+| "How does our offering compare?" | Competitive analysis, heuristic evaluation |
+| "Who are we designing for?" | Persona development, ability spectrum mapping |
+
+### Step 4: Plan for Inclusion
+
+Every research plan must address:
+- **Participant diversity** — include people with disabilities, different ages, different technical literacy, different languages
+- **Method accessibility** — ensure research methods themselves are accessible (e.g., interview formats that work for people with communication differences)
+- **Situational contexts** — include scenarios of stress, distraction, low bandwidth, unfamiliar environments
+
+### Step 5: Write the Research Plan
+
+```markdown
+# Research Plan: [Topic]
+
+## Research Questions
+1. [Question]
+2. [Question]
+3. [Question]
+
+## Methods
+| Method | Questions Addressed | Participants | Timeline |
+|--------|-------------------|-------------|----------|
+| [Method] | Q1, Q2 | [Who and how many] | [When] |
+
+## Inclusion Considerations
+[How participant diversity and method accessibility will be ensured]
+
+## Expected Outputs
+[What deliverables this research will produce — personas, journey maps, findings report]
+
+## Decision Points
+[Which design decisions this research will inform]
+```
+
+Save to: `docs/designpowers/research/YYYY-MM-DD-<topic>-plan.md`
+
+### Step 6: User Review
+
+Present the plan. Confirm scope, methods, and timeline are realistic.
+
+## Integration
+
+- **Called by:** `design-discovery`
+- **Calls:** `inclusive-personas` (when persona development is a research output)
+- **Pairs with:** `design-strategy` (research informs strategy)
+
+## What This Skill Does NOT Do
+
+This skill plans research — it does not execute it. Execution happens with real people in the real world. The plan ensures that when research happens, it is structured, inclusive, and actionable.

package/dist/skills/frontend/references/designpowers/vendor/skills/responsive-patterns/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: responsive-patterns
+description: "Use when designing complex responsive layouts — breakpoint strategy, layout shifts, content reflow, responsive typography, container queries, and ensuring the experience works across the full device spectrum"
+---
+
+# Responsive Patterns
+
+Responsive design is not "make it fit on a phone." It is designing for every context — one-handed on a bus, zoomed to 200% on a desktop, on a tablet in sunlight.
+
+## When to Use
+
+- When `ui-composition` defines a layout that spans breakpoints
+- When the design-critic flags responsive issues
+- When building anything more complex than single-column
+
+## Breakpoint Strategy
+
+Content drives breakpoints, not devices. Do not use 768px because "that's tablet." Use the width where your content breaks.
+
+1. Start at 320px
+2. Widen slowly
+3. When the layout looks wrong — that's a breakpoint
+4. Name by behaviour, not device
+
+```css
+--bp-stack: 0;
+--bp-sidebar: 640px;
+--bp-columns: 900px;
+--bp-wide: 1200px;
+```
+
+## Content Priority Shifting
+
+At narrow widths, decide what gets:
+- **Kept** — essential for the task
+- **Collapsed** — behind a toggle
+- **Deferred** — lower in scroll order
+- **Hidden** — removed (last resort)
+
+Document these decisions.
+
+## Responsive Typography
+
+```css
+--font-size-body: clamp(1rem, 0.9rem + 0.5vw, 1.125rem);
+--font-size-h1: clamp(1.75rem, 1.5rem + 1.25vw, 2.5rem);
+```
+
+Body text minimum 16px. Line length 45-75 characters. At 200% zoom, no horizontal scroll (WCAG 1.4.10).
+
+## Container Queries vs Media Queries
+
+| Use case | Use |
+|----------|-----|
+| Page-level layout | `@media` |
+| Component adaptation | `@container` |
+
+## Touch Targets
+
+44x44px minimum at mobile. 8px minimum gap between adjacent targets.
+
+## Testing
+
+Test at: 320px, one pixel below each breakpoint, 200% zoom at 1280px, landscape phone, and real devices.
+
+## What You Deliver
+
+- Breakpoint definitions with rationale
+- Layout behaviour at each breakpoint
+- Content priority decisions
+- Typography scale with clamp() values
+- Touch target verification
+
+## Integration
+
+- **Informed by:** `ui-composition`, `design-discovery`
+- **Feeds into:** `design-builder`, `accessibility-reviewer`