Overview
eq-storybook-test works alongside /eq-execute after TDD to decide whether a component needs a Storybook story, and if so, what belongs in play() vs .test.tsx. Prevents over-duplication (same interaction tested in both places) and under-testing (story exists but has no assertions).
When to Use
Use alongside /eq-execute when implementing any component that has:
- User interactions (forms, accordions, modals, carousels, tabs)
- Multiple visual states needing a11y coverage
- Conditional rendering logic
- Lives in
packages/ui/src/(design system components always get stories)
Decision Rules
| Signal | Story required? |
|---|---|
Component is in packages/ui/src/ (design system) | Always: document all variants |
| Component has interactions worth showing as living docs | Yes: play() documents intent, .test.tsx covers edge cases |
| Component has multiple visual states (loading, error, empty, success) | Yes: each state = one story export |
.test.tsx covers interactions with no visual/doc value | Skip story: tests sufficient |
| Simple stateless layout wrapper | Skip story: no a11y value, no doc value |
Testing Boundary
| Concern | .test.tsx | play() in story |
|---|---|---|
| Component logic, edge cases, error branches | Here | Not here |
| Interaction documentation (living spec) | No | Here |
| A11y gate on every story state | No | Free via addon-a11y |
| Form submission, toggle, accordion flows | Either | Prefer here: doubles as docs |
Usage Examples
/eq-storybook-test src/components/ToolBrowser.tsxChecks the existing .test.tsx, applies decision rules, and generates stories only where they add value: with play() functions for interaction documentation and free a11y coverage.
Configuration
Requires Storybook 10+ with storybook/test imports (not @storybook/test).
Installation
npx skills add mclaude95/eq-foundry -s eq-storybook-test