Storybook 仓库内部开发流程rebuild-restart-storybook 技能——重建并重启内部 Storybook 的标准化工作流【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook本文围绕 Storybook 开源仓库中的 Agent 技能定义文件 SKILL.md实体内容位于 .agents/skills/rebuild-restart-storybook/SKILL.md完整解析这套改动内部 Storybook 代码后如何重建、重启并审查 UI的五步工作流。读完后你将掌握如何确定被修改的 monorepo 包及其 Nx 项目名、如何在code/目录执行缓存清理、按需构建与后台启动内部 Storybook、如何处理端口占用以及如何借助 MCP 的review-create工具为本次改动生成 UI 审查。技能定位与触发条件rebuild-restart-storybook是 Storybook 仓库为 AI 编码代理Claude Code / Codex 等定义的标准化操作技能。SKILL.md 的 frontmatter 声明了它的元信息name: rebuild-restart-storybook技能标识名description用于在修改了内部 Storybook 代码core、addons、frameworks、renderers、libs 等之后重建并重启内部 Storybook UI并可选地展示一次 UI 审查review。触发时机是编辑了code/目录下的任意包之后或用户主动要求重建/重启 Storybook 时allowed-tools: Bash, Read技能执行时仅允许使用 Bash 与 Read 工具即整个流程只涉及读代码 跑命令不需要额外的写文件能力。需要说明的是.claude/skills/rebuild-restart-storybook/SKILL.md 本身只是一个指向.agents/skills/rebuild-restart-storybook/SKILL.md的引用文件内容为路径指针真正的技能正文以.agents/下的文件为准。这也体现了该仓库的约定技能定义统一维护在.agents/skills/下.claude/skills/侧做引用分发。第一步与用户确认是否重建交互护栏技能的第一步是一道交互确认除非用户是显式执行/rebuild-restart-storybook命令触发的代理都必须先询问用户是否要重建并重启 Storybook如果用户拒绝流程到此终止。这一步的设计意图在于重建 重启是一个重量级操作涉及清理缓存、重新构建多个包、拉起 dev server在代理顺带修改了代码之后不应未经确认就自动执行。它把是否重建的决策权交还给人类同时保留了用户显式斜杠命令时的免确认路径。第二步确定被修改的包并找到 Nx 项目名流程要求构建一个以空格分隔的 monorepo 包名列表列出本次会话中被修改过的所有包。关键规则是每个包必须使用其目录内project.json文件里的name字段即 Nx 项目名而不是package.json里的name字段即 npm 包名。技能给出的示例是如果修改了code/addons/review和code/addons/vitest得到的列表就是addon-review addon-vitest。这个规则可以在仓库中得到直接印证code/addons/vitest/project.json 中name: addon-vitest对应的 npm 包名则是storybook/addon-vitest见 code/package.json 的 dependenciescode/core/project.json 中name: core而 npm 包名是storybook/core。从源码结构看这一约定并非任意构建入口 scripts/build-package.ts 在解析命令行参数时是把 npm 包名去掉storybook/前缀得到后缀来匹配的并对storybook/cli做了特判映射为sb-cli。也就是说yarn build接受的包名标识与 Nx 项目名在绝大多数包上一致、在个别包如 CLI上以项目名为准因此技能明确规定查project.json而不是package.json可以避免代理拿 npm 包名去匹配导致构建失败。第三步按顺序执行构建与启动命令确定包列表后技能要求在code/目录下按顺序执行以下命令其中extra packages替换为第二步得到的包名列表rm -rf node_modules/.cache yarn yarn build storybook extra packages随后在后台执行启动命令NODE_OPTIONS--preserve-symlinks yarn storybook:ui --no-open这两组命令在仓库中都有明确落点可以逐条核对yarn build的来源。code/package.json 中定义了build: NODE_ENVproduction yarn --cwd ../scripts build-package最终转入 scripts/build-package.ts。该脚本基于 commander 解析参数支持--all、--watch、--prod等选项当直接传入包名如yarn build storybook addon-review addon-vitest时会按后缀匹配并对无效包名给出Did you mean ...的纠错提示后以退出码 1 终止。技能中的命令形式无--watch/--prod对应一次性的 production 环境构建。注意storybook本身也要出现在构建列表里——它是核心 CLI 包code/package.json 中storybook:ui脚本依赖的正是构建产物core/dist/bin/dispatcher.js。storybook:ui脚本的真实展开。code/package.json 中该脚本为NODE_OPTIONS--max_old_space_size4096 --trace-deprecation core/dist/bin/dispatcher.js dev --port 6006 --config-dir ./.storybook即通过 core 的 dispatcher 入口以 dev 模式在6006 端口启动配置目录指向 code/.storybook。技能外层追加的NODE_OPTIONS--preserve-symlinks作用于 yarn 进程本身的模块解析而脚本内部又为 dispatcher 进程设置了--max_old_space_size4096 --trace-deprecation大堆内存 弃用警告追踪。--no-open则透传给 dev 命令避免启动时自动打开浏览器。内部 Storybook 为何重建后生效。code/.storybook/main.ts 展示了内部 UI 的组织方式stories 直接扫描code/core/src、code/addons/*/src等源码目录且viteFinal在 DEVELOPMENT 模式下把storybook/manager-api、storybook/preview-api、storybook/theming等模块别名直接指向code/core/src下的源码文件如../core/src/preview-api/index.ts。从源码结构看这意味着 dev 模式下 manager 侧的变更可被 vite 直接热更新捕获但对 core 的编译入口、addons 的构建产物等路径上的改动仍需走重建包 重启这条技能流程这正是该工作流存在的理由。此外refs中挂载了一个远端 Chromatic 图标库作为Icons参考staticDirs暴露了/bundle-analyzer页面便于在内部 UI 里做 bundle 分析。处理端口占用技能明确给出了端口冲突的处理预案可能已经有一个 Storybook 实例在运行如果发现端口被占用应取消当前启动、杀掉旧进程以释放端口然后重新启动。结合上面的脚本定义内部 UI 默认监听 6006 端口因此实际操作中要检查的就是 6006 是否被旧的 dispatcher 进程占用。第四步给出 URL 并询问是否需要 reviewStorybook 启动成功后技能要求代理把 URL 告知用户默认即http://localhost:6006随后询问用户是否需要展示一次 reviewUI 审查。这一步把跑起来了与看得怎么样了拆成两个独立决策点URL 是每次必给的交付物而 review 是有代价的可选动作。第五步用 review-create MCP 工具展示 UI review如果用户选择查看 review技能要求使用 Storybook 的review-createMCP 工具针对与整个会话迄今为止内容相关的 stories 创建一次 UI review如果本次改动没有触及任何 UI 元素、因此不存在相关 stories则应反问用户希望审查什么内容而不是自行编造审查对象。这条指令在仓库源码中能得到完整的机制佐证工具注册与门控逻辑位于 code/addons/mcp/src/preset.ts其中注释说明stories-find-by-component、stories-changed、review-create等工具受特性开关门控且review-create额外要求experimentalReview特性标志开启code/addons/mcp/src/mcp-handler.test.ts 中的用例验证了该门控行为当experimentalReview与changeDetection两个 feature flag 同时开启时才注册review-create缺少任一条件则不注册内部 Storybook 的 code/.storybook/main.ts 恰好同时启用了features.experimentalReview: true与core.changeDetection: true以及features.changeDetection: true因此在该仓库内部运行这套技能时review-create工具是可用的。从源码结构看changeDetection使 MCP 能够感知哪些 stories 发生了变化与第二步确定被修改的包的思路一脉相承先定位改动范围再据此圈定 review 的 stories 集合。流程要点小结步骤动作依据1非显式命令触发时先询问用户是否重建重启拒绝即终止SKILL.md Step 12汇总会话中修改过的包取各自project.json的nameNx 项目名如addon-vitest、corecode/addons/vitest/project.json、code/core/project.json3在code/目录依次执行rm -rf node_modules/.cache、yarn、yarn build storybook extra packages后台执行NODE_OPTIONS--preserve-symlinks yarn storybook:ui --no-open端口被占则杀旧进程后重启code/package.json、scripts/build-package.ts4给出 URL默认 6006 端口并询问是否需要 reviewSKILL.md Step 45用review-createMCP 工具对与会话相关的 stories 建 review无相关 stories 时询问用户想看什么code/addons/mcp/src/preset.ts、code/.storybook/main.ts适用前提该工作流面向 Storybook 仓库自身的内部开发monorepocode/目录依赖 Yarn workspaces 与 Nx 工程结构且内部 UI 使用storybook/react-vite框架与./.storybook配置目录对外部普通 Storybook 用户项目并不适用。整套技能的本质是把改内部代码 → 重建产物 → 重启内部 UI → 按改动范围做 UI 审查这一高频动作固化为一套可被 AI 代理可靠执行、且每一步都有仓库内脚本与配置可核对的标准流程。【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Storybook 仓库内部开发流程：rebuild-restart-storybook 技能——重建并重启内部 Storybook 的标准化工作流
Storybook 仓库内部开发流程rebuild-restart-storybook 技能——重建并重启内部 Storybook 的标准化工作流【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook本文围绕 Storybook 开源仓库中的 Agent 技能定义文件 SKILL.md实体内容位于 .agents/skills/rebuild-restart-storybook/SKILL.md完整解析这套改动内部 Storybook 代码后如何重建、重启并审查 UI的五步工作流。读完后你将掌握如何确定被修改的 monorepo 包及其 Nx 项目名、如何在code/目录执行缓存清理、按需构建与后台启动内部 Storybook、如何处理端口占用以及如何借助 MCP 的review-create工具为本次改动生成 UI 审查。技能定位与触发条件rebuild-restart-storybook是 Storybook 仓库为 AI 编码代理Claude Code / Codex 等定义的标准化操作技能。SKILL.md 的 frontmatter 声明了它的元信息name: rebuild-restart-storybook技能标识名description用于在修改了内部 Storybook 代码core、addons、frameworks、renderers、libs 等之后重建并重启内部 Storybook UI并可选地展示一次 UI 审查review。触发时机是编辑了code/目录下的任意包之后或用户主动要求重建/重启 Storybook 时allowed-tools: Bash, Read技能执行时仅允许使用 Bash 与 Read 工具即整个流程只涉及读代码 跑命令不需要额外的写文件能力。需要说明的是.claude/skills/rebuild-restart-storybook/SKILL.md 本身只是一个指向.agents/skills/rebuild-restart-storybook/SKILL.md的引用文件内容为路径指针真正的技能正文以.agents/下的文件为准。这也体现了该仓库的约定技能定义统一维护在.agents/skills/下.claude/skills/侧做引用分发。第一步与用户确认是否重建交互护栏技能的第一步是一道交互确认除非用户是显式执行/rebuild-restart-storybook命令触发的代理都必须先询问用户是否要重建并重启 Storybook如果用户拒绝流程到此终止。这一步的设计意图在于重建 重启是一个重量级操作涉及清理缓存、重新构建多个包、拉起 dev server在代理顺带修改了代码之后不应未经确认就自动执行。它把是否重建的决策权交还给人类同时保留了用户显式斜杠命令时的免确认路径。第二步确定被修改的包并找到 Nx 项目名流程要求构建一个以空格分隔的 monorepo 包名列表列出本次会话中被修改过的所有包。关键规则是每个包必须使用其目录内project.json文件里的name字段即 Nx 项目名而不是package.json里的name字段即 npm 包名。技能给出的示例是如果修改了code/addons/review和code/addons/vitest得到的列表就是addon-review addon-vitest。这个规则可以在仓库中得到直接印证code/addons/vitest/project.json 中name: addon-vitest对应的 npm 包名则是storybook/addon-vitest见 code/package.json 的 dependenciescode/core/project.json 中name: core而 npm 包名是storybook/core。从源码结构看这一约定并非任意构建入口 scripts/build-package.ts 在解析命令行参数时是把 npm 包名去掉storybook/前缀得到后缀来匹配的并对storybook/cli做了特判映射为sb-cli。也就是说yarn build接受的包名标识与 Nx 项目名在绝大多数包上一致、在个别包如 CLI上以项目名为准因此技能明确规定查project.json而不是package.json可以避免代理拿 npm 包名去匹配导致构建失败。第三步按顺序执行构建与启动命令确定包列表后技能要求在code/目录下按顺序执行以下命令其中extra packages替换为第二步得到的包名列表rm -rf node_modules/.cache yarn yarn build storybook extra packages随后在后台执行启动命令NODE_OPTIONS--preserve-symlinks yarn storybook:ui --no-open这两组命令在仓库中都有明确落点可以逐条核对yarn build的来源。code/package.json 中定义了build: NODE_ENVproduction yarn --cwd ../scripts build-package最终转入 scripts/build-package.ts。该脚本基于 commander 解析参数支持--all、--watch、--prod等选项当直接传入包名如yarn build storybook addon-review addon-vitest时会按后缀匹配并对无效包名给出Did you mean ...的纠错提示后以退出码 1 终止。技能中的命令形式无--watch/--prod对应一次性的 production 环境构建。注意storybook本身也要出现在构建列表里——它是核心 CLI 包code/package.json 中storybook:ui脚本依赖的正是构建产物core/dist/bin/dispatcher.js。storybook:ui脚本的真实展开。code/package.json 中该脚本为NODE_OPTIONS--max_old_space_size4096 --trace-deprecation core/dist/bin/dispatcher.js dev --port 6006 --config-dir ./.storybook即通过 core 的 dispatcher 入口以 dev 模式在6006 端口启动配置目录指向 code/.storybook。技能外层追加的NODE_OPTIONS--preserve-symlinks作用于 yarn 进程本身的模块解析而脚本内部又为 dispatcher 进程设置了--max_old_space_size4096 --trace-deprecation大堆内存 弃用警告追踪。--no-open则透传给 dev 命令避免启动时自动打开浏览器。内部 Storybook 为何重建后生效。code/.storybook/main.ts 展示了内部 UI 的组织方式stories 直接扫描code/core/src、code/addons/*/src等源码目录且viteFinal在 DEVELOPMENT 模式下把storybook/manager-api、storybook/preview-api、storybook/theming等模块别名直接指向code/core/src下的源码文件如../core/src/preview-api/index.ts。从源码结构看这意味着 dev 模式下 manager 侧的变更可被 vite 直接热更新捕获但对 core 的编译入口、addons 的构建产物等路径上的改动仍需走重建包 重启这条技能流程这正是该工作流存在的理由。此外refs中挂载了一个远端 Chromatic 图标库作为Icons参考staticDirs暴露了/bundle-analyzer页面便于在内部 UI 里做 bundle 分析。处理端口占用技能明确给出了端口冲突的处理预案可能已经有一个 Storybook 实例在运行如果发现端口被占用应取消当前启动、杀掉旧进程以释放端口然后重新启动。结合上面的脚本定义内部 UI 默认监听 6006 端口因此实际操作中要检查的就是 6006 是否被旧的 dispatcher 进程占用。第四步给出 URL 并询问是否需要 reviewStorybook 启动成功后技能要求代理把 URL 告知用户默认即http://localhost:6006随后询问用户是否需要展示一次 reviewUI 审查。这一步把跑起来了与看得怎么样了拆成两个独立决策点URL 是每次必给的交付物而 review 是有代价的可选动作。第五步用 review-create MCP 工具展示 UI review如果用户选择查看 review技能要求使用 Storybook 的review-createMCP 工具针对与整个会话迄今为止内容相关的 stories 创建一次 UI review如果本次改动没有触及任何 UI 元素、因此不存在相关 stories则应反问用户希望审查什么内容而不是自行编造审查对象。这条指令在仓库源码中能得到完整的机制佐证工具注册与门控逻辑位于 code/addons/mcp/src/preset.ts其中注释说明stories-find-by-component、stories-changed、review-create等工具受特性开关门控且review-create额外要求experimentalReview特性标志开启code/addons/mcp/src/mcp-handler.test.ts 中的用例验证了该门控行为当experimentalReview与changeDetection两个 feature flag 同时开启时才注册review-create缺少任一条件则不注册内部 Storybook 的 code/.storybook/main.ts 恰好同时启用了features.experimentalReview: true与core.changeDetection: true以及features.changeDetection: true因此在该仓库内部运行这套技能时review-create工具是可用的。从源码结构看changeDetection使 MCP 能够感知哪些 stories 发生了变化与第二步确定被修改的包的思路一脉相承先定位改动范围再据此圈定 review 的 stories 集合。流程要点小结步骤动作依据1非显式命令触发时先询问用户是否重建重启拒绝即终止SKILL.md Step 12汇总会话中修改过的包取各自project.json的nameNx 项目名如addon-vitest、corecode/addons/vitest/project.json、code/core/project.json3在code/目录依次执行rm -rf node_modules/.cache、yarn、yarn build storybook extra packages后台执行NODE_OPTIONS--preserve-symlinks yarn storybook:ui --no-open端口被占则杀旧进程后重启code/package.json、scripts/build-package.ts4给出 URL默认 6006 端口并询问是否需要 reviewSKILL.md Step 45用review-createMCP 工具对与会话相关的 stories 建 review无相关 stories 时询问用户想看什么code/addons/mcp/src/preset.ts、code/.storybook/main.ts适用前提该工作流面向 Storybook 仓库自身的内部开发monorepocode/目录依赖 Yarn workspaces 与 Nx 工程结构且内部 UI 使用storybook/react-vite框架与./.storybook配置目录对外部普通 Storybook 用户项目并不适用。整套技能的本质是把改内部代码 → 重建产物 → 重启内部 UI → 按改动范围做 UI 审查这一高频动作固化为一套可被 AI 代理可靠执行、且每一步都有仓库内脚本与配置可核对的标准流程。【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考