Rebuild modified packages in the Storybook monorepo and restart its internal UI after code changes. The workflow provides the running URL and can optionally create a UI review of stories related to the changes.
Rebuild and restart the internal Storybook UI after changes to internal Storybook code (core, addons, frameworks, renderers, libs, etc.), then optionally display a UI review. Use after editing any package in the Storybook monorepo's code/ directory, or when the user asks to rebuild and/or restart Storybook.
Review the instructions the agent will receive before you install.
After making changes to internal Storybook code (core, addons or otherwise), follow this workflow.
Unless the user explicitly ran /rebuild-restart-storybook, ask the user whether they want to rebuild and restart Storybook. If they decline, stop here.
Build a space-separated list of the monorepo packages that were modified in the conversation. For each modified package, find its Nx project name in the project.json file in that package's directory (the name field), not the package.json name.
For example, if code/addons/review and code/addons/vitest were modified, the list is addon-review addon-vitest.
Run these in the code directory, in order. Substitute <extra packages> with the list from Step 2.
rm -rf node_modules/.cache
yarn
yarn build storybook <extra packages>
Then, run in the background:
NODE_OPTIONS="--preserve-symlinks" yarn storybook:ui --no-open
A Storybook may already be running. If the port is occupied, cancel the start, kill the old process to free the port, then start Storybook again.
Once Storybook has started, give the user the URL. Then ask whether they want to display a review.
If the user wants a review, use Storybook's review-create MCP tool to create a UI review of relevant stories. Pick a set of stories related to the entirety of the conversation so far.
If there are no relevant stories because no UI elements were touched, ask the user what they would like to see a review for.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Find a trial Storybook package for a specific branch, or trigger its publication when needed. Check release progress and obtain the package reference or commands for creating or upgrading a project with that build.
Look up a project's existing UI components in Storybook, including their props, or configuration inputs, and usage examples. Use the findings to answer questions and identify components to reuse before building duplicates.
Review, improve, rewrite, or draft Storybook documentation in /docs. Assess each page’s purpose, audience, structure, and examples, then make suitable edits or provide a content plan, with formatting checks after changes.
Check out a GitHub pull request, fix linting and TypeScript errors, and commit and push the changes. The workflow supports forked pull requests and repeats type checks to verify fixes while keeping changes focused on these errors.
Organize GitHub issues and pull requests found during quality assurance testing. Apply release tracking labels, classify bugs by four severity levels, and label multiple findings while keeping documentation issues and feature requests outside the severity scheme.
Work through unresolved GitHub pull request reviews one at a time. The skill explains each comment, proposes a fix, asks how to proceed, and handles chosen edits, replies, commits, and thread resolution.