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.
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
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 .bodyUse 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/storybookWhen 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> upgradegh CLI authenticated for storybookjs/storybookpublish-canary.ymlWorkflow page:
CLI:
gh run list --repo storybookjs/storybook --workflow publish-canary.ymlstorybookjs/storybook
bc26c29
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.