# Maintain Storybook

Keeps stories and the catalog aligned with production UI and the feature map.

- Repository: https://github.com/paperclipai/paperclip (109885 stars)
- Category: Design
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add paperclipai/paperclip --skill maintain-storybook -g -a claude-code -y`
Codex: `npx skills add paperclipai/paperclip --skill maintain-storybook -g -a codex -y`
Cursor: `npx skills add paperclipai/paperclip --skill maintain-storybook -g -a cursor -y`
Gemini CLI: `npx skills add paperclipai/paperclip --skill maintain-storybook -g -a gemini-cli -y`

## Description

Keep Paperclip stories and their downstream catalog aligned with the feature map and production UI. Use to reconcile story drift, classify prototypes, update fixtures, or maintain feature coverage.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Maintain Storybook

Read the [Storybook catalog contract](../../../maps/storybook-map/README.md),
the relevant [feature recipes](../../../maps/feature-map/README.md), and
[DESIGN.md](../../../DESIGN.md). The feature map is an upstream input. This skill
owns stories, their fixtures/support, and `maps/storybook-map/`; it does not edit
the feature or agent-access maps. Report upstream drift to
`maintain-verification-skill` with source evidence.

## Reconcile the requested scope

For a feature/change, follow its capability IDs to catalog entries and shared
dependencies. For a full inventory, account for every configured story file,
including historical examples. Start with `node scripts/storybook-catalog.mjs`.
Record the source revision and whether the pass covers source, rendering,
interactions, or visual comparisons. Inventory completeness is not behavioral
coverage. Do not expand a targeted maintenance request into an all-product audit.

Compare each affected story's rendered subject, props, fixture responses, actions,
and assertions with the production implementation and recipe. Follow imported
wrappers: a production Button inside a locally recreated page does not make that
page a production-component story. A real production page using mocked APIs is
valid isolation; record component provenance and data simulation separately.
Inspect mock methods/paths, payload shapes, errors, identity, gates, and reset
behavior. An API method returning success without the relevant state transition
can hide drift. Do not replace errors with generic successful mocks to pass.

Prefer mounting the shipped subject and mocking its external boundary. Retain
local layout wrappers and fixture data when they serve that isolation. Replace a
duplicate product implementation only when the current component expresses the
same scenario without losing the original purpose. Production bugs and larger
redesigns are separate findings, not reasons to rewrite expected behavior.

The rest: https://github.com/paperclipai/paperclip/blob/HEAD/.agents/skills/maintain-storybook/SKILL.md