Review Storybook's minimum supported browser versions using Plausible documentation traffic data. The skill presents usage evidence and proposed versions for approval, then updates pinned settings and documentation and opens a pull request with the recorded decision.
Recomputes Storybook browser support floors from Plausible /docs usage, writes pinned versions, and opens a PR. Use only when a human explicitly applies this skill.
This skill reviews Storybook’s minimum supported browser versions using documentation traffic collected in Plausible. It organizes usage shares by version for the last 30 days and presents proposed minimum versions with the evidence behind their selection. After approval, it updates support settings, public documentation, and migration guidance, then creates a pull request containing the evidence and approval record.
Use it for maintenance work that revisits browser support based on actual documentation readership. It uses a visitor share of at least 0.5% to consider versions. A person reviews the reasoning and decides whether isolated usage of older versions belongs in the supported range.
Use this skill only when a person explicitly applies it. It requires PLAUSIBLE_API_KEY. Explicit approval of the versions to include is required before changing minimum versions. Node settings remain unchanged. It updates caniuse-lite if needed and follows the repository’s seven-day restriction on newly published npm packages. The PR targets next.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 21, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Need PLAUSIBLE_API_KEY in the environment. How the operator supplies the key is up to them. Do not print the key.
POST https://plausible.io/api/v2/query
site_id: storybook.js.orgdate_range: "30d"filters: [["contains", "event:page", ["/docs"]]]dimensions: ["visit:browser", "visit:browser_version"]metrics: ["visitors", "percentage"]include: { "total_rows": true }Save the request, resolved date range, retrieval time, and complete response. Fetch all pages before rolling versions. Use the same fixed date range for every request in the run.
Plausible's Stats API reference defines percentage as the percentage of total visitors in each category. With the query above, the denominator is all unique visitors matching the /docs page filter during the selected period, across all browsers and versions. It is not the total for one browser or the sum of the returned version rows. In each result row, metrics[0] is visitors and metrics[1] is percentage. Use metrics[1] as the share for an unrolled category. The 0.5% cutoff means percentage >= 0.5, not 0.005.
Also query metrics: ["visitors"] with no dimensions and the same site, date range, and page filter to record the denominator. Do not add browser filters to this denominator query.
/docs visitors × 100. For a rolled version containing multiple raw versions, query metrics: ["visitors"] with no dimensions, the same site/date/page filter, and additional is filters for that browser and its matching raw versions. Divide this unique-visitor count by the recorded denominator and multiply by 100 to get the rolled share. Do not sum unique-visitor counts or percentages across raw versions; a visitor can appear in more than one row.Companions: android / and_chr = Chrome floor. ios_saf = Safari floor. Leave Node unchanged.
The heuristic does not define a numerical boundary between the current cluster and an older island. Do not infer that boundary silently or write new floors without explicit operator approval.
Present the saved query evidence and a table for each browser containing:
/docs visitors.Record the operator's approval, identity, date, and selected versions with the evidence in the PR. The floor is the oldest qualifying version in that approved cluster. If the operator disputes the boundary or the evidence cannot distinguish clusters, stop and ask the Technical Architect to resolve the selection semantics. Do not change the policy to break a tie. Reuse of the saved evidence and approval must yield the same floors.
Pin explicit versions (do not leave a live query):
code/core/src/shared/constants/environments-support.ts — BROWSER_TARGETS (chromeN, edgeN, firefoxN, safariN.N, iosN.N; Opera only if kept)code/package.json — browserslistdocs/get-started/install.mdx — public list and older-browser fallback guidance, scoped to the same Storybook versions as MIGRATION.md; preserve the preview-only limitationsMIGRATION.md — next major From version X.x to Y.0.0 section. Create that section at the top if it does not exist.If browserslist cannot resolve the new pins, bump caniuse-lite (root resolutions + lockfile). The repo has a 7-day npm age gate.
Branch from origin/next. Open a PR that targets next and follows .github/PULL_REQUEST_TEMPLATE.md. Add labels ci:normal, qa:skip, and BREAKING CHANGE.
In What I did, keep it short: before → after versions, and the share of /docs visitors for each chosen floor.
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.