mcpField
S
storybook-stories

storybook-stories

github.com/pedronauckDevelopment644306 installsUpdated 1w ago
Repository

About storybook-stories

A skill for adding Storybook stories that follow the conventions of the owning project layer. It emphasizes realistic, accessible examples, reuse of shared providers, and checks through the relevant Storybook build or visual review.

Key features

  1. 01Extend the nearest existing story
  2. 02Reuse shared decorators and providers
  3. 03Use typed CSF metadata and StoryObj
  4. 04Choose focused, interactive states
  5. 05Follow autodocs and validation conventions

Use cases

  1. 01Adding stories for a component change
  2. 02Demonstrating meaningful component states
  3. 03Checking a story with the owning Storybook

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/pedronauck/skills --skill storybook-stories

After installing, type/storybook-storiesin Claude Code to confirm it loaded.

Bundled filesreferences/patterns.md

Details

From the project README

Storybook Stories

Extend the nearest existing story using the Storybook instance and naming conventions for its layer. Locate the owning Storybook configuration for primitives versus app/domain stories. Reuse global QueryClient/router/MSW decorators instead of duplicating providers.

  • Inspect the shared primitive inventory before composing examples. Use its public exports; domain components remain local. Follow the repository's token source, design documentation, and surface instructions.
  • Use typed CSF metadata and StoryObj<typeof meta>. Choose layout/decorators for the component's real surface; centered layout is useful for some controls, not full routes.
  • Show the smallest set of supported states that explains meaningful behavior. No minimum or maximum story count, exhaustive prop matrix, or per-export JSDoc requirement.
  • Use args for controlled props and render for compound composition. A render-only story does not need empty args. Add descriptions when they explain behavior, constraints, or usage that the canvas cannot show.
  • Keep examples interactive, accessible, and realistic. Use the actual component API, not assumed variants copied from a template.
  • Follow the project's existing autodocs policy. Enable or omit tags: ["autodocs"] consistently with that owner; avoid duplicate pages.
  • Run the owning Storybook/build or visual check for the changed behavior. Reuse existing evidence; stories do not automatically require new unit or end-to-end suites.

Read references/patterns.md only for the story composition pattern being used. Examples are adaptable, not a required scaffold.

Comments

Markdown supported