A mature, well-documented megaproject with clear governance and strong community signals, but setup complexity and dependency management overhead bite newcomers.
last scored 2026-06-15
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
21 of 35 checks passed across 6 categories.
Machine Orientation
5 checks passed3 problems found
- lowAgent instructions stay lean
A bloated instructions file burns context and measurably hurts more than it helps.
Fix: Trim AGENTS.md to the load-bearing commands and conventions; link out to the rest.
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowArchitecture doc
An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Fix: Add an ARCHITECTURE.md describing the major components and how they fit.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
3 checks passed3 problems found
- mediumContainer or dev-container
A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
Fix: Add a Dockerfile, a compose file, or a .devcontainer so the environment is declared, not assumed.
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowDev container
A .devcontainer gives an agent a one-command, fully-declared environment.
Fix: Add a .devcontainer so the toolchain is declared, not assumed.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
Code Navigability
0 checks passed2 problems found
- mediumConventional source layout
A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
Fix: Group source under a conventional top-level directory (src/, lib/, app/, …).
- lowTypeScript strict mode on
Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Fix: Turn on `strict` in tsconfig.json.
Verification Surface
4 checks passed3 problems found
- lowTask runner present
A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Fix: Add a Makefile / Taskfile / justfile collecting the common commands.
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- lowBuild command
A documented build command is the discoverable way for an agent to produce artifacts.
Fix: Add a `build` script that produces the distributable.
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Test command defined — A `test` script is the documented, discoverable way to run the suite.
- Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
Agent Safety
6 checks passed2 problems found
- highNo committed .env
A tracked real .env hands secrets to anything — including an agent — that reads the repo.
Fix: Remove the .env from history, gitignore it, and ship a .env.example instead.
- lowAutomated dependency updates
Dependabot / Renovate keeps dependencies patched without a human in the loop.
Fix: Enable Dependabot or Renovate.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- .gitignore covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
- CODEOWNERS present — CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
3 checks passed1 problem found
- lowNo oversized source file
A single file in the hundreds of KB blows past an agent's effective context window.
Fix: Split the largest files along their natural seams.
- Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
- Generated / vendored files marked — A .gitattributes linguist marker tells tools (and agents) what to skip.
How ready the repo is for a human newcomer to understand, set up, and contribute.
74 / 10017 of 25 checks passed across 6 categories.
First Impression
88Clear, professional, and persuasive—tells you exactly what Storybook is and why you'd use it.
The README immediately communicates purpose ('Build bulletproof UI components faster'), target audience (thousands of teams), and provides a demo GIF, live examples via Chromatic, and quick links to docs and web setup (storybook.new). Badges showing build status, codecov, license, community links, and OpenSSF scorecard reinforce maturity. A comprehensive projects table with demo links for 13+ supported frameworks makes breadth visible.
Getting Running
62Prerequisites and core scripts are documented, but setup is heavyweight and version/dependency pinning is indirect.
CONTRIBUTING.md specifies Node.js version via .nvmrc and recommends fnm, with clear copy-paste Shell commands for nvm/fnm/pnpm. Root package.json pins yarn@4.10.3 and tooling (nx, vitest, playwright). However, monorepo setup (yarn workspaces across 8+ package directories) and heap-size overrides for CI tests ('NODE_OPTIONS=--max_old_space_size=4096') suggest non-trivial bootstrapping. No .env.example or setup script that orchestrates the full bootstrap; newcomers must infer sequencing from script names ('start' task uses yarn task wrapper that isn't directly explained upfront).
Finding Your Way
71Large modular structure is coherent but requires upfront navigation effort to understand cross-cutting concerns.
File tree shows clear separation: addons, frameworks, renderers, presets, lib, builders under code/, plus scripts, .github workflows, and agent skills. Package.json workspaces define module boundaries. However, no top-level architecture.md or CODEOWNERS excerpt explaining layer roles (core vs. renderers vs. frameworks vs. addons). CODEOWNERS exists but is not described. Documentation assumes readers will navigate external docs at storybook.js.org rather than in-repo guides; no quick reference for 'where does React support live?' or 'how do addons get loaded?'
Path to Contribute
81Strong, explicit guidance with good-first-issue labels and clear branching for different contribution types.
CONTRIBUTING.md opens with tip on 'good first issue' label (confirmed in GitHub URL), lists 6 contribution types (RFC, docs, examples, framework integration, addons, bug reports) with links to docs, and points to Discord #contributing channel. Code of Conduct is referenced. PR template exists (.github/PULL_REQUEST_TEMPLATE.md). However, dev-setup details are scattered: main CONTRIBUTING.md is truncated in snapshot, so no single place that says 'clone → install → yarn start → run tests → submit PR'. Docs are external (storybook.js.org); in-repo CONTRIBUTING.old.md suggests prior churn but no explanation of why it's deprecated.
Signs of Life
87Actively maintained with strong recent momentum, broad contributor base, and frequent releases.
Last pushed 2026-06-15 (in future context, assume recent). 90k+ stars, 1815 open issues (showing triage not stalled), multiple workflows (Nx, CircleCI, publish, prerelease, agent scanning) indicate continuous integration and deployment. CHANGELOG.md, CHANGELOG.prerelease.md, and version-specific CHANGELOGs (v6, v1-5) show versioning discipline. Multiple Discord/Collective badges and community links (GitHub Discussions) indicate a living ecosystem. Presence of .agents and .claude skill configs suggests AI-augmented development (acknowledged in CONTRIBUTING.md). However, no explicit release schedule or current maintainer roster visible in snapshot (MAINTAINERS.md exists but not shown).
Open Door
81MIT license, CoC, and clear communication channels; no legal friction but some social barriers for newcomers.
MIT License confirmed in README badge and LICENSE file exists. CODE_OF_CONDUCT.md is present. Discord server (discord.gg/storybook), GitHub Discussions, and multiple community badges (Open Collective, Twitter) provide multiple entry points. CONTRIBUTING.md explicitly welcomes all skill levels and types. However, the note on AI contributions ('never let an LLM speak for you', AI-generated PRs auto-closed after 3 days) sets a defensive tone that may deter first-time users unsure of authorship attribution. No explicit 'help needed' section or mentorship program visible; size and complexity may make newcomers hesitant to ask basic questions in a 90k-star project.
First Impression
3 checks passed0 problems found
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
- Topics set — Topics situate the project's domain at a glance and help a newcomer find it.
Getting Running
3 checks passed3 problems found
- mediumOne-command environment
A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
Fix: Add a Dockerfile, a compose file, or a .devcontainer for a one-command setup.
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowOne-click dev container
A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
Fix: Add a .devcontainer for a one-click, batteries-included environment.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Prerequisite versions pinned — Unpinned prerequisites are the classic 'works on my machine' first-run failure.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
0 checks passed3 problems found
- mediumConventional source layout
A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
Fix: Group source under a conventional top-level directory (src/, lib/, app/, …).
- mediumArchitecture / overview doc
An overview hands a newcomer the map instead of making them reconstruct it.
Fix: Add an ARCHITECTURE.md (or a 'Project layout' README section) naming the key directories.
- lowNo oversized source file
A single thousand-line file is a wall a newcomer bounces off.
Fix: Split the largest files along their natural seams.
Path to Contribute
5 checks passed1 problem found
- lowTask runner
A Makefile / Taskfile gives a contributor a single index of the project's commands.
Fix: Add a Makefile / Taskfile collecting the common dev commands.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
- Issue templates — Issue templates show a newcomer how to file something useful — and that contributions are welcome.
- Pull-request template — A PR template tells a first-time contributor what a good change includes.
- Test command defined — A documented test command lets a contributor check their change before opening a PR.
- Lint command — A linter lets a first-time contributor catch style issues before review.
Signs of Life
2 checks passed1 problem found
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
Open Door
4 checks passed0 problems found
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- License is a standard one — A non-standard or custom license is a legal question mark a newcomer won't resolve.
- Code of conduct — A code of conduct states the social ground rules that make it safe to step in.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- highPath To Contribute+18 pts if fixed
CONTRIBUTING.md is truncated; complete dev workflow not visible to newcomers
The snapshot cuts off CONTRIBUTING.md after the Prerequisites section. Full build, test, lint, and PR submission instructions are not shown. Newcomers cannot see the complete path from 'I want to fix a bug' to 'my PR is merged' without leaving the repo.
Fix: Ensure CONTRIBUTING.md in the repo (not snapshot) is comprehensive and includes: (1) Prerequisites (already shown), (2) Installation, (3) Development workflow (how to run tests, linter, type-checker; which npm scripts do what), (4) Building (if needed), (5) Testing expectations (coverage thresholds, test framework choice), (6) Submission (PR etiquette, review process, how to respond to feedback), (7) Troubleshooting common setup issues. Verify the full file is at least 3000 words and covers all seven sections.
- highGetting Running+15 pts if fixed
No single source of truth for dev setup and testing workflow
CONTRIBUTING.md is truncated in the snapshot, but the visible portion lacks a complete step-by-step dev setup (clone → install → verify → run tests → build → run Storybook locally). Root package.json has a 'start' script that invokes 'yarn task', but 'task' requires a template parameter and isn't self-documenting. NODE_OPTIONS heap overrides appear in test scripts without explanation. Newcomers will waste time hunting for 'how do I run the Storybook dev server?' or 'what's the test command for my new addon?'
Fix: Create a top-level SETUP.md or expand CONTRIBUTING.md (in snapshot) with a complete quick-start that includes: (1) fnm/nvm install, (2) node --version && yarn --version checks, (3) git clone + cd, (4) yarn install, (5) yarn start (with explanation of template/task system), (6) open http://localhost:6006, (7) yarn test, (8) yarn lint. Add a brief note explaining NODE_OPTIONS and why it's needed.
- mediumFinding Your Way+12 pts if fixed
Monorepo architecture not explained in-repo; navigation requires external docs
The monorepo spans 9+ package directories (addons, frameworks, renderers, presets, builders, lib, core, scripts) with yarn workspaces, but no architecture.md or top-level index explains module responsibility, dependency flow, or how a feature flows from core → renderer → addon. CODEOWNERS exists but is not summarized. Newcomers will struggle to answer 'where does the React renderer live?' or 'how do I add a new addon?' without consulting external storybook.js.org docs.
Fix: Add ARCHITECTURE.md at the repo root with: (1) ASCII diagram of module boundaries (e.g., core depends on builders, renderers depend on core, addons are independent), (2) one-paragraph role for each top-level package directory, (3) pointers to CODEOWNERS for ownership, (4) example: 'to add a framework: see code/frameworks/[name]/', (5) 'to add an addon: see code/addons/[name]/'. Link from CONTRIBUTING.md.
- mediumGetting Running+10 pts if fixed
Indirect version pinning and dependency management in resolutions; no lockfile info
package.json uses 'resolutions' to pin @babel, @types, @testing-library, @playwright, esbuild, playwright, react, and typescript versions. Yarn 4.10.3 is pinned in packageManager, but there's no yarn.lock visible in snapshot, and .yarnrc.yml config is not shown. Newcomers won't know: (1) why resolutions override package-level semver, (2) how patches in .yarn/patches/ work, (3) whether yarn install will succeed or require cache busting. The complexity obscures 'just run yarn install' as safe and deterministic.
Fix: Add a DEPENDENCIES.md or section in SETUP.md that explains: (1) why resolutions are used (to fix transitive dep conflicts/vulnerabilities), (2) what .yarn/patches/ does (temporary monkey-patches until upstreams release fixes), (3) that yarn 4 uses .yarnrc.yml and .yarn/releases/yarn-4.10.3.cjs for reproducibility, (4) that yarn install is the single source of truth. Link from CONTRIBUTING.md. Ensure .yarnrc.yml is shown in snapshot summary.
- mediumGetting Running+8 pts if fixed
No beginner-friendly entry point for 'how do I run Storybook on my own UI'
README points to storybook.new and docs at storybook.js.org, but repo itself has no 'quick demo' or worked example of cloning Storybook, running its own dev server, and seeing its component library live. The 'start' script requires knowledge of templates ('react-vite/default-ts'). A newcomer who clones the repo expecting to 'just see Storybook running' will hit a wall.
Fix: Add a 'Local Development' section to SETUP.md: 'To see Storybook's own component library: yarn start (uses React + Vite by default). Open http://localhost:6006 and interact with addons, core UI, and example components.' Alternatively, provide a shell script ./scripts/quick-start.sh that wraps yarn start with sensible defaults and prints the URL.
- lowPath To Contribute+7 pts if fixed
No explicit mentorship or onboarding path for first-time contributors
While CONTRIBUTING.md points to 'good first issue' label and lists contribution types, there is no explicit 'first-time contributor onboarding' section, no list of 'issues reserved for newcomers', no mentor/buddy assignment process, and no FAQ addressing 'I've never contributed to OSS before—where do I start?'. A newcomer will see 1815 open issues and 90k stars and feel overwhelmed without a clear entry ramp.
Fix: Add a 'First-Time Contributors' section to CONTRIBUTING.md that includes: (1) start with a 'good first issue' by filtering GitHub issues with label 'good first issue', (2) open a draft PR early (before finishing) to get feedback, (3) ask questions in the PR or on Discord #contributing—maintainers are friendly, (4) link to a curated list of 5-10 'starter issues' (e.g., 'fix typo in docs', 'add a test for edge case X', 'improve error message Y'), (5) point to a Discord #newcomers-welcome channel if one exists. Encourage draft PRs and early feedback.
- lowSigns Of Life+6 pts if fixed
No visible release schedule or maintenance roadmap
While signs of life are strong (recent commits, active issues, multiple CHANGELOGs), there is no visible release schedule, roadmap, or guidance on which versions are actively supported. CONTRIBUTING.md does not state 'we release on the 15th of each month' or 'security patches are backported to the last 3 versions'. Newcomers cannot predict when their fix will ship or understand the project's long-term direction.
Fix: Create ROADMAP.md or add a Roadmap section to README.md that includes: (1) current stable version and next planned version, (2) release cadence (e.g., 'minor release every 2 weeks, major release every 6 months'), (3) support policy (e.g., 'latest 2 majors are actively supported'), (4) link to GitHub Projects or Milestones for upcoming features, (5) quarterly or annual vision statement (1-2 paragraphs on strategic direction). Keep it updated quarterly.
- lowOpen Door+5 pts if fixed
AI contribution policy is defensive and may discourage newcomers
CONTRIBUTING.md states 'Pull requests or issues entirely generated by AI with no human involvement... will be labeled... and closed automatically after 3 days' and 'AI-generated comments... can be subject to a ban'. This is correct governance, but the framing ('never let an LLM speak for you') may make newcomers unsure whether they can use GitHub Copilot while editing code or Claude to help debug, leading to anxiety and hesitation to contribute.
Fix: Rephrase the AI contribution policy in CONTRIBUTING.md to be welcoming and clear: 'We welcome the use of AI tools (Copilot, Claude, etc.) as personal assistants during development. However, you—a real person—must be the author and maintainer of every issue and pull request. AI-generated PRs submitted by automation bots with no human review or involvement will be closed. If you use AI to help draft code or comments, please disclose the tool (e.g., "with help from Claude") in the PR description or comment.' This clarifies that tool use is fine, but human authorship and accountability are required.
Show your score
[](https://latch.fyi/storybookjs/storybook)Share this analysis
https://latch.fyi/storybookjs/storybookFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.