Review, improve, rewrite, author, or plan Storybook documentation in /docs. Use this when asked to review docs, improve a page, rewrite documentation, draft new docs, or advise on docs strategy.
日本語の概要は準備中です。原文の説明を表示しています。
Finds or publishes a pkg.pr.new canary release for a Storybook branch. Use when the user wants the canary package specifier for a branch or needs to trigger the canary workflow manually.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Use this skill to get a branch-specific canary build from pkg.pr.new.
Canary publishes are driven by the publish-canary.yml workflow.
Automatic canary publishes:
nextci:canary (a human must apply that label). While it remains, every push to the PR republishes. The label does nothing on fork PRs.The canary version string is constructed like this:
storybook@https://pkg.pr.new/storybook@<SHA>
Replace <SHA> with the short commit SHA (first 7 characters). Compact URLs (https://pkg.pr.new/storybook@<SHA>) resolve to the same tarball as the owner/repo form. The pkg.pr.new dashboard is always https://pkg.pr.new/~/storybookjs/storybook.
SHA=$(git rev-parse --short=7 HEAD)
curl -I "https://pkg.pr.new/storybook@$SHA"
An HTTP 200 status code means the canary already exists for that commit.
Use this skill with the following if-then behavior.
ci:canary labelDo not trigger anything manually. Read the canary heading and install commands from the PR body. That section is the current run status and the most recent release.
BRANCH=$(git branch --show-current)
gh pr list \
--repo storybookjs/storybook \
--head "$BRANCH" \
--state open \
--json number,title,labels,url \
--jq '.[] | select(any(.labels[]?; .name == "ci:canary"))'
gh pr view <NUMBER> --repo storybookjs/storybook --json body --jq .body
Use the heading and the CANARY_RELEASE_SECTION commands as-is. A follow-up workflow (publish-canary-pr-body.yml) writes those sections after publish finishes, including after a maintainer manual run.
Fork PRs never use path A. Use path C.
ci:canary labelTrigger the canary workflow manually on the branch and watch it finish. It usually takes 5-10 minutes. You can also use the GitHub Actions UI: open publish-canary.yml, click "Run workflow", and select the branch. Optional inputs pr, branch, and sha must agree when more than one is set.
BRANCH=$(git branch --show-current)
gh workflow run --repo storybookjs/storybook publish-canary.yml --ref "$BRANCH"
Find the new workflow run and watch it:
BRANCH=$(git branch --show-current)
RUN_ID=$(gh run list \
--repo storybookjs/storybook \
--workflow publish-canary.yml \
--branch "$BRANCH" \
--event workflow_dispatch \
--json databaseId \
--jq '.[0].databaseId')
gh run watch "$RUN_ID" --repo storybookjs/storybook
When it finishes successfully, read the canary heading from the PR body if a PR was updated. Otherwise construct the version string from the published SHA (the run's headSha is the workflow-source branch, which may differ when you passed pr or sha):
RUN_SHA=$(gh run view "$RUN_ID" --repo storybookjs/storybook --json jobs --jq '[.jobs[].steps[]?.name | select(startswith("canary-ref "))][0]' | sed -n 's/.*sha=\([0-9a-fA-F]\{7,40\}\).*/\1/p')
SHORT_SHA="${RUN_SHA:0:7}"
echo "storybook@https://pkg.pr.new/storybook@$SHORT_SHA"
Do not add ci:canary. Dispatch the workflow from this repository with the PR number. The fork author does not need to do anything.
gh workflow run --repo storybookjs/storybook publish-canary.yml --ref next -f pr=<PR_NUMBER>
If you also pass branch or sha, they must be that PR's current head. A later push on the fork does not republish until you run the workflow again.
Optionally confirm the package is live:
curl -I "https://pkg.pr.new/storybook@$SHORT_SHA"
For a new project:
npx --yes --allow-remote=all https://pkg.pr.new/create-storybook@<SHA>
For an existing project:
npx --yes --allow-remote=all https://pkg.pr.new/storybook@<SHA> upgrade
gh CLI authenticated for storybookjs/storybookpublish-canary.ymlWorkflow page:
CLI:
gh run list --repo storybookjs/storybook --workflow publish-canary.yml
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Review, improve, rewrite, author, or plan Storybook documentation in /docs. Use this when asked to review docs, improve a page, rewrite documentation, draft new docs, or advise on docs strategy.
日本語の概要は準備中です。原文の説明を表示しています。
Checks out a PR (including fork PRs), fixes all linting and TypeScript errors, then pushes the changes back. Use when asked to fix lint, types, or TS errors on a PR.
日本語の概要は準備中です。原文の説明を表示しています。
Label GitHub issues and PRs found during QA testing. Use when organizing QA findings with proper labels.
日本語の概要は準備中です。原文の説明を表示しています。
Triage and resolve GitHub PR review comments one by one, interactively. Use when the user asks to handle, address, respond to, or resolve PR review comments, or mentions reviewer feedback on a pull request.
日本語の概要は準備中です。原文の説明を表示しています。
Use when adding Storybook to a project that does not have Storybook configured yet.
日本語の概要は準備中です。原文の説明を表示しています。
Write the changelog entry for a new minor or major Storybook release. Use when preparing a CHANGELOG.md entry for a X.Y.0 version.
日本語の概要は準備中です。原文の説明を表示しています。