Use this when you need to document the interaction patterns a product uses (or should use) -- loading behaviors, state transitions, feedback mechanisms, progressive disclosure, and microinteractions. Produces a pattern catalog that designers and engineers reference for consistency.

Related skills: Use /component-spec for individual component documentation. Pair with /design-review to evaluate pattern usage in designs. Use /style-guide for foundational design tokens.

Process

Step 1: Gather inputs

Ask the user to provide:

1. Product or feature area -- what are we cataloging patterns for?
2. Scope -- full product audit or specific flows?
3. Existing patterns -- does the team have documented patterns? What's inconsistent?
4. Design system -- is there a component library these patterns should align with?
5. Platform -- web, mobile, or both? (Interaction patterns differ by platform)

Step 2: Identify patterns in use

Walk through the product or designs and catalog every distinct interaction pattern:

## Interaction Pattern Inventory -- {{product name}}

### Loading patterns

| Pattern | Where used | Implementation | Consistent? |
|---------|-----------|---------------|-------------|
| Spinner (blocking) | (screens) | (duration, placement) | Yes / No |
| Skeleton screen | (screens) | (shape matches content?) | Yes / No |
| Progressive loading | (screens) | (above-fold first, rest lazy) | Yes / No |
| Optimistic update | (actions) | (show success, rollback on failure) | Yes / No |
| Background refresh | (data) | (silent update, no UI disruption) | Yes / No |

### Feedback patterns

| Pattern | Where used | Implementation | Consistent? |
|---------|-----------|---------------|-------------|
| Toast notification | (actions) | (position, duration, dismissible?) | Yes / No |
| Inline validation | (forms) | (on blur, on submit, or real-time?) | Yes / No |
| Success confirmation | (actions) | (animation, text, auto-dismiss?) | Yes / No |
| Error display | (failures) | (inline, banner, modal?) | Yes / No |
| Progress indicator | (multi-step) | (bar, steps, percentage?) | Yes / No |

### Disclosure patterns

| Pattern | Where used | Implementation | Consistent? |
|---------|-----------|---------------|-------------|
| Accordion/expand | (content) | (single or multi-expand?) | Yes / No |
| Tooltip | (help text) | (hover, click, or focus trigger?) | Yes / No |
| Popover | (details) | (trigger, dismissal, mobile behavior?) | Yes / No |
| Modal/dialog | (decisions) | (focus trap, backdrop, escape to close?) | Yes / No |
| Drawer/panel | (secondary content) | (push or overlay? Responsive behavior?) | Yes / No |

### Navigation patterns

| Pattern | Where used | Implementation | Consistent? |
|---------|-----------|---------------|-------------|
| Tab switching | (content) | (keyboard arrows, URL updates?) | Yes / No |
| Pagination | (lists) | (numbered, load more, infinite scroll?) | Yes / No |
| Back/undo | (actions) | (browser back, in-app back, undo?) | Yes / No |
| Search/filter | (collections) | (instant, debounced, submit?) | Yes / No |

Step 3: Specify standard patterns

For each pattern category, define the standard behavior the product should follow:

## Pattern Specification: {{Pattern name}}

**When to use:** (Scenario that calls for this pattern)
**When NOT to use:** (Common misapplication)

### Behavior
- **Trigger:** (What initiates the pattern)
- **Duration:** (How long it lasts -- timing in ms if animated)
- **Transition:** (How it appears/disappears -- fade, slide, instant)
- **Dismissal:** (How the user exits -- click outside, escape, timer, explicit close)

### States
| State | Visual | Behavior |
|-------|--------|----------|
| Entering | (how it appears) | (what happens on entry) |
| Active | (steady state) | (user can interact with...) |
| Exiting | (how it leaves) | (what happens on exit) |

### Accessibility
- **Keyboard:** (how to trigger and dismiss)
- **Screen reader:** (what's announced)
- **Motion:** (respects prefers-reduced-motion?)

### Platform variations
| Platform | Difference |
|----------|-----------|
| Desktop | (default behavior) |
| Mobile | (touch-specific adaptation -- e.g., bottom sheet instead of dropdown) |

Step 4: Identify inconsistencies

## Consistency Report

### Inconsistencies found

| Pattern | Location A | Location B | Difference | Recommendation |
|---------|-----------|-----------|-----------|----------------|
| (pattern) | (screen) | (screen) | (how they differ) | Standardize to (version) |

### Missing patterns
- (Interaction that currently has no defined pattern -- e.g., "no standard for bulk selection")

Step 5: Review

Ask the user:

• Are these the right standard patterns for your product?
• Any patterns I missed or miscategorized?
• Does the team prefer any of the inconsistent implementations over others?
• Should I spec individual components from these patterns using /component-spec?

Output location

Present the pattern library as formatted text in the conversation. For design system documentation, export to Notion, Storybook, or the team's pattern docs.