Storybook QA 缺陷标签规范基于 GitHub CLI 的升级追踪与严重度分级实践【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook本文基于 Storybook 仓库内的 Agent 技能文件 github-qa-labels/SKILL.md系统讲解在升级 QA质量验证过程中如何为发现的 Issue 和 PR 建立规范的标签体系包括按版本追踪的upgrade:version标签、仅限 Bug 使用的sev:S1–sev:S4严重度标签以及批量打标操作。读完后你将掌握一套可直接执行的ghCLI 打标流程并理解它在 Storybook 发布与 QA 工作流中的位置与适用前提。技能定位QA 发现项的统一组织方式该文件是 Storybook 仓库中面向编码 Agent 的一项技能Skill其 frontmatter 声明了触发条件与权限边界name: github-qa-labels description: Label GitHub issues and PRs found during QA testing. Use when organizing QA findings with proper labels. allowed-tools: Bash从定义可以看出两点第一它的唯一职责是“为 QA 测试中创建的/整理的 Issue 和 PR 应用标签”即缺陷与问题的组织而不是修 Bug 本身第二allowed-tools: Bash表明它仅依赖 shell 能力实际操作全部通过 GitHub CLIgh完成。该文件位于 .agents/skills/ 目录下与仓库中其他协作技能如 open-pr、canary、storybook-upgrade共同构成维护者的日常协作工具集。QA 追踪标签upgrade:version升级 QA 时一个版本会产生多条发现缺陷、回归、修复 PR 等。为了让所有发现项可以按版本聚合检索规范为每个受测版本创建一个追踪标签upgrade:version并打给该版本 QA 期间产生的所有 Issue 和 PR。文档给出的完整操作分两步第 1 步创建标签若不存在gh label create upgrade:10.2 --repo storybookjs/storybook --color 0E8A16 --description Issues/PRs found during 10.2 upgrade QA参数说明--repo storybookjs/storybook显式指定目标仓库保证在非该仓库目录下执行命令时依然生效--color 0E8A16指定标签颜色绿色系便于在 PR/Issue 列表中快速识别 QA 追踪标签--description写明代价语义——“10.2 升级 QA 期间发现的 Issue/PR”使标签自解释。第 2 步把标签加到具体的 Issue 或 PR 上# Add to issue/PR gh issue edit NUMBER --repo storybookjs/storybook --add-label upgrade:10.2 gh pr edit NUMBER --repo storybookjs/storybook --add-label upgrade:10.2Issue 与 PR 使用gh issue edit/gh pr edit两条不同命令但参数结构一致--add-label以追加方式打标不会覆盖已有标签。这一点对实践很重要——QA 发现项往往同时还带有类型标签或 CI 标签追加语义避免了标签互相覆盖。严重度标签sev:S1到sev:S4仅限 Bug严重度标签用于量化 Bug 的影响程度但规范中有一条硬边界只加给 Bug不加给文档问题和功能请求。基本命令gh issue edit NUMBER --repo storybookjs/storybook --add-label sev:S2四级严重度的定义如下标签级别含义sev:S1Critical严重、阻塞性问题且无变通方案no workaroundsev:S2Significant显著问题可能有变通方案sev:S3Moderate中等问题存在变通方案sev:S4Minor轻微问题、边缘场景变通方案容易实施从分级逻辑看区分维度有二一是“是否阻塞用户”二是“是否存在 workaround”。S1 是双重命中阻塞且无解S4 是双重未命中S2 与 S3 的差别则在于 workaround 的确定性——S2 只是“可能有”S3 已确认“存在”。这一设计使维护者能在发版评审时按sev:S1/sev:S2过滤出必须在本版本解决的高危项。什么类型的发现项该打严重度标签原文档用一张决策表划定了边界这里完整保留类型是否打严重度标签Bug运行时错误是Bug类型错误是Bugautomigrate 问题是文档问题Documentation issue否功能请求Feature request否增强需求Enhancement否三类“是”都值得展开理解因为它们对应 Storybook 升级场景下最常见的缺陷形态运行时错误预览Preview/管理界面Manager加载失败、组件渲染报错等属于最直接的 QA 命中类型错误Storybook 10 起采用 ESM-only 分发见 minor-release 技能中的 10.0.0 版本说明升级后 TypeScript 项目常暴露出类型层面的不兼容这类问题虽不一定立即崩溃但会影响用户的开发体验同样纳入严重度分级automigrate 问题Storybook 提供自动化迁移automigrate机制帮助用户跨版本升级迁移脚本在真实项目上产生的错误是升级 QA 的核心检测面之一。而文档问题、功能请求、增强需求不进入严重度体系它们走各自的类型标签流程——这与 open-pr 技能 中定义的 PR 类型标签集合bug、maintenance、dependencies、build、documentation、feature request等是同一套标签语言两者互补类型标签描述“这是什么”严重度标签描述“有多严重仅 Bug 适用”。批量打标一条命令链完成多个发现项当一轮 QA 结束时通常需要把一批 Issue/PR 一次性挂到同一版本标签下。规范推荐的写法是用串联gh命令gh issue edit 33524 --repo storybookjs/storybook --add-label upgrade:10.2 \ gh issue edit 33527 --repo storybookjs/storybook --add-label upgrade:10.2 \ gh pr edit 33526 --repo storybookjs/storybook --add-label upgrade:10.2这里有两点实践细节串联而非;前一条失败如编号不存在、无权限时后续命令立即中止避免在错误状态下继续操作并给出“全部成功”的错觉混合issue edit与pr edit同一条链中同时处理 Issue 与 PR符合 QA 发现项“问题归 Issue、修复归 PR”的常见形态——例如本例中 33526 是修复 PR33524/33527 是问题 Issue三者共同归属upgrade:10.2追踪。在仓库发布流程中的位置理解这套标签规范的价值需要把它放回 Storybook 的发布流程中。CONTRIBUTING/RELEASING.md 描述了 Releaser 的七步发布流程其中第 3 步即为“QA Each Merged Pull Request”——逐项验证已合入 PR 的内容是否适合本次版本、标题与标签是否正确、补丁是否已在预发布中验证过。QA 过程中发现的回归与问题正是通过本文描述的upgrade:versionsev:S*标签体系被系统化追踪的。与之配合的仓库内技能还有canary 技能通过gh workflow run --repo storybookjs/storybook publish.yml --field prPR_NUMBER触发 PR 的 canary 发布产出版本号为0.0.0-pr-PR_NUMBER-sha-SHORT_SHA的 npm 包QA 人员用它在下游项目中实测 PR 变更storybook-upgrade 技能用npx storybookVERSION upgrade把外部项目整体升级到指定版本含 canary是“对每个已合入 PR 做 QA”的实操载体。也就是说仓库内的证据链是canary/upgrade 两个技能负责“把变更装进外部项目做真实验证”gh workflow run与gh issue/pr edit负责“把验证结果以标签形式落回 GitHub”而 github-qa-labels 规范则保证这些结果可被按版本、按严重度聚合查询。从源码结构看这三者共同支撑了 RELEASING.md 中 QA 步骤的可执行性。适用前提与限制所有命令默认目标仓库为storybookjs/storybook且依赖ghCLI 已完成认证并具备对目标仓库写标签的权限upgrade:10.2、sev:S2等均为示意值实际使用时替换为受测版本号与对应严重级别gh label create在标签已存在时会报错可先查询再创建或直接忽略报错继续严重度标签的“仅 Bug 适用”是规范约束而非 CLI 约束——命令本身可以给它任何对象打标但打给文档问题或功能请求会污染后续按sev:S*过滤缺陷的结果本规范面向 Issue/PR 的元数据管理不涉及缺陷本身的修复流程也不改变 RELEASING.md 中定义的 patch:yes/freeze 等发版标签语义。【免费下载链接】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 QA 缺陷标签规范：基于 GitHub CLI 的升级追踪与严重度分级实践
Storybook QA 缺陷标签规范基于 GitHub CLI 的升级追踪与严重度分级实践【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook本文基于 Storybook 仓库内的 Agent 技能文件 github-qa-labels/SKILL.md系统讲解在升级 QA质量验证过程中如何为发现的 Issue 和 PR 建立规范的标签体系包括按版本追踪的upgrade:version标签、仅限 Bug 使用的sev:S1–sev:S4严重度标签以及批量打标操作。读完后你将掌握一套可直接执行的ghCLI 打标流程并理解它在 Storybook 发布与 QA 工作流中的位置与适用前提。技能定位QA 发现项的统一组织方式该文件是 Storybook 仓库中面向编码 Agent 的一项技能Skill其 frontmatter 声明了触发条件与权限边界name: github-qa-labels description: Label GitHub issues and PRs found during QA testing. Use when organizing QA findings with proper labels. allowed-tools: Bash从定义可以看出两点第一它的唯一职责是“为 QA 测试中创建的/整理的 Issue 和 PR 应用标签”即缺陷与问题的组织而不是修 Bug 本身第二allowed-tools: Bash表明它仅依赖 shell 能力实际操作全部通过 GitHub CLIgh完成。该文件位于 .agents/skills/ 目录下与仓库中其他协作技能如 open-pr、canary、storybook-upgrade共同构成维护者的日常协作工具集。QA 追踪标签upgrade:version升级 QA 时一个版本会产生多条发现缺陷、回归、修复 PR 等。为了让所有发现项可以按版本聚合检索规范为每个受测版本创建一个追踪标签upgrade:version并打给该版本 QA 期间产生的所有 Issue 和 PR。文档给出的完整操作分两步第 1 步创建标签若不存在gh label create upgrade:10.2 --repo storybookjs/storybook --color 0E8A16 --description Issues/PRs found during 10.2 upgrade QA参数说明--repo storybookjs/storybook显式指定目标仓库保证在非该仓库目录下执行命令时依然生效--color 0E8A16指定标签颜色绿色系便于在 PR/Issue 列表中快速识别 QA 追踪标签--description写明代价语义——“10.2 升级 QA 期间发现的 Issue/PR”使标签自解释。第 2 步把标签加到具体的 Issue 或 PR 上# Add to issue/PR gh issue edit NUMBER --repo storybookjs/storybook --add-label upgrade:10.2 gh pr edit NUMBER --repo storybookjs/storybook --add-label upgrade:10.2Issue 与 PR 使用gh issue edit/gh pr edit两条不同命令但参数结构一致--add-label以追加方式打标不会覆盖已有标签。这一点对实践很重要——QA 发现项往往同时还带有类型标签或 CI 标签追加语义避免了标签互相覆盖。严重度标签sev:S1到sev:S4仅限 Bug严重度标签用于量化 Bug 的影响程度但规范中有一条硬边界只加给 Bug不加给文档问题和功能请求。基本命令gh issue edit NUMBER --repo storybookjs/storybook --add-label sev:S2四级严重度的定义如下标签级别含义sev:S1Critical严重、阻塞性问题且无变通方案no workaroundsev:S2Significant显著问题可能有变通方案sev:S3Moderate中等问题存在变通方案sev:S4Minor轻微问题、边缘场景变通方案容易实施从分级逻辑看区分维度有二一是“是否阻塞用户”二是“是否存在 workaround”。S1 是双重命中阻塞且无解S4 是双重未命中S2 与 S3 的差别则在于 workaround 的确定性——S2 只是“可能有”S3 已确认“存在”。这一设计使维护者能在发版评审时按sev:S1/sev:S2过滤出必须在本版本解决的高危项。什么类型的发现项该打严重度标签原文档用一张决策表划定了边界这里完整保留类型是否打严重度标签Bug运行时错误是Bug类型错误是Bugautomigrate 问题是文档问题Documentation issue否功能请求Feature request否增强需求Enhancement否三类“是”都值得展开理解因为它们对应 Storybook 升级场景下最常见的缺陷形态运行时错误预览Preview/管理界面Manager加载失败、组件渲染报错等属于最直接的 QA 命中类型错误Storybook 10 起采用 ESM-only 分发见 minor-release 技能中的 10.0.0 版本说明升级后 TypeScript 项目常暴露出类型层面的不兼容这类问题虽不一定立即崩溃但会影响用户的开发体验同样纳入严重度分级automigrate 问题Storybook 提供自动化迁移automigrate机制帮助用户跨版本升级迁移脚本在真实项目上产生的错误是升级 QA 的核心检测面之一。而文档问题、功能请求、增强需求不进入严重度体系它们走各自的类型标签流程——这与 open-pr 技能 中定义的 PR 类型标签集合bug、maintenance、dependencies、build、documentation、feature request等是同一套标签语言两者互补类型标签描述“这是什么”严重度标签描述“有多严重仅 Bug 适用”。批量打标一条命令链完成多个发现项当一轮 QA 结束时通常需要把一批 Issue/PR 一次性挂到同一版本标签下。规范推荐的写法是用串联gh命令gh issue edit 33524 --repo storybookjs/storybook --add-label upgrade:10.2 \ gh issue edit 33527 --repo storybookjs/storybook --add-label upgrade:10.2 \ gh pr edit 33526 --repo storybookjs/storybook --add-label upgrade:10.2这里有两点实践细节串联而非;前一条失败如编号不存在、无权限时后续命令立即中止避免在错误状态下继续操作并给出“全部成功”的错觉混合issue edit与pr edit同一条链中同时处理 Issue 与 PR符合 QA 发现项“问题归 Issue、修复归 PR”的常见形态——例如本例中 33526 是修复 PR33524/33527 是问题 Issue三者共同归属upgrade:10.2追踪。在仓库发布流程中的位置理解这套标签规范的价值需要把它放回 Storybook 的发布流程中。CONTRIBUTING/RELEASING.md 描述了 Releaser 的七步发布流程其中第 3 步即为“QA Each Merged Pull Request”——逐项验证已合入 PR 的内容是否适合本次版本、标题与标签是否正确、补丁是否已在预发布中验证过。QA 过程中发现的回归与问题正是通过本文描述的upgrade:versionsev:S*标签体系被系统化追踪的。与之配合的仓库内技能还有canary 技能通过gh workflow run --repo storybookjs/storybook publish.yml --field prPR_NUMBER触发 PR 的 canary 发布产出版本号为0.0.0-pr-PR_NUMBER-sha-SHORT_SHA的 npm 包QA 人员用它在下游项目中实测 PR 变更storybook-upgrade 技能用npx storybookVERSION upgrade把外部项目整体升级到指定版本含 canary是“对每个已合入 PR 做 QA”的实操载体。也就是说仓库内的证据链是canary/upgrade 两个技能负责“把变更装进外部项目做真实验证”gh workflow run与gh issue/pr edit负责“把验证结果以标签形式落回 GitHub”而 github-qa-labels 规范则保证这些结果可被按版本、按严重度聚合查询。从源码结构看这三者共同支撑了 RELEASING.md 中 QA 步骤的可执行性。适用前提与限制所有命令默认目标仓库为storybookjs/storybook且依赖ghCLI 已完成认证并具备对目标仓库写标签的权限upgrade:10.2、sev:S2等均为示意值实际使用时替换为受测版本号与对应严重级别gh label create在标签已存在时会报错可先查询再创建或直接忽略报错继续严重度标签的“仅 Bug 适用”是规范约束而非 CLI 约束——命令本身可以给它任何对象打标但打给文档问题或功能请求会污染后续按sev:S*过滤缺陷的结果本规范面向 Issue/PR 的元数据管理不涉及缺陷本身的修复流程也不改变 RELEASING.md 中定义的 patch:yes/freeze 等发版标签语义。【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考