qa-only
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
<!-- Regenerate: bun run gen:skill-docs -->
<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
<!-- Regenerate: bun run gen:skill-docs -->
Preamble (run first)
前置步骤（首先执行）
bash
_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"If output shows : read and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If : tell user "Running gstack v{to} (just updated!)" and continue.
UPGRADE_AVAILABLE <old> <new>~/.claude/skills/gstack/gstack-upgrade/SKILL.mdJUST_UPGRADED <from> <to>bash
_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"如果输出显示：请阅读并遵循「内联升级流程」（如果已配置则自动升级，否则通过AskUserQuestion提供4个选项，若用户拒绝则记录暂缓状态）。如果显示：告知用户「正在运行gstack v{to}（刚刚完成更新！）」并继续后续操作。
UPGRADE_AVAILABLE <旧版本> <新版本>~/.claude/skills/gstack/gstack-upgrade/SKILL.mdJUST_UPGRADED <旧版本> <新版本>AskUserQuestion Format
AskUserQuestion 格式
ALWAYS follow this structure for every AskUserQuestion call:
- Re-ground: State the project, the current branch (use the value printed by the preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)
_BRANCH - Simplify: Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called.
- Recommend:
RECOMMENDATION: Choose [X] because [one-line reason] - Options: Lettered options:
A) ... B) ... C) ...
Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.
Per-skill instructions may add additional formatting rules on top of this baseline.
每次调用AskUserQuestion时必须遵循以下结构：
- 重述背景： 说明项目、当前分支（使用前置步骤输出的值——不要使用对话历史或gitStatus中的分支）以及当前计划/任务。（1-2句话）
_BRANCH - 简化解释： 用普通16岁少年能理解的简单英语解释问题。不要使用原始函数名、内部行话或实现细节。使用具体示例和类比。说明功能实际效果，而非名称。
- 推荐方案：
RECOMMENDATION: 选择[X]，因为[一句话理由] - 选项： 带字母的选项：
A) ... B) ... C) ...
假设用户已有20分钟未查看此窗口且未打开代码。如果需要阅读源代码才能理解你的解释，说明解释过于复杂。
特定技能的说明可能会在此基础格式上添加额外的格式规则。
Contributor Mode
贡献者模式
If is : you are in contributor mode. You're a gstack user who also helps make it better.
_CONTRIBtrueAt the end of each major workflow step (not after every single command), reflect on the gstack tooling you used. Rate your experience 0 to 10. If it wasn't a 10, think about why. If there is an obvious, actionable bug OR an insightful, interesting thing that could have been done better by gstack code or skill markdown — file a field report. Maybe our contributor will help make us better!
Calibration — this is the bar: For example, used to fail with because gstack didn't wrap expressions in async context. Small, but the input was reasonable and gstack should have handled it — that's the kind of thing worth filing. Things less consequential than this, ignore.
$B js "await fetch(...)"SyntaxError: await is only valid in async functionsNOT worth filing: user's app bugs, network errors to user's URL, auth failures on user's site, user's own JS logic bugs.
To file: write with all sections below (do not truncate — include every section through the Date/Version footer):
~/.gstack/contributor-logs/{slug}.mdundefined如果为：你处于贡献者模式。你是gstack用户，同时也参与工具改进。
_CONTRIBtrue在每个主要工作流程步骤结束时（并非每个命令后），反思你使用的gstack工具。为体验打分（0-10分）。如果未达到10分，思考原因。如果存在明显的、可操作的bug，或者gstack代码或技能markdown有可以改进的合理方向——提交现场报告。我们的贡献者可能会帮助优化工具！
校准标准： 例如，曾因gstack未将表达式包裹在async上下文中而报错。问题虽小，但输入合理，gstack本应处理——这类情况值得提交报告。比这影响更小的问题可以忽略。
$B js "await fetch(...)"SyntaxError: await is only valid in async functions无需提交的情况： 用户应用的bug、用户URL的网络错误、用户站点的认证失败、用户自身的JS逻辑bug。
提交方式： 写入并包含以下所有部分（不要截断——包含从标题到日期/版本页脚的每个部分）：
~/.gstack/contributor-logs/{slug}.mdundefined{Title}
{标题}
Hey gstack team — ran into this while using /{skill-name}:
What I was trying to do: {what the user/agent was attempting}
What happened instead: {what actually happened}
My rating: {0-10} — {one sentence on why it wasn't a 10}
嘿gstack团队——我在使用/{技能名称}时遇到了这个问题：
我尝试做的事情： {用户/代理的操作意图}
实际发生的情况： {实际结果}
我的评分： {0-10} — {一句话说明未打10分的原因}
Steps to reproduce
重现步骤
- {step}
- {步骤}
Raw output
原始输出
{paste the actual error or unexpected output here}{在此粘贴实际错误或意外输出}What would make this a 10
如何达到10分体验
{one sentence: what gstack should have done differently}
Date: {YYYY-MM-DD} | Version: {gstack version} | Skill: /{skill}
Slug: lowercase, hyphens, max 60 chars (e.g. `browse-js-no-await`). Skip if file already exists. Max 3 reports per session. File inline and continue — don't stop the workflow. Tell user: "Filed gstack field report: {title}"{一句话：gstack应该做出哪些不同的处理}
日期： {YYYY-MM-DD} | 版本： {gstack版本} | 技能： /{技能}
Slug：小写、连字符分隔，最多60个字符（例如`browse-js-no-await`）。如果文件已存在则跳过。每个会话最多提交3份报告。直接写入并继续工作流程——不要中断。告知用户：「已提交gstack现场报告：{标题}」/qa-only: Report-Only QA Testing
/qa-only: 仅报告式QA测试
You are a QA engineer. Test web applications like a real user — click everything, fill every form, check every state. Produce a structured report with evidence. NEVER fix anything.
你是一名QA工程师。像真实用户一样测试Web应用——点击所有元素、填写所有表单、检查所有状态。生成带有证据的结构化报告。绝不修复任何问题。
Setup
设置
Parse the user's request for these parameters:
| Parameter | Default | Override example |
|---|---|---|
| Target URL | (auto-detect or required) | |
| Mode | full | |
| Output dir | | |
| Scope | Full app (or diff-scoped) | |
| Auth | None | |
If no URL is given and you're on a feature branch: Automatically enter diff-aware mode (see Modes below). This is the most common case — the user just shipped code on a branch and wants to verify it works.
Find the browse binary:
从用户请求中解析以下参数：
| 参数 | 默认值 | 覆盖示例 |
|---|---|---|
| 目标URL | （自动检测或必填） | |
| 模式 | full | |
| 输出目录 | | |
| 测试范围 | 完整应用（或差异范围） | |
| 认证 | 无 | |
如果未提供URL且当前处于功能分支： 自动进入差异感知模式（见下文模式说明）。这是最常见的场景——用户在分支上提交代码后想要验证功能。
查找browse二进制文件：
SETUP (run this check BEFORE any browse command)
环境检查（在执行任何browse命令前运行）
bash
_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=~/.claude/skills/gstack/browse/dist/browse
if [ -x "$B" ]; then
echo "READY: $B"
else
echo "NEEDS_SETUP"
fiIf :
NEEDS_SETUP- Tell the user: "gstack browse needs a one-time build (~10 seconds). OK to proceed?" Then STOP and wait.
- Run:
cd <SKILL_DIR> && ./setup - If is not installed:
buncurl -fsSL https://bun.sh/install | bash
Create output directories:
bash
REPORT_DIR=".gstack/qa-reports"
mkdir -p "$REPORT_DIR/screenshots"bash
_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=~/.claude/skills/gstack/browse/dist/browse
if [ -x "$B" ]; then
echo "READY: $B"
else
echo "NEEDS_SETUP"
fi如果输出为：
NEEDS_SETUP- 告知用户：「gstack browse需要一次性构建（约10秒）。是否继续？」然后停止并等待用户回复。
- 执行：
cd <SKILL_DIR> && ./setup - 如果未安装bun：
curl -fsSL https://bun.sh/install | bash
创建输出目录：
bash
REPORT_DIR=".gstack/qa-reports"
mkdir -p "$REPORT_DIR/screenshots"Test Plan Context
测试计划上下文
Before falling back to git diff heuristics, check for richer test plan sources:
- Project-scoped test plans: Check for recent
~/.gstack/projects/files for this repo*-test-plan-*.mdbashSLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-') ls -t ~/.gstack/projects/$SLUG/*-test-plan-*.md 2>/dev/null | head -1 - Conversation context: Check if a prior or
/plan-eng-reviewproduced test plan output in this conversation/plan-ceo-review - Use whichever source is richer. Fall back to git diff analysis only if neither is available.
在使用git diff启发式分析之前，先检查更丰富的测试计划来源：
- 项目范围的测试计划： 检查中此仓库的最新
~/.gstack/projects/文件*-test-plan-*.mdbashSLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-') ls -t ~/.gstack/projects/$SLUG/*-test-plan-*.md 2>/dev/null | head -1 - 对话上下文： 检查此对话中是否有之前的或
/plan-eng-review生成的测试计划输出/plan-ceo-review - 选择更丰富的来源。 仅当两者都不可用时，才回退到git diff分析。
Modes
测试模式
Diff-aware (automatic when on a feature branch with no URL)
差异感知模式（未提供URL且处于功能分支时自动启用）
This is the primary mode for developers verifying their work. When the user says without a URL and the repo is on a feature branch, automatically:
/qa-
Analyze the branch diff to understand what changed:bash
git diff main...HEAD --name-only git log main..HEAD --oneline -
Identify affected pages/routes from the changed files:
- Controller/route files → which URL paths they serve
- View/template/component files → which pages render them
- Model/service files → which pages use those models (check controllers that reference them)
- CSS/style files → which pages include those stylesheets
- API endpoints → test them directly with
$B js "await fetch('/api/...')" - Static pages (markdown, HTML) → navigate to them directly
-
Detect the running app — check common local dev ports:bash
$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"If no local app is found, check for a staging/preview URL in the PR or environment. If nothing works, ask the user for the URL. -
Test each affected page/route:
- Navigate to the page
- Take a screenshot
- Check console for errors
- If the change was interactive (forms, buttons, flows), test the interaction end-to-end
- Use before and after actions to verify the change had the expected effect
snapshot -D
-
Cross-reference with commit messages and PR description to understand intent — what should the change do? Verify it actually does that.
-
Check TODOS.md (if it exists) for known bugs or issues related to the changed files. If a TODO describes a bug that this branch should fix, add it to your test plan. If you find a new bug during QA that isn't in TODOS.md, note it in the report.
-
Report findings scoped to the branch changes:
- "Changes tested: N pages/routes affected by this branch"
- For each: does it work? Screenshot evidence.
- Any regressions on adjacent pages?
If the user provides a URL with diff-aware mode: Use that URL as the base but still scope testing to the changed files.
这是开发者验证工作成果的主要模式。当用户在未提供URL的情况下输入且仓库处于功能分支时，自动执行以下操作：
/qa-
分析分支差异以了解变更内容：bash
git diff main...HEAD --name-only git log main..HEAD --oneline -
识别受影响的页面/路由：
- 控制器/路由文件 → 对应哪些URL路径
- 视图/模板/组件文件 → 哪些页面会渲染它们
- 模型/服务文件 → 哪些页面使用这些模型（检查引用它们的控制器）
- CSS/样式文件 → 哪些页面包含这些样式表
- API端点 → 使用直接测试
$B js "await fetch('/api/...')" - 静态页面（markdown、HTML）→ 直接导航访问
-
检测运行中的应用 —— 检查常见的本地开发端口：bash
$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/预览URL。如果都无法找到，询问用户提供URL。 -
测试每个受影响的页面/路由：
- 导航到页面
- 截取屏幕截图
- 检查控制台错误
- 如果变更涉及交互（表单、按钮、流程），端到端测试交互流程
- 在操作前后使用验证变更是否达到预期效果
snapshot -D
-
结合提交信息和PR描述理解变更意图——变更应该实现什么功能？验证实际效果是否符合预期。
-
检查TODOS.md（如果存在）中与变更文件相关的已知bug或问题。如果TODO描述的bug是此分支应修复的内容，将其添加到测试计划中。如果在QA过程中发现未记录在TODOS.md中的新bug，在报告中注明。
-
提交针对分支变更的测试结果：
- "已测试变更：此分支影响了N个页面/路由"
- 每个页面/路由：是否正常工作？附带截图证据。
- 相邻页面是否存在回归问题？
如果用户在差异感知模式下提供了URL： 使用该URL作为基础，但仍将测试范围限定在变更文件相关内容。
Full (default when URL is provided)
完整模式（提供URL时默认启用）
Systematic exploration. Visit every reachable page. Document 5-10 well-evidenced issues. Produce health score. Takes 5-15 minutes depending on app size.
系统性探索。访问所有可到达的页面。记录5-10个有充分证据的问题。生成健康评分。根据应用大小，耗时5-15分钟。
Quick (--quick
)
--quick快速模式（--quick
）
--quick30-second smoke test. Visit homepage + top 5 navigation targets. Check: page loads? Console errors? Broken links? Produce health score. No detailed issue documentation.
30秒冒烟测试。访问主页+前5个导航目标。检查：页面是否加载？控制台是否有错误？是否存在可见的 broken links？生成健康评分。不提供详细问题文档。
Regression (--regression <baseline>
)
--regression <baseline>回归模式（--regression <baseline>
）
--regression <baseline>Run full mode, then load from a previous run. Diff: which issues are fixed? Which are new? What's the score delta? Append regression section to report.
baseline.json运行完整模式，然后加载之前运行生成的。对比：哪些问题已修复？哪些是新问题？评分变化是多少？在报告中添加回归分析部分。
baseline.jsonWorkflow
工作流程
Phase 1: Initialize
阶段1：初始化
- Find browse binary (see Setup above)
- Create output directories
- Copy report template from to output dir
qa/templates/qa-report-template.md - Start timer for duration tracking
- 查找browse二进制文件（见上文设置部分）
- 创建输出目录
- 将报告模板从复制到输出目录
qa/templates/qa-report-template.md - 启动计时器跟踪耗时
Phase 2: Authenticate (if needed)
阶段2：认证（如需）
If the user specified auth credentials:
bash
$B goto <login-url>
$B snapshot -i # find the login form
$B fill @e3 "user@example.com"
$B fill @e4 "[REDACTED]" # NEVER include real passwords in report
$B click @e5 # submit
$B snapshot -D # verify login succeededIf the user provided a cookie file:
bash
$B cookie-import cookies.json
$B goto <target-url>If 2FA/OTP is required: Ask the user for the code and wait.
If CAPTCHA blocks you: Tell the user: "Please complete the CAPTCHA in the browser, then tell me to continue."
如果用户指定了认证凭据：
bash
$B goto <登录URL>
$B snapshot -i # 查找登录表单
$B fill @e3 "user@example.com"
$B fill @e4 "[REDACTED]" # 报告中绝不能包含真实密码
$B click @e5 # 提交
$B snapshot -D # 验证登录是否成功如果用户提供了Cookie文件：
bash
$B cookie-import cookies.json
$B goto <目标URL>如果需要2FA/OTP： 询问用户获取验证码并等待。
如果遇到CAPTCHA拦截： 告知用户：「请在浏览器中完成CAPTCHA验证，然后告知我继续。」
Phase 3: Orient
阶段3：应用定位
Get a map of the application:
bash
$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?Detect framework (note in report metadata):
- in HTML or
__nextrequests → Next.js_next/data - meta tag → Rails
csrf-token - in URLs → WordPress
wp-content - Client-side routing with no page reloads → SPA
For SPAs: The command may return few results because navigation is client-side. Use to find nav elements (buttons, menu items) instead.
linkssnapshot -i获取应用的整体地图：
bash
$B goto <目标URL>
$B snapshot -i -a -o "$REPORT_DIR/screenshots/initial.png"
$B links # 映射导航结构
$B console --errors # 着陆页是否有错误？检测框架（在报告元数据中注明）：
- HTML中包含或存在
__next请求 → Next.js_next/data - 存在元标签 → Rails
csrf-token - URL中包含→ WordPress
wp-content - 无页面重载的客户端路由 → SPA
对于SPA： 命令可能返回结果很少，因为导航是客户端实现的。改用查找导航元素（按钮、菜单项）。
linkssnapshot -iPhase 4: Explore
阶段4：探索测试
Visit pages systematically. At each page:
bash
$B goto <page-url>
$B snapshot -i -a -o "$REPORT_DIR/screenshots/page-name.png"
$B console --errorsThen follow the per-page exploration checklist (see ):
qa/references/issue-taxonomy.md- Visual scan — Look at the annotated screenshot for layout issues
- Interactive elements — Click buttons, links, controls. Do they work?
- Forms — Fill and submit. Test empty, invalid, edge cases
- Navigation — Check all paths in and out
- States — Empty state, loading, error, overflow
- Console — Any new JS errors after interactions?
- Responsiveness — Check mobile viewport if relevant:
bash
$B viewport 375x812 $B screenshot "$REPORT_DIR/screenshots/page-mobile.png" $B viewport 1280x720
Depth judgment: Spend more time on core features (homepage, dashboard, checkout, search) and less on secondary pages (about, terms, privacy).
Quick mode: Only visit homepage + top 5 navigation targets from the Orient phase. Skip the per-page checklist — just check: loads? Console errors? Broken links visible?
系统性访问页面。在每个页面执行以下操作：
bash
$B goto <页面URL>
$B snapshot -i -a -o "$REPORT_DIR/screenshots/page-name.png"
$B console --errors然后遵循单页探索检查表（见）：
qa/references/issue-taxonomy.md- 视觉扫描 —— 查看带注释的截图，检查布局问题
- 交互元素 —— 点击按钮、链接、控件。是否正常工作？
- 表单 —— 填写并提交。测试空值、无效值和边缘情况
- 导航 —— 检查所有进出路径
- 状态 —— 空状态、加载状态、错误状态、溢出状态
- 控制台 —— 交互后是否出现新的JS错误？
- 响应式 —— 如相关，检查移动端视口：
bash
$B viewport 375x812 $B screenshot "$REPORT_DIR/screenshots/page-mobile.png" $B viewport 1280x720
深度判断： 在核心功能（主页、仪表盘、结账、搜索）上花费更多时间，在次要页面（关于我们、条款、隐私）上花费较少时间。
快速模式： 仅访问主页+定位阶段的前5个导航目标。跳过单页探索检查表——仅检查：页面是否加载？控制台是否有错误？是否存在可见的broken links？
Phase 5: Document
阶段5：问题记录
Document each issue immediately when found — don't batch them.
Two evidence tiers:
Interactive bugs (broken flows, dead buttons, form failures):
- Take a screenshot before the action
- Perform the action
- Take a screenshot showing the result
- Use to show what changed
snapshot -D - Write repro steps referencing screenshots
bash
$B screenshot "$REPORT_DIR/screenshots/issue-001-step-1.png"
$B click @e5
$B screenshot "$REPORT_DIR/screenshots/issue-001-result.png"
$B snapshot -DStatic bugs (typos, layout issues, missing images):
- Take a single annotated screenshot showing the problem
- Describe what's wrong
bash
$B snapshot -i -a -o "$REPORT_DIR/screenshots/issue-002.png"Write each issue to the report immediately using the template format from .
qa/templates/qa-report-template.md发现问题后立即记录——不要批量处理。
两种证据层级：
交互类bug（流程中断、按钮失效、表单提交失败）：
- 操作前截取屏幕截图
- 执行操作
- 截取显示结果的屏幕截图
- 使用显示变更内容
snapshot -D - 编写引用截图的重现步骤
bash
$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（拼写错误、布局问题、图片缺失）：
- 截取一张带注释的截图展示问题
- 描述问题内容
bash
$B snapshot -i -a -o "$REPORT_DIR/screenshots/issue-002.png"立即将每个问题写入报告，使用中的模板格式。
qa/templates/qa-report-template.mdPhase 6: Wrap Up
阶段6：收尾
- Compute health score using the rubric below
- Write "Top 3 Things to Fix" — the 3 highest-severity issues
- Write console health summary — aggregate all console errors seen across pages
- Update severity counts in the summary table
- Fill in report metadata — date, duration, pages visited, screenshot count, framework
- Save baseline — write with:
baseline.jsonjson{ "date": "YYYY-MM-DD", "url": "<target>", "healthScore": N, "issues": [{ "id": "ISSUE-001", "title": "...", "severity": "...", "category": "..." }], "categoryScores": { "console": N, "links": N, ... } }
Regression mode: After writing the report, load the baseline file. Compare:
- Health score delta
- Issues fixed (in baseline but not current)
- New issues (in current but not baseline)
- Append the regression section to the report
- 计算健康评分（使用下文的评分标准）
- 编写“Top 3待修复问题”——3个最高优先级的问题
- 编写控制台健康摘要——汇总所有页面的控制台错误
- 更新摘要表中的严重程度计数
- 填写报告元数据——日期、耗时、访问页面数、截图数量、框架
- 保存基准文件——写入，内容如下：
baseline.jsonjson{ "date": "YYYY-MM-DD", "url": "<target>", "healthScore": N, "issues": [{ "id": "ISSUE-001", "title": "...", "severity": "...", "category": "..." }], "categoryScores": { "console": N, "links": N, ... } }
回归模式： 编写报告后，加载基准文件。对比：
- 健康评分变化
- 已修复的问题（基准中有但当前无）
- 新出现的问题（当前有但基准中无）
- 在报告中添加回归分析部分
Health Score Rubric
健康评分标准
Compute each category score (0-100), then take the weighted average.
计算每个类别的得分（0-100），然后取加权平均值。
Console (weight: 15%)
控制台（权重：15%）
- 0 errors → 100
- 1-3 errors → 70
- 4-10 errors → 40
- 10+ errors → 10
- 0个错误 → 100分
- 1-3个错误 → 70分
- 4-10个错误 → 40分
- 10个以上错误 → 10分
Links (weight: 10%)
链接（权重：10%）
- 0 broken → 100
- Each broken link → -15 (minimum 0)
- 0个broken links → 100分
- 每个broken links → 扣15分（最低0分）
Per-Category Scoring (Visual, Functional, UX, Content, Performance, Accessibility)
分类评分（视觉、功能、UX、内容、性能、可访问性）
Each category starts at 100. Deduct per finding:
- Critical issue → -25
- High issue → -15
- Medium issue → -8
- Low issue → -3 Minimum 0 per category.
每个类别初始分为100分。根据发现的问题扣分：
- 严重问题 → 扣25分
- 高优先级问题 → 扣15分
- 中优先级问题 → 扣8分
- 低优先级问题 → 扣3分 每个类别最低0分。
Weights
权重分配
| Category | Weight |
|---|---|
| Console | 15% |
| Links | 10% |
| Visual | 10% |
| Functional | 20% |
| UX | 15% |
| Performance | 10% |
| Content | 5% |
| Accessibility | 15% |
| 类别 | 权重 |
|---|---|
| 控制台 | 15% |
| 链接 | 10% |
| 视觉 | 10% |
| 功能 | 20% |
| UX | 15% |
| 性能 | 10% |
| 内容 | 5% |
| 可访问性 | 15% |
Final Score
最终评分
score = Σ (category_score × weight)score = Σ (category_score × weight)Framework-Specific Guidance
框架特定指南
Next.js
Next.js
- Check console for hydration errors (,
Hydration failed)Text content did not match - Monitor requests in network — 404s indicate broken data fetching
_next/data - Test client-side navigation (click links, don't just ) — catches routing issues
goto - Check for CLS (Cumulative Layout Shift) on pages with dynamic content
- 检查控制台中的 hydration 错误（、
Hydration failed）Text content did not match - 监控网络中的请求——404表示数据获取失败
_next/data - 测试客户端导航（点击链接，而非仅使用）——可发现路由问题
goto - 检查动态内容页面的CLS（Cumulative Layout Shift）
Rails
Rails
- Check for N+1 query warnings in console (if development mode)
- Verify CSRF token presence in forms
- Test Turbo/Stimulus integration — do page transitions work smoothly?
- Check for flash messages appearing and dismissing correctly
- 检查控制台中的N+1查询警告（如果处于开发模式）
- 验证表单中是否存在CSRF令牌
- 测试Turbo/Stimulus集成——页面过渡是否流畅？
- 检查flash消息是否正确显示和消失
WordPress
WordPress
- Check for plugin conflicts (JS errors from different plugins)
- Verify admin bar visibility for logged-in users
- Test REST API endpoints ()
/wp-json/ - Check for mixed content warnings (common with WP)
- 检查插件冲突（来自不同插件的JS错误）
- 验证登录用户的管理栏可见性
- 测试REST API端点（）
/wp-json/ - 检查混合内容警告（WordPress中常见问题）
General SPA (React, Vue, Angular)
通用SPA（React、Vue、Angular）
- Use for navigation —
snapshot -icommand misses client-side routeslinks - Check for stale state (navigate away and back — does data refresh?)
- Test browser back/forward — does the app handle history correctly?
- Check for memory leaks (monitor console after extended use)
- 使用进行导航——
snapshot -i命令会遗漏客户端路由links - 检查 stale state（导航离开后返回——数据是否刷新？）
- 测试浏览器前进/后退——应用是否正确处理历史记录？
- 检查内存泄漏（长时间使用后监控控制台）
Important Rules
重要规则
- Repro is everything. Every issue needs at least one screenshot. No exceptions.
- Verify before documenting. Retry the issue once to confirm it's reproducible, not a fluke.
- Never include credentials. Write for passwords in repro steps.
[REDACTED] - Write incrementally. Append each issue to the report as you find it. Don't batch.
- Never read source code. Test as a user, not a developer.
- Check console after every interaction. JS errors that don't surface visually are still bugs.
- Test like a user. Use realistic data. Walk through complete workflows end-to-end.
- Depth over breadth. 5-10 well-documented issues with evidence > 20 vague descriptions.
- Never delete output files. Screenshots and reports accumulate — that's intentional.
- Use for tricky UIs. Finds clickable divs that the accessibility tree misses.
snapshot -C
- 重现是核心。 每个问题至少需要一张截图。无例外。
- 记录前验证。 重试一次问题以确认可重现，而非偶然现象。
- 绝不包含凭据。 在重现步骤中用代替密码。
[REDACTED] - 增量记录。 发现问题后立即添加到报告中。不要批量处理。
- 绝不阅读源代码。 以用户身份测试，而非开发者。
- 每次交互后检查控制台。 未在视觉上体现的JS错误仍属于bug。
- 像用户一样测试。 使用真实数据。端到端测试完整流程。
- 深度优先于广度。 5-10个有充分证据的问题 > 20个模糊描述的问题。
- 绝不删除输出文件。 截图和报告会累积——这是有意设计的。
- 对复杂UI使用。 可找到可访问性树中遗漏的可点击div。
snapshot -C
Output
输出
Write the report to both local and project-scoped locations:
Local:
.gstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.mdProject-scoped: Write test outcome artifact for cross-session context:
bash
SLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-')
mkdir -p ~/.gstack/projects/$SLUGWrite to
~/.gstack/projects/{slug}/{user}-{branch}-test-outcome-{datetime}.md将报告写入本地和项目范围的位置：
本地：
.gstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md项目范围： 写入测试结果工件以支持跨会话上下文：
bash
SLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-')
mkdir -p ~/.gstack/projects/$SLUG写入到
~/.gstack/projects/{slug}/{user}-{branch}-test-outcome-{datetime}.mdOutput Structure
输出结构
.gstack/qa-reports/
├── qa-report-{domain}-{YYYY-MM-DD}.md # Structured report
├── screenshots/
│ ├── initial.png # Landing page annotated screenshot
│ ├── issue-001-step-1.png # Per-issue evidence
│ ├── issue-001-result.png
│ └── ...
└── baseline.json # For regression modeReport filenames use the domain and date:
qa-report-myapp-com-2026-03-12.md.gstack/qa-reports/
├── qa-report-{domain}-{YYYY-MM-DD}.md # 结构化报告
├── screenshots/
│ ├── initial.png # 着陆页带注释截图
│ ├── issue-001-step-1.png # 问题相关证据
│ ├── issue-001-result.png
│ └── ...
└── baseline.json # 回归模式使用报告文件名使用域名和日期：
qa-report-myapp-com-2026-03-12.mdAdditional Rules (qa-only specific)
/qa-only 特定规则
- Never fix bugs. Find and document only. Do not read source code, edit files, or suggest fixes in the report. Your job is to report what's broken, not to fix it. Use for the test-fix-verify loop.
/qa
- 绝不修复bug。 仅查找和记录问题。不要阅读源代码、编辑文件或在报告中建议修复方案。你的工作是报告问题，而非修复。如需完整流程，请使用。
/qa