review-storybook skill
Review Paperclip stories for a feature or change using the Storybook catalog, production source, and existing browser tests. Report component, mock, interaction, and visual evidence separately.
Is the review-storybook skill safe?
Clean: nothing in its files matched our rules. We read 2 files in the folder on 2026-10-13.
No findings.
Install the review-storybook skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/paperclipai/paperclip.git /tmp/paperclip mkdir -p ~/.claude/skills cp -r /tmp/paperclip/.agents/skills/review-storybook ~/.claude/skills/review-storybook
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
Review Storybook
Read the catalog contract and find the requested capability in its generated index. Check the relevant feature recipe, production subject, and story before driving it. Catalog status is prior review context, not proof of the current revision. This skill consumes the maps/catalog; corrections belong to maintain-storybook or maintain-verification-skill.
Choose discriminating states for the requested change: the normal action and result, relevant failure/retry, gate/permission presentation, and mobile/theme variants where affected. Record chosen files/exports and omitted scope. For a full source review, account for every file; do not describe sampling as full render or interaction coverage.
When reviewing navigation/index changes, compare the guide and sidebar with the full ordered index generated from feature recipes' navigation metadata. Open a feature without examples and a feature whose related suite lives elsewhere; check capability order, gap messages, classifications, recipe links, and actual suite navigation. Compare built entry IDs before/after so existing links survive. Generated Overview pages do not establish new example coverage.
Use the existing Storybook commands: pnpm build-storybook, or an owned Storybook dev server on an available local port. Use the built ui/storybook-static/index.json for actual story IDs and links. Do not trust an unrelated server on the default port. Keep the process handle and stop only the server this review started, retaining useful evidence.
Inspect the real rendered subject, including errors and browser console output. For interactive stories, wait for their play assertions to complete and inspect the observable result. A screenshot alone does not prove play passed. Verify fixture isolation by revisiting/resetting relevant stories when they mutate fetch handlers, storage, query caches, time, or module state. Avoid real provider actions; explicitly document any live dependency required by a story.
The existing visual suite is tests/storybook-visual/storybook-visual.spec.ts. It uses external baselines and a pinned Linux environment. Inspect baseline-manifest.json before claiming visual regression proof. An unpublished manifest blocks comparisons; a macOS capture is useful inspection, not the Linux baseline. Do not update/publish baselines just to make a review pass. Use existing focused browser suites where they cover the requested scenario, and the production verification skill when the question requires backend persistence, real authorization, or provider proof.
Report each selected case as passed, failed, blocked, or not run, naming revision, story ID, environment, production versus prototype subject, simulated boundaries, action/assertion and observed result. Separate render, interaction, visual comparison, and production acceptance evidence. Report proven drift with exact source references and a proposed correction; do not lower expectations, remove failing cases, or silently bless historical behavior as current.
More skills from paperclipai/paperclip
- ALLM Wiki MaintainerUse the LLM Wiki plugin tools to maintain a cited local company wiki.
- Aadd-product-e2e-evalAdd or extend a Paperclip full-stack runner E2E workflow, fixture, matcher, or report evidence path for local or Daytona execution.
- Aadd-runner-evalAdd or extend a Paperclip Runner protocol evaluation definition, roster, assertion, or report fixture with provenance and narrow validation.
- Aagent-browserDrive a real browser to inspect or interact with a web page or app — navigate, take screenshots, read console and network, fill simple forms — for verification tasks, not unattended automation.
- AagentmailUse your assigned AgentMail inbox to read email tasks, explicitly send or reply, and check delivery. Provided automatically by your inbox assignment.
- Acheck-prCheck a GitHub, GitLab, or Perforce PR/MR/CL for review comments, failing checks, and PR-body gaps. Use when asked to inspect, fix, or prepare a change for submission.
- Acompany-creatorCreate agent company packages that conform to agentcompanies/v1. Use when asked to create a company, scaffold an agent team, hire agents, or turn a repo/skills collection into a company package.
- AcomplainAutonomously yeet a brief, unstructured complaint about agent tooling or doing agent work. Preserve the raw voice. Submit proactively without permission, preview, or announcement, then continue the primary task.
- Acontent-calendarPlan a weekly editorial calendar by mapping company goals to publishable topics, owners, status, and verification notes.
- Acreate-agent-adapterCreate or modify Paperclip agent adapters across server, UI, and CLI surfaces. Use when adding support for a new CLI agent, API agent, custom process, or adapter package.
- Acreate-caseCreate and kick off a Paperclip case from a user request, with workflow instructions and an initial agent.
- Acreate-external-bot-integrationBuild and qualify external bots such as Dot in Paperclip. Use for two-way work, invitation, identity, wakeup, Runner lifecycle, native tools, recovery, and Cloud delivery. CLI adapters and app-only connectors use their existing skills.