gstack 中 /qa-only 只报告型 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/gstackgstack 用 23 个角色化技能覆盖了从产品规划到发布的全流程其中/qa-only是 QA 环节里一个边界极其清晰的技能像真实用户一样系统性地测试 Web 应用产出带健康分Health Score、截图证据和复现步骤的结构化报告但绝不修改任何代码。本文基于 qa-only/SKILL.md 这一技能文件本身结合 gstack 仓库中的 browse 浏览器 CLI 源码、QA 报告模板、问题分类法和 E2E 测试用例完整拆解它的参数体系、四种测试模式、六阶段工作流、健康分量表与框架专项检测策略读完你可以理解这套只测不修的 Agent 化 QA 流程是如何被设计成可复现、可回归、可审计的。技能定位报告与修复的严格分界/qa-only的 frontmatter 定义如下见 qa-only/SKILL.md 第 1-16 行name: qa-only preamble-tier: 4 version: 1.0.0 description: Report-only QA testing. (gstack) allowed-tools: - Bash - Read - Write - AskUserQuestion - WebSearch triggers: - qa report only - just report bugs - test but dont fix几个值得注意的设计点触发词即契约triggers中的三个短语qa report only、just report bugs、test but dont fix以及语音触发别名bug report、just check for bugs精确框定了使用场景——用户要的是一份 bug 报告而不是代码变更。工具白名单allowed-tools里没有Edit、Glob、Grep只有 Bash/Read/Write 等。对比完整闭环版 qa/SKILL.md后者额外开放了Edit、Glob、Grep——从源码结构看这正是绝不修复这一约束在工具权限层面的落地/qa-only在工具集上就不具备编辑能力。与 /qa 的分工/qa是 Test → Fix → Verify 循环测试、原子提交修复、再验证分 Quick/Standard/Exhaustive 三档/qa-only则把循环砍到测试与报告为止。技能文档中的 Additional Rules 第 11 条写得很直白Never fix bugs. Find and document only. Do not read source code, edit files, or suggest fixes in the report.启动参数五个可解析的入口/qa-only从用户的自然语言请求中解析以下参数原文 Setup 章节的完整参数表ParameterDefaultOverride exampleTarget URL(auto-detect or required)https://myapp.com,http://localhost:3000Modefull--quick,--regression .gstack/qa-reports/baseline.jsonOutput dir.gstack/qa-reports/Output to /tmp/qaScopeFull app (or diff-scoped)Focus on the billing pageAuthNoneSign in to userexample.com,Import cookies from cookies.json其中一条隐含路由规则是最高频的使用场景如果用户没给 URL 且当前处于 feature 分支自动进入 diff-aware 模式。文档的解释是用户刚在分支上提交了代码想验证它是否工作——这恰好是开发工作流里最常见的 QA 诉求。browse 二进制的发现逻辑所有浏览器操作都通过 gstack 自带的 browse CLI下文记作$B完成。技能要求在任何 browse 命令之前先执行如下检查_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逻辑是优先用仓库内.claude/skills/gstack/browse/dist/browsevendored 副本否则回退到全局安装路径~/.claude/skills/gstack/browse/dist/browse。若输出NEEDS_SETUP技能会先询问用户gstack browse 需要一次性构建约 10 秒是否继续然后执行cd SKILL_DIR ./setup若bun未安装会下载官方安装脚本并校验 SHA-256 校验和脚本内固定了BUN_VERSION与BUN_INSTALL_SHA校验失败直接报错退出。确认就绪后创建输出目录REPORT_DIR.gstack/qa-reports mkdir -p $REPORT_DIR/screenshots前置学习让 QA 会话站在过去之上进入正式测试前/qa-only会做一次先验学习检索_CROSS_PROJ$(~/.claude/skills/gstack/bin/gstack-config get cross_project_learnings 2/dev/null || echo unset) echo CROSS_PROJECT: $_CROSS_PROJ if [ $_CROSS_PROJ true ]; then ~/.claude/skills/gstack/bin/gstack-learnings-search --limit 10 --cross-project 2/dev/null || true else ~/.claude/skills/gstack/bin/gstack-learnings-search --limit 10 2/dev/null || true ficross_project_learnings首次使用时通过 AskUserQuestion 询问默认建议开启文档同时提示多客户代码库场景下为避免交叉污染应跳过。若检索到与当前发现匹配的历史学习报告中需显式展示Prior learning applied: [key] (confidence N/10, from [date])——这是 gstack 经验复利设计的一个可见性钩子让用户看到系统在自己的代码库上持续变强。测试计划上下文先查更丰富的信息源在回退到 git diff 启发式之前技能要求按优先级检查两类更丰富的测试计划来源项目级测试计划检查~/.gstack/projects/下本仓库最近的*-test-plan-*.md文件setopt o nomatch 2/dev/null || true # zsh compat eval $(~/.claude/skills/gstack/bin/gstack-slug 2/dev/null) ls -t ~/.gstack/projects/$SLUG/*-test-plan-*.md 2/dev/null | head -1会话上下文检查此前/plan-eng-review或/plan-ceo-review是否已在当前对话中产出测试计划。规则是用更丰富的那个只有两者都没有时才回退到 git diff 分析。四种模式diff-aware、Full、Quick、RegressionDiff-awarefeature 分支无 URL 时自动启用这是验证开发工作的主模式共七步分析分支差异git diff main...HEAD --name-only git log main..HEAD --oneline从变更文件推断受影响的页面/路由映射规则明确Controller/route 文件 → 其服务的 URL 路径View/template/component 文件 → 渲染它们的页面Model/service 文件 → 引用这些 model 的 controller 所对应的页面CSS/style 文件 → 引入这些样式表的页面API 端点 → 用$B js await fetch(/api/...)直接测静态页面markdown、HTML→ 直接导航访问有一条明确的兜底规则即使 diff 中看不出任何页面/路由也不得跳过浏览器测试。因为用户调用 /qa 就是要浏览器级验证此时回退到 Quick 模式——访问首页、走前 5 个导航目标、查 console 错误、测交互元素。后端、配置和基础设施的变更都会影响应用行为——永远要验证应用还能工作。探测运行中的应用依次尝试本地常用端口$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。逐个测试受影响页面导航 → 截图 → 查 console若变更是交互式的表单、按钮、流程则端到端测试交互在动作前后各用一次snapshot -D验证变更确实产生了预期效果。交叉比对 commit 信息与 PR 描述理解意图——这次改动应该做什么验证它确实做到了。检查 TODOS.md若存在中变更文件相关的已知问题若 TODO 描述了本分支应当修复的 bug加入测试计划QA 中新发现的 bug 若不在 TODOS.md 里写入报告。输出以分支变更为准的报告Changes tested: N pages/routes affected by this branch每个附截图证据并检查相邻页面有无回归。若用户在 diff-aware 模式下提供了 URL则以该 URL 为基址但测试范围仍限定在变更文件上。Full提供 URL 时的默认模式系统性探索访问所有可达页面记录 5-10 个证据充分的 issue产出健康分。文档给出的时间预期是 5-15 分钟取决于应用规模。Quick--quick30 秒冒烟测试访问首页 前 5 个导航目标只检查三件事——页面能加载吗有 console 错误吗有可见的断链吗产出健康分不做逐 issue 的详细记录。Regression--regression baseline先跑 full 模式再加载上一次运行生成的baseline.json做三类对比哪些 issue 被修复了哪些是新出现的健康分变化多少然后把回归小节追加到报告末尾。六阶段工作流Phase 1: Initialize定位 browse 二进制见上文创建输出目录从 qa/templates/qa-report-template.md 复制报告模板到输出目录——注意这是跨技能复用/qa-only直接引用qa/目录下的模板文件启动计时器用于时长统计。Phase 2: Authenticate如需要用户给了登录凭据时标准操作序列是$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注意e3、e4这类引用它们来自snapshot输出的可访问性树见 browse/src/commands.ts 中 snapshot 的用法说明 Flags: -i interactive only, ... -D diff vs previous, -a annotated screenshot, -o path output, -C cursor-interactive c refs即快照后按e1、e2… 引用元素进行填充和点击。Cookie 文件$B cookie-import cookies.json后直接goto目标页cookie-import在 browse CLI 中的定义为 Import cookies from JSON file2FA/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.jscsrf-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视觉扫描— 看标注截图找布局问题交互元素— 点击每个按钮、链接、控件行为符合预期吗表单— 填写并提交测空值、非法值、边界长文本、特殊字符导航— 检查进出路径面包屑、返回按钮、深链、移动菜单状态— 空状态、加载态、错误态、溢出态Console— 交互后有无新的 JS 错误响应式— 如相关检查移动视口$B viewport 375x812 $B screenshot $REPORT_DIR/screenshots/page-mobile.png $B viewport 1280x720browse CLI 中viewport的用法为viewport [WxH] [--scale n]responsive子命令则会一次性产出 375x812 / 768x1024 / 1280x720 三档截图深度判断核心功能首页、dashboard、结账、搜索多花时间次级页面about、terms、privacy少花时间。Quick 模式只访问首页 Orient 阶段的前 5 个导航目标跳过逐页清单。Phase 5: Document发现即记录不许攒批。文档区分两个证据等级交互式 bug流程中断、死按钮、表单失败——五步证据链$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每个 issue 发现后立即按模板格式写入报告。Phase 6: Wrap Up按下文量表计算健康分写Top 3 Things to Fix三个最高严重度 issue写console 健康汇总跨页面聚合所有 console 错误;更新汇总表中的严重度计数填报告元数据——日期、时长、访问页数、截图数、框架保存基线写出baseline.json{ date: YYYY-MM-DD, url: target, healthScore: N, issues: [{ id: ISSUE-001, title: ..., severity: ..., category: ... }], categoryScores: { console: N, links: N, ... } }Regression 模式下写完报告后加载基线文件对比健康分差值、已修复 issue基线有而当前没有、新增 issue当前有而基线没有并把回归小节追加到报告。健康分量表可复现的质量度量健康分是/qa-only报告的核心量化输出。先算每个类别分0-100再加权平均Console权重 15%0 个错误 → 1001-3 个错误 → 704-10 个错误 → 4010 个错误 → 10Links权重 10%0 个断链 → 100每多一个断链 → -15下限 0其余类别Visual / Functional / UX / Content / Performance / Accessibility每类从 100 起步按发现扣分严重度扣分Critical issue-25High issue-15Medium issue-8Low issue-3每类下限 0。权重表CategoryWeightConsole15%Links10%Visual10%Functional20%UX15%Performance10%Content5%Accessibility15%最终分score Σ (category_score × weight)。这套量表的意义在于让这次比上次好/坏了变成可比较的数字——也正是baseline.json回归对比的输入。严重度与问题分类法报告的 issue 记录遵循 qa/references/issue-taxonomy.md 中的分类体系。严重度四级Severity定义例子critical阻塞核心流程、导致数据丢失或应用崩溃表单提交触发错误页、结账流程中断、数据被无确认删除high主要功能损坏且无替代方案搜索结果错误、文件上传静默失败、认证重定向循环medium功能可用但问题明显有变通方式页面加载慢5s、缺校验但能提交、仅移动端布局破损low轻微外观/打磨问题页脚错别字、1px 对齐问题、hover 状态不一致七大类别各自给出具体清单Visual/UI元素重叠、图片缺失、z-index 错误、暗色模式问题…、Functional断链、死按钮、校验被绕过、状态不持久、竞态条件…、UX无加载指示器、500ms 无反馈、破坏性操作无确认…、Content占位文本残留、文案截断、空状态缺失…、Performance3s 加载、单页 50 个网络请求、阻塞 JS…、Console/Errors未捕获异常、4xx/5xx、CORS、混合内容、CSP 违规…、Accessibility图片缺 alt、表单无标签、焦点陷阱、对比度不足…。框架专项检测策略技能对不同技术栈给出了针对性的检查点这部分直接体现了像用户一样测但懂框架的折中Next.js检查 console 里的 hydration 错误Hydration failed、Text content did not match监控_next/data请求——404 意味着数据获取断裂测客户端导航点链接而不是只goto——能抓到路由问题检查动态内容页的 CLS累积布局偏移Rails开发模式下检查 N1 查询告警验证表单中的 CSRF token 存在测 Turbo/Stimulus 集成——页面切换是否顺滑检查 flash 消息正确出现与消失WordPress插件冲突来自不同插件的 JS 错误登录用户的管理工具条可见性测试 REST API 端点/wp-json/混合内容告警WP 上常见通用 SPAReact/Vue/Angular用snapshot -i做导航——links命令会漏掉客户端路由检查状态过期离开再回来——数据刷新了吗测浏览器前进/后退——历史处理正确吗监控长时间使用后的 console排查内存泄漏十二条铁律Important Rules/qa-only的 Important Rules 章节是整个技能的行为底线逐条继承如下Repro is everything.每个 issue 至少一张截图没有例外。Verify before documenting.重试一次确认可复现而非偶发。Never include credentials.复现步骤中密码一律写[REDACTED]。Write incrementally.发现即追加不攒批。Never read source code.以用户而非开发者的身份测试。Check console after every interaction.不显现的 JS 错误同样是 bug。Test like a user.用真实数据端到端走完整流程。Depth over breadth.5-10 个带证据的 issue 好过 20 条模糊描述。Never delete output files.截图和报告只增不删——有意为之。Usesnapshot -Cfor tricky UIs.可找到可访问性树漏掉的 clickable div对应 browse 源码中-C cursor-interactive c refs标志。Show screenshots to the user.每次$B screenshot、$B snapshot -a -o或$B responsive之后用 Read 工具读回输出文件让用户内联可见——没有这一步截图对用户是不可见的。Never refuse to use the browser.用户调用了 /qa 或 /qa-only 就是要求浏览器级测试不得用 evals、单测等替代方案搪塞即使 diff 看起来没有 UI 变更后端变更也影响应用行为——始终开浏览器测。输出双位置报告与目录结构报告写入两处本地随项目.gstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md项目作用域跨会话eval $(~/.claude/skills/gstack/bin/gstack-slug 2/dev/null) mkdir -p ~/.gstack/projects/$SLUG写入~/.gstack/projects/{slug}/{user}-{branch}-test-outcome-{datetime}.md作为跨会话上下文供 Context Recovery 阶段恢复。目录结构.gstack/qa-reports/ ├── qa-report-{domain}-{YYYY-MM-DD}.md # 结构化报告 ├── screenshots/ │ ├── initial.png # 落地页标注截图 │ ├── issue-001-step-1.png # 逐 issue 证据 │ ├── issue-001-result.png │ └── ... └── baseline.json # 回归模式用报告文件名以域名 日期命名如qa-report-myapp-com-2026-03-12.md。报告本体使用 qa/templates/qa-report-template.md模板包含元数据表日期、URL、分支、commit、PR、Tier、Scope、时长、访问页数、截图数、框架、健康分分类表、Top 3 Things to Fix、Console Health 表、按严重度统计的 Summary 表、逐 issue 记录严重度/类别/URL/描述/带截图的复现步骤以及/qa才用到的 Fixes Applied / Regression Tests / Ship Readiness 小节——/qa-only的报告不含已修复部分这正是两者输出形态的分界。会话学习结束时的经验沉淀测试完成后若有非显而易见的模式、陷阱或架构洞察记录给未来会话~/.claude/skills/gstack/bin/gstack-learnings-log {skill:qa-only,type:TYPE,key:SHORT_KEY,insight:DESCRIPTION,confidence:N,source:SOURCE,files:[path/to/relevant/file]}typepattern可复用方法、pitfall不该做的、preference用户声明的、architecture结构性决策、tool库/框架洞察、operational项目环境/CLI/流程知识sourceobserved在代码中发现、user-stated用户告知、inferredAI 推断、cross-modelClaude 与 Codex 一致同意confidence1-10。代码里验证过的 observed 模式是 8-9不确定的推断是 4-5用户明确声明的偏好是 10files附带该学习引用的具体文件路径用于过期检测——文件被删除时学习可被标记为失效记录标准是这个洞察未来能省时间吗能才记。测试保障E2E 用例如何验证绝不修复gstack 仓库用真实 E2E 测试看护这一约束。test/skill-e2e-qa-workflow.test.ts 中的QA-Only skill E2E套件用例 IDqa-only-no-fix把qa-only/目录和qa/模板复制到临时工作区、初始化 git 仓库因为 qa-only 在 diff-aware 模式下会检查 feature 分支然后让模型执行报告工作流并写入qa-reports/qa-only-report.md。测试名no-fix本身就揭示了断言核心运行期间若模型调用了 Edit 工具qa-only used Edit tool: N times 的告警即来源于此说明只报告不修复的边界被突破。这类测试与 test/skill-coverage-matrix.ts、test/skill-routing-e2e.test.ts 一起构成对技能触发词 → 行为约束链条的持续回归。qa-only 专属的两条补充规则技能末尾的 Additional Rules (qa-only specific) 只有两条但都指向它的独特定位Never fix bugs.只发现和记录。不读源码、不改文件、不在报告里给修复建议。报告坏了什么不是修好它。要修复请用/qa。No test framework detected?若项目没有测试基础设施无测试配置文件、无测试目录在报告 summary 中写入No test framework detected. Run/qato bootstrap one and enable regression test generation.——/qa具备测试框架引导bootstrap能力/qa-only只负责把这个缺口报出来。运行前提与小结使用/qa-only的前提与边界gstack 已安装默认位于~/.claude/skills/gstack/browse 二进制首次使用前需一次性构建约 10 秒依赖 bun技能运行在preamble-tier: 4的共享 preamble 之下更新检查、会话状态、遥测开关、Artifacts Sync 等这些与 QA 逻辑本身无关属于 gstack 技能的通用运行框架技能不读源码、不改文件、不输出修复建议——这是设计约束而非能力缺失对应的完整闭环由 qa/SKILL.md 承担。概括来说/qa-only把测试一个 Web 应用这件事拆成了可被 Agent 逐步执行的确定性流程参数解析与模式路由diff-aware / full / quick / regression→ 基于 browse CLI 的认证与定向 → 逐页探索清单 → 双证据等级的问题记录 → 加权健康分与基线回归 → 双位置报告输出与经验沉淀。它的工程价值在于每个步骤都有可复制的命令、每张截图都有命名规范、每个分数都有量表可复算、每条约束都有 E2E 测试看护——像真实用户一样测试这一模糊要求由此变成了一份可审计的契约。【免费下载链接】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），仅供参考