gstack /qa 工作流全解Test → Fix → Verify 的自动化浏览器 QA 与缺陷修复闭环【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文以 gstack 仓库的 qa/SKILL.md 为主体完整拆解 gstack 的 QA 技能从触发词、三档测试层级Quick / Standard / Exhaustive、四种运行模式diff-aware / Full / Quick / Regression到 11 个阶段的 Test → Fix → Verify 工作流、健康分加权评分标准、缺陷分级分类法、原子提交修复循环、回归测试生成与 WTF-likelihood 自我调节机制。读完你可以理解一个AI QA 工程师如何在真实浏览器中像用户一样测试 Web 应用、为每个修复做原子提交与前后截图证据、并输出可放入 PR 描述的 ship-readiness 报告。一、技能定位QA 工程师 缺陷修复工程师的双重角色gstack 是 Garry Tan 的 Claude Code 工作流配置集其中 23 个技能分别扮演 CEO、设计师、工程经理、发布经理、文档工程师和 QA 等角色。/qa是其中的 QA 技能其 SKILL.md 头部qa/SKILL.md声明了元信息name: qaversion: 2.0.0preamble-tier: 4description: Systematically QA test a web application and fix bugs found. (gstack)允许的工具Bash、Read、Write、Edit、Glob、Grep、AskUserQuestion、WebSearch触发词qa test this、find bugs on site、test the site语音别名包括 quality check、test the app、run QA。技能正文开宗明义qa/SKILL.mdYou are a QA engineer AND a bug-fix engineer. Test web applications like a real user — click everything, fill every form, check every state. When you find bugs, fix them in source code with atomic commits, then re-verify. Produce a structured report with before/after evidence.也就是说/qa不是只测不改的报告工具而是一个完整闭环测试 → 发现缺陷 → 源码级最小修复 → 原子提交 → 浏览器复测验证 → 结构化报告。如果只需要报告而不修改代码应使用配套的 qa-only 技能just report bugs、test but dont fix 触发。二、调用入口与参数解析/qa启动时先解析用户请求中的 6 个参数qa/SKILL.md参数默认值覆盖示例Target URL自动探测或必填https://myapp.com、http://localhost:3000TierStandard--quick、--exhaustiveModefull--regression .gstack/qa-reports/baseline.jsonOutput dir.gstack/qa-reports/Output to /tmp/qaScope全应用或 diff 范围Focus on the billing pageAuthNoneSign in to userexample.com、Import cookies from cookies.json三档 Tier 直接决定哪些严重级别的缺陷会被修复Quick只修 critical highStandard再加 medium默认档Exhaustive连 low / 装饰性问题也一并修。另外有一个自动行为如果用户没给 URL 且当前在 feature 分支上自动进入diff-aware 模式——这是最常见的场景即开发者刚在分支上写完代码想验证它是否真的能工作。启动前还有两项环境检查1. CDP 模式检测——检查 browse 服务是否连接到用户真实浏览器$B status 2/dev/null | grep -q Mode: cdp echo CDP_MODEtrue || echo CDP_MODEfalse若CDP_MODEtrue则跳过 cookie 导入提示、跳过 user-agent 覆盖、跳过无头检测补丁——因为真实浏览器里已有真实的登录会话和 user-agent。2. 干净工作树检查——/qa的每个修复都要独立原子提交所以要求git status --porcelain输出非空工作树脏时立即 STOP 并用 AskUserQuestion 提供三个选项A) 先提交当前改动再开始 QA推荐未提交的工作应保留为提交B) stash 后 QA 完成再 popC) 中止用户自行清理。三、browse 二进制与测试框架引导3.1 定位 browse 浏览器引擎/qa依赖 gstack 的 browse 工具持久化 headless Chromium首次调用自动启动约 3 秒之后每条命令约 100mscookie / 标签页 / 登录态在调用间持久详见 browse/SKILL.md。定位方式_ROOT$(git rev-parse --show-toplevel 2/dev/null) B [ -n $_ROOT ] [ -x $_ROOT/.claude/skills/gstack/browse/dist/browse ] B$_ROOT/.claude/skills/gstack/browse/dist/browse [ -z $B ] B$HOME/.claude/skills/gstack/browse/dist/browse if [ -x $B ]; then echo READY: $B else echo NEEDS_SETUP fi若为NEEDS_SETUP先征得用户同意one-time build (~10 seconds)然后cd SKILL_DIR ./setup若机器上没有bun会下载固定版本 1.3.10 的安装脚本并校验 SHA-256bab8acfb046aac8c72407bdcce903957665d655d7acaa3e11c7c4616beae68dd不匹配则报错退出。这段逻辑与 browse/SKILL.md 的 SETUP 小节完全一致说明/qa直接复用了 browse 技能的构建路径。3.2 测试框架引导Test Framework Bootstrap修复循环要写回归测试所以/qa在 Setup 阶段先确认项目有没有可用的测试命令。规则的核心是证据不盲跑先读项目的 CLAUDE.md以及 TESTING.md。如果其中已写明测试命令直接采用跳过全部检测与引导。否则运行一组 marker 探测脚本qa/SKILL.md识别运行时生态与既有测试证据# Definitive ecosystem markers (presence ecosystem, NOT a command to run) [ -f manage.py ] echo RUNTIME:python FRAMEWORK:django MARKER:manage.py { [ -f pyproject.toml ] || [ -f pytest.ini ] || [ -f tox.ini ] || [ -f setup.cfg ] || [ -f requirements.txt ]; } echo RUNTIME:python [ -f Gemfile ] || [ -f Rakefile ] || [ -f .rspec ] echo RUNTIME:ruby [ -f package.json ] echo RUNTIME:node [ -f go.mod ] echo RUNTIME:go [ -f Cargo.toml ] echo RUNTIME:rust [ -f composer.json ] echo RUNTIME:php [ -f mix.exs ] echo RUNTIME:elixir [ -f pom.xml ] echo RUNTIME:jvm BUILD:maven { [ -f build.gradle ] || [ -f build.gradle.kts ]; } echo RUNTIME:jvm BUILD:gradle # 已有测试路径配置文件、声明的脚本、测试文件 ls jest.config.* vitest.config.* playwright.config.* .rspec pytest.ini tox.ini phpunit.xml* 2/dev/null [ -f package.json ] grep -q test[[:space:]]*: package.json echo SCRIPT:package.json test [ -f Makefile ] grep -qE ^(test|check): Makefile echo TARGET:make test git ls-files | grep -cE (^|/)(tests?|spec|__tests__)/|(^|/)tests?\.py$|...|\.(test|spec)\.[jt]sx?$|_spec\.rb$|Test\.(java|kt)$ | sed s/^/TESTFILES:/ # Rust 单元测试在 src/ 内部仅靠文件名会漏掉 [ -f Cargo.toml ] git grep -lF #[test] -- src /dev/null 21 echo TESTS:rust in-source # 用户此前拒绝过引导 [ -f .gstack/no-test-bootstrap ] echo BOOTSTRAP_DECLINED文档特别强调两个易错点marker 只是证据不是可以盲跑的命令在一个从未用过该 runner 的项目上探测性执行会大声失败且毫无信息量没有配置文件不等于没有测试——Django 的测试在app/tests.py、Go 在*_test.go、Rust 在src/内的#[test]块python manage.py test全绿就是已测试项目绝不引导安装第二套框架。发现任何既有测试证据配置文件、声明的 test 脚本、TESTFILES:计数非零、TESTS:rust in-source不引导改为通过 AskUserQuestion 把候选命令给用户确认并持久化到 CLAUDE.md 的## Testing段之后不再询问再读 2-3 个既有测试文件学习命名、导入、断言风格。完全没有生态 marker问用户语言栈Node / Ruby / Python / Go / Rust / PHP / Elixir / 不需要测试。选不需要则写.gstack/no-test-bootstrap标记文件。有生态但零测试证据 → 执行引导步骤 B2–B8B2 研究最佳实践用 WebSearch 查[runtime] best test framework 2025 2026不可用时回落到内置推荐表Ruby/Rails → minitest fixtures capybaraNode.js → vitest testing-libraryNext.js → vitest testing-library/react playwrightPython → pytest pytest-covGo → stdlib testing testifyRust → cargo test mockallPHP → phpunit mockeryElixir → ExUnit ex_machina 等。B3 框架选择AskUserQuestion 给出 A) 首选方案含理由与包清单、B) 替代方案、C) 跳过。B4 安装配置装包、建最小配置、建目录、写一个示例测试验证 setup安装失败则调试一次仍失败就git checkout --回滚并继续无测试流程。B4.5 首批真实测试git log --since30.days --name-only --format | sort | uniq -c | sort -rn | head -10找近期改动文件按风险排序错误处理器 带条件分支的业务逻辑 API 端点 纯函数每个文件写一个有真实断言的测试禁止expect(x).toBeDefined()这类空断言通过则保留失败修一次仍失败就静默删除。测试文件里永远不引入密钥与凭证。B5 验证跑完整测试套件失败则调试一次仍失败回滚全部引导改动。B5.5 CI 流水线检测.github/等 CI providerGitHub Actions 则生成.github/workflows/test.ymlruns-on: ubuntu-latest、对应 runtimes 的 setup action、B5 验证过的测试命令、push pull_request 触发非 GitHub CI 则跳过并提示手动添加。B6 写 TESTING.md哲学100% test coverage is the key to great vibe coding、框架与版本、已验证的运行命令、Unit/Integration/Smoke/E2E 分层、命名与 setup/teardown 约定。已存在则更新而非覆盖。B7 更新 CLAUDE.md追加## Testing段已有则跳过写明运行命令、目录以及测试预期新函数配测试、修 bug 配回归测试、加错误处理配触发该错误的测试、加 if/else 时两条路径都测、绝不提交让既有测试变红的代码。B8 提交git commit -m chore: bootstrap test framework ({framework name})。最后创建输出目录mkdir -p .gstack/qa-reports/screenshots。四、四种运行模式/qa支持四种模式qa/SKILL.mdTier 控制修什么Mode 控制测什么4.1 Diff-aware 模式feature 分支 无 URL 时自动启用主模式分析分支 diffgit diff main...HEAD --name-only git log main..HEAD --oneline从改动文件反推受影响的页面/路由controller/route 文件 → 它们服务的 URL 路径view/template/component → 渲染它们的页面model/service → 使用这些 model 的页面查引用它的 controllerCSS → 引入该样式表的页面API 端点 → 直接用$B js await fetch(/api/...)测试静态页面 → 直接导航。若 diff 推不出任何明确页面不跳过浏览器测试——回落到 Quick 模式首页 顶部 5 个导航目标 控制台错误 发现的交互元素因为后端、配置与基础设施改动同样影响应用行为。探测本地运行中的应用依次尝试常见开发端口$B goto http://localhost:3000 2/dev/null echo Found app on :3000 || \ $B goto http://localhost:4000 2/dev/null echo Found app on :4000 || \ $B goto http://localhost:8080 2/dev/null echo Found app on :8080找不到则查 PR 或环境里的 staging/preview URL再不行就向用户要 URL。逐个测试受影响的页面导航 → 截图 → 查控制台 → 交互类改动做端到端验证 → 操作前后用snapshot -D对比确认改动产生了预期效果。与提交信息、PR 描述交叉验证意图——这个改动应该做什么验证它确实做到了。查 TODOS.md若存在与改动文件相关的已知 bug 纳入测试计划QA 中发现的 TODOS.md 之外的新 bug 记入报告。报告限定在分支改动范围内Changes tested: N pages/routes affected by this branch每页给出是否可用 截图证据 相邻页面回归检查。4.2 其余三种模式Full提供 URL 时的默认系统性探索访问所有可达页面记录 5-10 个证据充分的缺陷产出健康分。耗时 5-15 分钟视应用规模而定。Quick--quick30 秒冒烟测试。首页 顶部 5 个导航目标检查能加载有控制台错误有死链产出健康分不做详细缺陷记录。Regression--regression baseline跑完整 Full 模式后加载baseline.jsondiff 出哪些修好了、哪些是新增的、分数变化多少把回归小节追加进报告。五、Phase 1-6QA 基线工作流Phase 1初始化找到 browse 二进制、建输出目录、把报告模板qa/templates/qa-report-template.md复制到输出目录、启动计时器。Phase 2认证如需用户给了凭据时模拟真实登录$B goto login-url $B snapshot -i # find the login form $B fill e3 userexample.com $B fill e4 [REDACTED] # NEVER include real passwords in report $B click e5 # submit $B snapshot -D # verify login succeeded提供了 cookie 文件则$B cookie-import cookies.json后直达目标 URL遇到 2FA/OTP 向用户要验证码并等待遇到 CAPTCHA 则请用户在浏览器里手动完成后通知继续。Phase 3定向Orient先拿应用地图$B goto target-url $B snapshot -i -a -o $REPORT_DIR/screenshots/initial.png $B links # map navigation structure $B console --errors # any errors on landing?同时探测前端框架并记入报告元数据HTML 里有__next或_next/data请求 → Next.js有csrf-tokenmeta 标签 → RailsURL 含wp-content→ WordPress客户端路由无整页刷新 → SPA。SPA 的links命令可能返回很少导航在客户端完成要改用snapshot -i找导航元素。Phase 4探索Explore逐页访问每页三件套$B goto page-url $B snapshot -i -a -o $REPORT_DIR/screenshots/page-name.png $B console --errors然后执行 qa/references/issue-taxonomy.md 定义的逐页探索清单1) 视觉扫描——看标注截图找布局问题2) 交互元素——点每个按钮/链接/控件是否做了它声称的事3) 表单——空提交、非法数据、边界值长文本、特殊字符4) 导航——进出路径、面包屑、后退键、深链、移动端菜单5) 状态——空态、加载中、错误态、溢出态6) 控制台——交互后再跑console --errors7) 响应式——移动端视口按需检查8) 认证边界——登出状态、不同角色下行为如何。$B viewport 375x812 $B screenshot $REPORT_DIR/screenshots/page-mobile.png $B viewport 1280x720深度分配原则核心功能首页、dashboard、checkout、搜索多花时间次要页面about、terms、privacy少花。Phase 5即时记录Document发现即记录绝不攒批。证据分两档交互类 bug坏流程、死按钮、表单失败操作前截图 → 执行操作 → 结果截图 →snapshot -D展示变化 → 写引用截图的复现步骤$B screenshot $REPORT_DIR/screenshots/issue-001-step-1.png $B click e5 $B screenshot $REPORT_DIR/screenshots/issue-001-result.png $B snapshot -D静态 bug错字、布局问题、缺图一张标注截图 问题描述$B snapshot -i -a -o $REPORT_DIR/screenshots/issue-002.png每个问题立即按模板格式写入报告。Phase 6收尾Wrap Up按评分标准下一节计算健康分2. 写 Top 3 Things to Fix3. 汇总所有页面看到的控制台错误4. 更新严重级别计数表5. 填充报告元数据日期、耗时、访问页数、截图数、框架6.保存基线baseline.json{ date: YYYY-MM-DD, url: target, healthScore: N, issues: [{ id: ISSUE-001, title: ..., severity: ..., category: ... }], categoryScores: { console: N, links: N } }Regression 模式下再加载基线文件比较分数 delta、已修复项、新增项并追加回归小节。六、健康分评分标准Health Score Rubric每个类别先算 0-100 分再加权平均qa/SKILL.mdConsole权重 15%0 错误 → 1001-3 个错误 → 704-10 个 → 4010 个以上 → 10。Links权重 10%0 死链 → 100每个死链 -15下限 0。其余六类Visual、Functional、UX、Content、Performance、Accessibility每类从 100 起按发现扣减——Critical 缺陷 -25、High -15、Medium -8、Low -3每类下限 0。权重表类别权重Console15%Links10%Visual10%Functional20%UX15%Performance10%Content5%Accessibility15%最终分score Σ (category_score × weight)。功能正确性Functional 20%权重最高内容权重最低这个分布体现了用户能不能用优先于文字是否通顺的 QA 价值观。七、缺陷分级与分类法Issue Taxonomyqa/references/issue-taxonomy.md 定义了四级严重度级别定义示例critical阻塞核心工作流、造成数据丢失或应用崩溃表单提交导致错误页、checkout 流程断裂、无确认即删除数据high主要功能损坏或不可用且无绕行方案搜索返回错误结果、文件上传静默失败、认证重定向死循环medium功能可用但存在明显问题有绕行方案页面加载慢5s、缺表单校验但提交仍可用、仅移动端布局破损low轻微外观或打磨问题页脚错字、1px 对齐问题、hover 状态不一致七个类别Visual/UI布局破损、图片缺失、z-index 错误、暗色模式问题等、Functional死链、死按钮、表单校验缺失、状态不持久、竞态条件、UX导航困惑、缺加载指示、500ms 无反馈、破坏性操作无确认、死胡同、Content错字、lorem ipsum 残留、截断文本、空态缺失、Performance3s 加载、布局偏移、单页 50 请求、阻塞 JS、Console/ErrorsJS 异常、4xx/5xx、CORS、混合内容、CSP 违规、Accessibility缺 alt 文本、表单无标签、键盘导航断裂、焦点陷阱、对比度不足。八、框架特化测试指引SKILL.md 为四类技术栈给出专项检查点qa/SKILL.mdNext.js查 hydration 错误Hydration failed、Text content did not match监控_next/data请求的 404点链接做客户端导航而不是goto才能抓到路由问题动态内容页查 CLS。Rails查 N1 查询警告development 模式验证表单里的 CSRF token测 Turbo/Stimulus 集成——页面过渡是否顺滑flash 消息是否正确出现并消失。WordPress查插件冲突来自不同插件的 JS 错误登录用户的管理栏可见性测/wp-json/REST 端点查混合内容警告WP 上很常见。通用 SPAReact/Vue/Angular用snapshot -i找导航links会漏客户端路由查陈旧状态离开再回来数据刷新了吗测浏览器前进/后退history 处理对吗长时间使用后的内存泄漏迹象。九、Phase 7-8分诊与修复循环Phase 7Triage按严重度排序后按 Tier 决定修哪些Quick 只修 critical highStandard 加 mediumExhaustive 全修。凡无法从源码修复的问题第三方 widget 的 bug、基础设施问题无论 Tier 一律标记 deferred。分诊后还要针对缺陷所在组件刷新 learnings选一个纯字母/连字符的关键词如checkout-button、signup-form、payment不能带引号、斜杠、点、冒号、空格~/.claude/skills/gstack/bin/gstack-learnings-search --query your-keyword --limit 5 2/dev/null || true若命中历史学习用一句话说明哪条适用于即将做的修复没有命中也照常继续——无命中本身就是有用信息。Phase 8Fix Loop每个可修复问题按严重度顺序8a 定位grep 错误信息、组件名、路由定义glob 匹配受影响页面的文件模式只改与该问题直接相关的文件。8b 最小修复读懂上下文后做解决该问题的最小改动不重构周边代码、不加功能、不顺手改进无关的东西。8c 原子提交一个修复一个提交绝不捆绑git add only-changed-files git commit -m fix(qa): ISSUE-NNN — short description8d 复测导航回受影响页面拍 before/after 截图对查控制台用snapshot -D确认变化符合预期$B goto affected-url $B screenshot $REPORT_DIR/screenshots/issue-NNN-after.png $B console --errors $B snapshot -D8e 分类verified复测确认修复且无新错误/best-effort已修但无法完全验证如需特定认证态或外部服务/reverted检测到回归 →git revert HEAD→ 标记 deferred。8e.5 回归测试分类非 verified、或纯视觉/CSS 修复、或无测试框架且用户拒绝引导时跳过。五步流程研究项目既有测试模式读 2-3 个离修复最近的测试文件精确匹配文件命名、导入、断言风格、describe/it 嵌套、setup/teardown——回归测试要看起来是同一个开发者写的。追踪 bug 代码路径后写测试什么输入/状态触发了 bug精确前置条件走了哪条代码路径断在哪一行/哪个条件还有哪些输入会撞同一条路径修复周围的边界null、空数组、边界值测试必须构造触发 bug 的前置条件、执行暴露 bug 的动作、断言正确行为而不是它渲染了或没抛异常。并附完整归因注释// Regression: ISSUE-NNN — {what broke} // Found by /qa on {YYYY-MM-DD} // Report: .gstack/qa-reports/qa-report-{domain}-{date}.md测试类型决策控制台错误/JS 异常/逻辑 bug → 单元或集成测试表单断裂/API 失败/数据流 bug → 带请求/响应的集成测试带 JS 行为的视觉 bug坏下拉、动画→ 组件测试纯 CSS → 跳过靠 QA 重跑兜底。mock 掉全部外部依赖DB、API、Redis、文件系统用自增命名{name}.regression-*.test.{ext}避免冲突。 3.只跑新测试文件{detected test command} {new-test-file}。 4.评估通过 → 提交test(qa): regression test for ISSUE-NNN — {desc}失败 → 修一次仍失败删测试并 defer探索超 2 分钟 → 跳过并 defer。 5.WTF-likelihood 排除测试提交不计入下面的启发式计分。8f 自我调节STOP AND EVALUATE每 5 次修复或任何一次 revert 后计算WTF-LIKELIHOOD: Start at 0% Each revert: 15% Each fix touching 3 files: 5% After fix 15: 1% per additional fix All remaining Low severity: 10% Touching unrelated files: 20%WTF 20% 立即停止向用户展示已做的工作并询问是否继续。硬上限50 次修复之后无论还有多少遗留问题都停止。这套机制防止 AI 在长会话里越修越离谱——修复率失控本身就是回归风险信号。十、Phase 9-11最终验证、报告与学习沉淀Phase 9 Final QA所有修复完成后对受影响页面重跑 QA计算最终健康分。若最终分比基线更差显著 WARN——说明引入了回归。Phase 10 Report报告双写——本地.gstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md文件名用域名 日期如qa-report-myapp-com-2026-03-12.md以及项目作用域的~/.gstack/projects/{slug}/{user}-{branch}-test-outcome-{datetime}.md跨会话上下文。每个问题额外记录 Fix Statusverified / best-effort / reverted / deferred、Commit SHA、改动文件、before/after 截图。汇总段给出总缺陷数、修复数verified: X, best-effort: Y, reverted: Z、deferred 数、健康分 deltabaseline → final以及一行可粘贴进 PR 的总结QA found N issues, fixed M, health score X → Y.Phase 11 TODOS.md 更新若仓库有 TODOS.md新的 deferred bug 按严重度/类别/复现步骤写成 TODOTODOS.md 里被本次修掉的条目标注 Fixed by /qa on {branch}, {date}。输出目录结构.gstack/qa-reports/ ├── qa-report-{domain}-{YYYY-MM-DD}.md # 结构化报告 ├── screenshots/ │ ├── initial.png # 落地页标注截图 │ ├── issue-001-step-1.png # 逐问题证据 │ ├── issue-001-result.png │ ├── issue-001-before.png # 修复前若已修 │ ├── issue-001-after.png # 修复后若已修 │ └── ... └── baseline.json # 回归模式用报告本体由 qa/templates/qa-report-template.md 定义元数据表Date/URL/Branch/Commit/PR/Tier/Scope/Duration/访问页数/截图数/Framework、Health Score 分类表、Top 3 Things to Fix、Console Health 聚合表错误信息/次数/首次出现 URL、按严重度汇总的 Summary 表、每个 ISSUE 的 Severity/Category/URL/描述/带截图的复现步骤、Fixes Applied 表Issue/Fix Status/Commit/Files Changed、Before/After Evidence、Regression Tests 表含 Deferred Tests 的 Precondition/Action/Expected/Why deferred、Ship Readiness 表health score before → after、issues found、fixes applied、deferred与 PR Summary、Regression 对比表。流程结束前还有学习沉淀把本次发现的非显而易见的模式、陷阱或架构洞见写入 learningsgstack-learnings-log类型分pattern/pitfall/preference/architecture/tool/operational来源分observed/user-stated/inferred/cross-model置信度 1-10代码里验证过的模式 8-9不确定的推断 4-5用户明确说出的偏好 10并附上 learning 引用的文件路径以便后续陈旧检测。十一、十二条 QA 铁律SKILL.md 用 Important Rules 固化了执行纪律qa/SKILL.md这些是理解该技能设计哲学的关键复现就是一切——每个问题至少一张截图无例外记录前先验证——重试一次确认可复现排除偶发绝不包含凭据——复现步骤里密码一律写[REDACTED]增量写入——发现即追加进报告不攒批绝不读源码测试阶段——像用户一样测不是像开发者一样测每次交互后查控制台——不表现为视觉问题的 JS 错误也是 bug像用户一样测——真实数据、完整工作流端到端走一遍深度优于广度——5-10 个有证据的缺陷好过 20 条含糊描述绝不删除输出文件——截图与报告只增不减这是有意的棘手 UI 用snapshot -C——能发现可访问性树漏掉的 cursor:pointer / onclick / tabindex div对应 browse 技能的 Core QA Patterns 第 5 条每次截图后必须用 Read 工具把图片读给会话看——否则截图对用户不可见responsive产生 3 张就全读绝不拒绝使用浏览器——用户调 /qa 就是要求基于浏览器的测试哪怕 diff 看起来没有 UI 改动也不得建议用 evals、单测等替代方案。qa 专属补充规则11-15干净工作树是前置条件脏则 AskUserQuestion 三选一一修复一提交只在 8e.5 生成回归测试时改测试——绝不改 CI 配置、绝不改既有测试只新建测试文件回归就立刻git revert HEAD遵循 WTF-likelihood 启发式拿不准就停下问。十二、测试佐证与延伸阅读gstack 仓库用 E2E 测试验证该技能的行为边界test/skill-e2e-qa-workflow.test.ts 中qa-quick用例把 qa 目录拷入临时工作区、启动本地测试服务器后让会话读取qa/SKILL.md并跑 Quick 档测试跳过 preamble / telemetry 等运维段落直接走 QA 工作流qa-only-no-fix用例则验证 report-only 路径——值得注意的是它会专门把 qa/templates/qa-report-template.md 复制进沙箱因为 qa-only 技能引用的正是 qa 目录下的模板印证了两个技能共享同一份报告模板资产。另有 test/skill-e2e-qa-bugs.test.ts 专门验证缺陷发现行为。延伸资料缺陷分级与逐页清单qa/references/issue-taxonomy.md报告模板qa/templates/qa-report-template.md浏览器引擎全部命令goto/snapshot/fill/click/console/viewport/upload/dialog等browse/SKILL.mdreport-only 变体qa-only/SKILL.md技能模板源文件SKILL.md 由它自动生成勿直接编辑qa/SKILL.md.tmpl小结gstack 的/qa把测试 → 修复 → 验证压进一条可执行的流程Setup 阶段解决浏览器引擎、工作树清洁度与测试命令三个前置问题四种模式覆盖验分支diff-aware、全量体检Full、冒烟Quick和趋势对比RegressionPhase 1-6 用标注截图 控制台证据 加权健康分建立基线Phase 7-8 在 Tier 约束下做最小修复、原子提交fix(qa): ISSUE-NNN、before/after 复测与回归测试生成并用 WTF-likelihood 计分和 50 次硬上限给 AI 修复行为上保险Phase 9-11 重跑验证、双写报告、回写 TODOS.md最终产出一行可直接进 PR 的 QA found N issues, fixed M, health score X → Y。整条链路的设计重心非常清晰每个结论都要有截图与控制台证据每个修复都要有独立提交与复测每个循环都要有自我刹车。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考