docs-review
- Repo stars 90,172
- Author updated Live
- Author repo storybook
- Domain
- Documentation
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @storybookjs · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: docs-review
description: Review, improve, rewrite, author, or plan Storybook documentation in /docs. Use this when asked…
category: documentation
runtime: no special runtime
---
# docs-review output preview
## PART A: Task fit
- Use case: 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..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Scope / Use This Skill When / Use a Light Touch When” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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.”.
- **02** When the source has headings, the agent prioritizes “Scope / Use This Skill When / Use a Light Touch When” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/docs`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Scope / Use This Skill When / Use a Light Touch When”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: docs-review
description: Review, improve, rewrite, author, or plan Storybook documentation in /docs. Use this when asked…
category: documentation
source: storybookjs/storybook
---
# docs-review
## When to use
- Review, improve, rewrite, author, or plan Storybook documentation in /docs. Use this when asked to review docs, improv…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Scope / Use This Skill When / Use a Light Touch When” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "docs-review" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Scope / Use This Skill When / Use a Light Touch When
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Documentation Review
Scope
This skill applies to documentation files in /docs and docs-owned snippet files in docs/_snippets/. Do not use this skill for non-docs files (code, configuration, READMEs outside /docs).
Use This Skill When
- Asked to review, improve, rewrite, or author documentation in
/docs. - Asked for advice on page structure, doc type, audience, or content strategy for
/docs. - Asked to fix formatting, style, or compliance issues in
/docs.
Use a Light Touch When
- The request is a trivial grammar or typo fix that does not need full diagnosis.
- The page is already structurally sound and only needs minor editorial cleanup.
Reference Files
This skill uses four reference files under references/. Load them in order and only as needed:
| File | Owns | When to Load |
|---|---|---|
references/docs-principles.md |
North star, quality dimensions, dual-reader requirement | Always — read first |
references/docs-strategy.md |
Modes, doc types, intervention thresholds, page-shape guidance | Always — read second |
references/docs-antipatterns.md |
Diagnosis patterns and corrective moves | When diagnosing a weak or confusing draft |
references/storybook-style.md |
Editorial, MDX components, frontmatter, formatting, validation rules | In maintenance mode, or as the final pass of edit modes |
Ownership Rules
- Strategy references do not own formatting or component rules.
storybook-style.mddoes not own doc-type or intervention logic.- This file (
SKILL.md) owns workflow and handoffs only.
Workflow
Follow this sequence for every request. Steps 1–4 are diagnosis; steps 5–7 are action.
1. Determine the Requested Outcome
Read the user's request and map it to a mode:
| Request Pattern | Mode |
|---|---|
| "Fix links, callouts, formatting" | maintenance |
| "Make this clearer", "improve this page" | improve |
| "This doc is a mess; rewrite it" | rewrite |
| "Draft docs for feature X" | author |
| "What kind of page should this be?" | strategy |
| "Review this doc" (unspecified) | hybrid — see below |
Hybrid behavior: For vague asks like "review this doc":
- If the draft is obviously weak or the ask implies planning → critique-first (lead with diagnosis).
- If the page is decent and the ask implies cleanup → improve-first (lead with edits).
Default: When ambiguous, default to improve, not maintenance.
2. Determine the Primary Doc Type
Read the page and classify it using the doc types in references/docs-strategy.md:
concept— explains what something is and why it matterstask— walks the reader through accomplishing a goalreference— lookup for options, API, or configtroubleshooting— diagnose and fix a problemmigration— move from one version or approach to anotherdecision guide— choose between options
Always select one primary type, even if the page contains secondary elements.
After selecting the primary type, identify any secondary sections — sections with their own heading whose content follows a different doc type's shape. Note these for Step 3. See "Common Secondary Sections" in references/docs-strategy.md for expected combinations.
3. Diagnose the Draft
Evaluate the page against the quality dimensions in references/docs-principles.md, in order:
- Intent clarity
- Audience fit
- Information shape
- Conceptual clarity
- Task usability
- Example quality
- Economy
For secondary sections, evaluate dimensions 3 (Information Shape) and 5 (Task Usability) against the secondary section's own doc type, not the page's primary type. All other dimensions apply page-wide.
If the page shows signs of structural weakness, load references/docs-antipatterns.md and check for common patterns.
4. Choose the Intervention Level
Use the thresholds in references/docs-strategy.md:
- No structural issues, minor style problems →
maintenance - Structure is okay but framing, order, or examples are weak →
improve - Structure is wrong for the page's job →
rewrite - Page does not exist →
author - User wants advice, not edits →
strategy
Hard rule: When the draft is structurally weak, do not stop at sentence-level edits. Reorder, split, replace examples, or rewrite the page shape.
Split/escalation rule: If the dominant job is unclear or the page serves multiple unrelated jobs, switch to strategy mode or recommend a page split before polishing. Well-structured secondary sections (see references/docs-strategy.md) are not a reason to split.
5. Improve or Plan
Execute based on the chosen mode:
maintenance: Apply editorial and compliance fixes. Loadreferences/storybook-style.mdas primary guide.improve: Strengthen framing, order, explanation, and examples. Keep the page's identity. Usereferences/storybook-style.mdfor the final pass.rewrite: Materially replace the page. Preserve sound content; discard or restructure the rest. Usereferences/storybook-style.mdfor the final pass.author: Write the page from scratch using the primary doc type's shape as a guide. Usereferences/storybook-style.mdfor the final pass.strategy: Return a planning artifact containing:- Audience
- Page job
- Primary doc type
- Recommended outline
- Split/merge recommendation (if applicable)
- Preserve list (content worth keeping)
- Do not edit files or run validation.
When editing, you may also improve docs-owned snippet files in docs/_snippets/ if example quality depends on them.
6. Apply Storybook Style
For edit modes (maintenance, improve, rewrite, author):
- Load
references/storybook-style.mdif not already loaded. - Apply voice, tone, heading, link, component, and frontmatter rules.
- This step is always downstream of structural and editorial work — never the first pass.
7. Validate
For edit modes only:
yarn fmt:write
yarn docs:check
Fix any errors reported by yarn docs:check, then run it again to confirm.
Do not run validation in strategy mode or when no files were edited.
Handoffs
- PR creation: Do not create a PR automatically. If the user asks for end-to-end execution including a PR, hand off to the
prskill. - Snippet files: This skill may edit files in
docs/_snippets/when example quality requires it, but does not own snippet creation for non-docs purposes.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review