Agent skill

Storybook Check

by rstackjs in rstackjs/storybook-rsbuild

Audit ported storybook-rsbuild source files against the CURRENT upstream Storybook source, grouped by the local package that owns each port, independent of commit history.

MITAuto-check passedFrontend & Design

Install Storybook Check

skills CLI
$ npx skills add rstackjs/storybook-rsbuild --skill storybook-check -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rstackjs/storybook-rsbuild storybook-check --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rstackjs/storybook-rsbuild.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/storybook-check .claude/skills/storybook-check && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
storybook-check
GitHub stars
156
Token cost
~2.5k tokens
SKILL.md length
1,224 words
Files
3 (incl. scripts)
Skills in repo
2
Repo updated
First seen
Licence
MIT

At a glance

Audit ported storybook-rsbuild source files against the CURRENT upstream Storybook source, grouped by the local package that owns each port, independent of commit history.

  • Works in 4 steps: Mapping maintenance (package level first) → Drift audit (one subagent per local… → Disposition → …
  • The user wants to verify nothing was missed in porting
  • SKILL.md covers Why this exists, Ground rules, Files and Workflow, plus 1 more section
  • Runs JavaScript scripts from its folder; calls node, git and gh

What it does

Storybook Check is an agent skill from rstackjs/storybook-rsbuild. Audit ported storybook-rsbuild source files against the CURRENT upstream Storybook source, grouped by the local package that owns each port, independent of commit history. Use this skill whenever the user wants to verify nothing was missed in porting, audit drift against upstream, double-check sync triage, or suspects an upstream fix never landed here. Activate for phrases like "check drift", "audit against upstream", "are we missing anything from storybook", "source-level check", "verify ported files", "did we…

Its SKILL.md is about 2.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files, including scripts (for example `manifest.json`).

It sits in Frontend & Design. It works with Storybook, React and Vue.js. The repository describes itself as: Storybook builder and frameworks powered by Rsbuild. The licence is MIT.

When your agent uses it

  • The user wants to verify nothing was missed in porting
  • Audit drift against upstream
  • Double-check sync triage
  • Suspects an upstream fix never landed here

Example prompts

  • “check drift”
  • “audit against upstream”
  • “are we missing anything from storybook”
  • “/storybook-check”

Requirements

  • Node.js

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Mapping maintenance (package level first)
  2. Drift audit (one subagent per local package)
  3. Disposition
  4. Report

What it can do on your machine

Read from SKILL.md and the folder at commit 88a557d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (JavaScript), which the agent can run.

    Shell commands in SKILL.md call:

    • node
    • git
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Storybook Check loads about 2.5k tokens when it runs. Until then it costs about 179 tokens; SKILL.md has 1,224 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~179
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from rstackjs/storybook-rsbuild at commit 88a557d, republished under its MIT licence (© rstackjs). 1,224 words, ~2,515 tokens.

Download SKILL.mdSave it as .claude/skills/storybook-check/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
storybook-check
description
Audit ported storybook-rsbuild source files against the CURRENT upstream Storybook source, grouped by the local package that owns each port, independent of commit history. Use this skill whenever the user wants to verify nothing was missed in porting, audit drift against upstream, double-check sync triage, or suspects an upstream fix never landed here. Activate for phrases like "check drift", "audit against upstream", "are we missing anything from storybook", "source-level check", "verify ported files", "did we port this", and also right after a storybook-sync report has been consumed — a check run is how its triage gets verified. This complements (does not replace) the storybook-sync skill.
internal
true

Storybook Upstream Drift Checker

Compare the current content of upstream Storybook source against its local storybook-rsbuild counterparts. This is the safety net under the storybook-sync skill.

Why this exists

storybook-sync consumes the upstream commit stream incrementally: each report starts where the previous one ended, and every commit gets a one-shot triage judgment. A wrong judgment is permanent — the commit is never looked at again, and the miss stays invisible until it resurfaces as a user-facing bug.

This skill covers that structural blind spot: every run is a full, stateless sweep over current file contents on both sides. Nothing is skipped because of a previous run, so any drift — including drift a past sync triage judged wrongly — shows up on every run until it is actually resolved.

Ground rules

  1. Full sweep, no memory. Audit every mapping on every run. Skipping "already checked" pairs would reintroduce exactly the failure mode this skill exists to catch: a judgment error that nothing ever revisits.
  2. Verify the mapping before the content. File sets change on both sides — upstream adds, renames, and deletes files, and so does this repo. Repair the manifest first; auditing content through an outdated mapping produces false confidence.
  3. The audit unit is the local package, judged behavior by behavior. The mapping is not cleanly 1:1 in either direction — several upstream files fold into one local file, several upstream packages can feed one local package (framework-react ports from react-webpack5, react-vite, and presets/react-webpack), and some upstream files have no direct counterpart at all. Grouping by what receives the port keeps every behavior that lands in one local package under one pair of eyes, and stops the same file being judged twice by agents that can't see each other's findings.
  4. Intentional divergences live in the manifest, not in your judgment. If you discover a new legitimate divergence, add it to the manifest in the same change — undocumented divergences are indistinguishable from bugs on the next run.
  5. local: null entries still get reviewed. No direct counterpart doesn't mean irrelevant — review the upstream file for semantic parallels per the entry's note.

Files

  • manifest.json — the file-level mapping: upstream path → local path (null plus reviewWith for review-only entries), plus intentionalDivergences (accepted deliberate differences), ignoredUpstreamFiles, and localOnlyFiles. Committed state; keeping it accurate is part of the workflow.
  • scripts/check-upstream.mjs — deterministic git plumbing over the shared blobless cache (~/.cache/storybook-upstream/, same cache as storybook-sync). Plain Node, no dependencies or build step: run it with node. --help lists every mode.

Workflow

1. Mapping maintenance (package level first)
bash
node <skill-dir>/scripts/check-upstream.mjs --coverage

This validates the manifest — first for internal consistency, then against reality on both sides:

  • INVALID-MANIFEST — the entry itself is malformed: a review-only entry with no reviewWith, a duplicate upstream, a reviewWith on an entry that already has a local, or one pointing at a package that isn't there. These block step 2, which partitions on exactly those fields.
  • MISSING-UPSTREAM — a mapped upstream file no longer exists. Track the rename (git -C ~/.cache/storybook-upstream log --follow --format='%H %s' -5 origin/next -- <path>) and fix the entry.
  • UNMAPPED — a new upstream file with no mapping decision. Map it, or add it to ignoredUpstreamFiles. A new mapping needs a local path, or local: null plus a reviewWith naming the local package that reviews it — grouping in step 2 depends on that field.
  • MISSING-LOCAL — a mapped or local-only file was removed from this repo. Fix the entry.
  • UNLISTED-LOCAL — a new local file the manifest doesn't know. Map it or add to localOnlyFiles.

Before descending to individual files, sanity-check the package-level shape: does each upstream package still map to the same local package (per the mapping table in the storybook-sync skill)? A package split, rename, or restructure upstream invalidates file mappings wholesale and must be reflected in the manifest first.

Resolve all coverage findings — commit the manifest fix — before step 2. If coverage is complete, proceed directly.

Show full SKILL.md (586 more words)Show less
2. Drift audit (one subagent per local package)

The partition is computed for you — don't hand-derive it from the manifest:

bash
node <skill-dir>/scripts/check-upstream.mjs --no-fetch --groups

Output is GROUP|UPSTREAM|LOCAL, where GROUP is the local package that owns the port. Spawn one subagent per distinct GROUP, all in one message as parallel foreground Agent calls (no run_in_background), so results arrive together. Keep each group whole: the mappings converge many-to-one on both axes (iframe-webpack.config.ts + base-webpack.config.ts + custom-webpack-preset.ts all land in iframe-rsbuild.config.ts; react-webpack5, react-vite and presets/react-webpack all land in framework-react), so only an agent holding the entire group can tell "this behavior lives in a different file here" from "this behavior is missing".

Each subagent's prompt must carry three things — the exact wording is yours:

  1. Inputs: the group's manifest slice (mappings with their notes) and the accepted intentionalDivergences, stated as not-to-be-reported. How to fetch upstream content (node check-upstream.mjs --no-fetch --show <path>); local files are read directly.
  2. Method: compare across the whole local package, behavior by behavior. The port is adapted (webpack→rspack idioms), not copied, and not structured 1:1 — a behavior may live in a different local file than its upstream declaration, and local: null entries may still have semantic parallels (see their notes). A behavior is present if it exists anywhere appropriate in the local package, and missing only after checking all of it.
  3. Output: a verdict plus, per missing behavior: what upstream does, where the evidence is on each side, the provenance — the upstream commit and PR that introduced the behavior, with upstream's stated reason for the change — and a severity (high = bugfix/correctness, medium = feature/perf, low = polish). Also have it surface divergences that look deliberate but are not yet in the manifest, and notable local-only behaviors. Keep the shape consistent across subagents so results aggregate cleanly.

Tracing provenance. Whether a behavior is worth porting usually turns on why upstream added it — a correctness fix ports, a webpack-only workaround may not — so a finding without its origin story is only half a finding. To trace one: node check-upstream.mjs --no-fetch --log <upstream-path> lists recent commits touching a file, and git -C ~/.cache/storybook-upstream log -S'<distinctive snippet>' --format='%H|%ai|%s' origin/next -- <path> pinpoints the commit that introduced a specific piece of code. Commit subjects don't carry PR numbers (Storybook merges branches rather than squashing), so resolve the PR from the commit: gh api repos/storybookjs/storybook/commits/<sha>/pulls --jq '.[0] | {number, title, body}' — the PR body is upstream's own explanation. The log explains a drift, it never establishes one — content stays the ground truth.

3. Disposition

For each missing finding, exactly one outcome, decided with the user (or per their standing instruction):

  • Port — implement it (separate commit/PR, referencing the upstream PR from the finding's provenance).
  • Intentional — add to the entry's intentionalDivergences with a rationale, in the same change.
  • Defer — record the blocker in the report. Nothing else to do: the full sweep re-surfaces it automatically on the next run.
4. Report

Write upstream-check-report-<YYYYMMDD>.md to the project root and summarize the findings in your response:

markdown
# Storybook Upstream Drift Check

- **Generated**: YYYY-MM-DD
- **Upstream**: storybookjs/storybook@next (`<short-sha of origin/next>`)
- **Packages audited**: N — **Findings**: X missing behaviors (H high, M medium, L low)

## Findings

(per package: table of missing behaviors with severity, evidence on both sides,
upstream PR + upstream's reason for the change, disposition)

## Deferred

(findings left open, with blockers — these re-surface automatically next run)

## Mapping changes

(manifest entries added/updated this run, with reasons)

The report file and the response summary are for the human; the manifest commit is the only persistent state, and it only changes when mappings or intentional divergences change.

Relationship to storybook-sync

  • sync = incremental commit-stream triage; fast, catches things early, but one-shot judgments.
  • check = stateless full-content audit; heavier per run, but immune to triage mistakes by construction.

Run check after consuming a sync report (to verify the triage), and periodically (monthly or per upstream minor release) regardless. The two are independent by design: check results never feed sync's range tracking, and sync reports never scope what check audits.

© rstackjs, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (scripts) in .agents/skills/storybook-check of rstackjs/storybook-rsbuild.

  • SKILL.md
  • manifest.json
  • scripts/check-upstream.mjs

Open the folder on GitHubat commit 88a557d

Compare with similar skills

Storybook Check next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Storybook Check compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Storybook Check this skillrstackjs/storybook-rsbuild156—~2.5kAutomated safety check: PassMIT
Update Component DocsAgnosticUI/agnosticui827—~607Automated safety check: PassApache-2.0
Framework Interopinkline/inkline1.5k—~1.3kAutomated safety check: PassNone
Design Systemrevfactory/harness-1001.3k—~1.8kAutomated safety check: PassApache-2.0
GSAP Core Animationgreensock/gsap-skills16k4 repos~3.7kAutomated safety check: PassMIT
Boneyard0xGF/boneyard7.5k—~2.2kAutomated safety check: NotesMIT

Similar skills

  • Update Component Docs

    AgnosticUI/agnosticui

    Update component documentation when code changes. An agent skill from AgnosticUI/agnosticui.

    827 GitHub stars~607 tokensUpdated yesterday
    Frontend & DesignAuto-check passed
  • Framework Interop

    inkline/inkline

    The seven framework output packages and the boundaries Inkline lives on — exports contracts, peer-dep/version matrix, per-target capability gaps, idiom fidelity, and the styleframe upstream…

    1.5k GitHub stars~1.3k tokensUpdated 28 days ago
    Frontend & DesignAuto-check passed
  • Design System

    revfactory/harness-100

    Full pipeline for systematically building a UI design system.

    1.3k GitHub stars~1.8k tokensUpdated 6 mo ago
    Frontend & DesignAuto-check passed
  • GSAP Core Animation

    greensock/gsap-skills

    Covers the GSAP core API for tweens, easing, staggers, defaults and matchMedia, and when to choose GSAP over CSS animations or other JavaScript animation libraries.

    16k GitHub starsUsed in 4 repos~3.7k tokens
    Frontend & DesignAuto-check passed
  • Boneyard

    0xGF/boneyard

    Use boneyard-js to add, configure, debug, or rebuild skeleton screens.

    7.5k GitHub stars~2.2k tokensUpdated 1 mo ago
    Frontend & DesignAuto-check: notes
  • Kill AI Slop

    yetone/kill-ai-slop

    Find and remove AI slop — the generic, machine-default visual and copy tics of vibe-coded products — from a web project.

    1.3k GitHub stars~1.4k tokensUpdated 24 days ago
    Frontend & DesignAuto-check passed

More from rstackjs/storybook-rsbuild

  • Storybook Sync

    rstackjs/storybook-rsbuild

    Check and analyze upstream Storybook repository changes that may need to be synced to storybook-rsbuild.

    156 GitHub stars~5.2k tokensUpdated 9 days ago
    Auto-check passed

Questions about Storybook Check

What does Storybook Check do?

Audit ported storybook-rsbuild source files against the CURRENT upstream Storybook source, grouped by the local package that owns each port, independent of commit history. Storybook Check is an agent skill from rstackjs/storybook-rsbuild. Audit ported storybook-rsbuild source files against the CURRENT upstream Storybook source, grouped by the local package that owns each port, independent of commit history.

When should I use Storybook Check?

Storybook Check fits situations like: the user wants to verify nothing was missed in porting; audit drift against upstream; double-check sync triage; suspects an upstream fix never landed here.

How do I install Storybook Check in Claude Code?

Run `npx skills add rstackjs/storybook-rsbuild --skill storybook-check -a claude-code`. Or copy the skill folder (.agents/skills/storybook-check in rstackjs/storybook-rsbuild) into .claude/skills/storybook-check in your project. Claude Code loads it when a task matches its description.

How do I install Storybook Check in Codex?

Run `npx skills add rstackjs/storybook-rsbuild --skill storybook-check -a codex`. Or copy the skill folder (.agents/skills/storybook-check in rstackjs/storybook-rsbuild) into .agents/skills/storybook-check in your project. Codex loads it when a task matches its description.

Can I use Storybook Check in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rstackjs/storybook-rsbuild --skill storybook-check -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/storybook-check, .gemini/skills/storybook-check, .github/skills/storybook-check and .opencode/skills/storybook-check in your project.

What does Storybook Check need to run?

Going by SKILL.md and its folder, Storybook Check needs JavaScript for the scripts in its folder and the command-line tools its instructions call (node, git and gh). Our summary lists: Node.js.

Does Storybook Check access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Storybook Check safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Storybook Check use?

Storybook Check is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Storybook Check use?

About 2.5k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Storybook Check?

Skills that share tags, products or a category with Storybook Check: Update Component Docs (AgnosticUI/agnosticui, 827 stars), Framework Interop (inkline/inkline, 1.5k stars), Design System (revfactory/harness-100, 1.3k stars) and GSAP Core Animation (greensock/gsap-skills, 16k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Storybook Check?

rstackjs (a GitHub organization) maintains it in rstackjs/storybook-rsbuild, which has 156 GitHub stars. The repository holds 2 skills in this directory. The repository was last updated on September 30, 2026.

Source: rstackjs/storybook-rsbuild on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.