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.
Label GitHub issues and PRs found during QA testing. Use when organizing QA findings with proper labels.
Review the instructions the agent will receive before you install.
When creating or organizing issues/PRs found during QA testing, apply these labels.
Add upgrade:<version> label to track all QA findings for a release:
# Create label if it doesn't exist
gh label create "upgrade:10.2" --repo storybookjs/storybook --color "0E8A16" --description "Issues/PRs found during 10.2 upgrade QA"
# Add to issue/PR
gh issue edit <NUMBER> --repo storybookjs/storybook --add-label "upgrade:10.2"
gh pr edit <NUMBER> --repo storybookjs/storybook --add-label "upgrade:10.2"
Add sev:S1 through sev:S4 to bugs only (not docs or feature requests):
gh issue edit <NUMBER> --repo storybookjs/storybook --add-label "sev:S2"
Severity levels:
| Type | Severity label? |
|---|---|
| Bug (runtime error) | Yes |
| Bug (type error) | Yes |
| Bug (automigrate issue) | Yes |
| Documentation issue | No |
| Feature request | No |
| Enhancement | No |
Label multiple issues at once:
gh issue edit 33524 --repo storybookjs/storybook --add-label "upgrade:10.2" && \
gh issue edit 33527 --repo storybookjs/storybook --add-label "upgrade:10.2" && \
gh pr edit 33526 --repo storybookjs/storybook --add-label "upgrade:10.2"
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.
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.
Add Storybook to a project that does not have it configured, choosing the installation tag based on the latest stable version. Then use the separate setup skill to configure Storybook for the project.