// TestSpec 用例评审（流程第 5 步）- 对生成的测试用例做 14 维度交叉验证（R1-R6 规则检查 + H1-H8 启发式检查），产出 review-report.md 评审报告。当用户要「评审用例」「检查用例质量」「审查测试用例」或执行 testspec-review / testspec review 时使用。也适用于用户说「用例写完了帮我看看」「检查一下覆盖度」「用例有没有问题」的场景。支持默认模式和 --deep 深度模式。
TestSpec 需求分析和梳理（流程第 2 步）- 对需求做深度测试分析，运用等价类、边界值、状态迁移等方法，产出 requirements-analysis.md。当用户要「分析需求」「梳理测试点」「做需求分析」「拆解可测项」或执行 testspec-analysis / testspec analysis 时使用。也适用于用户说「这个 PRD 有哪些要测的」「帮我分析一下测试范围」「需求评审准备」的场景。注意：如果用户要的是简短的测试点清单而非深度分析，应使用 testspec-points。
TestSpec 生成测试用例（流程第 4 步）- 根据测试点（specs/*.md）生成完整测试用例并导出 Excel (.xlsx) 或 XMind (.xmind) 格式。当用户要「生成用例」「写测试用例」「导出 Excel」「导出 XMind」「生成测试用例表格」或执行 testspec-generate / testspec generate 时使用。也适用于用户说「把测试点展开成用例」「帮我出一份测试用例表」「生成 Excel 测试文档」的场景。使用内置 Python 脚本完成 Excel/XMind 文件生成，不依赖外部技能。
TestSpec 新建测试工作（流程第 1 步）- 创建测试变更目录，编写 proposal.md，并在用户提供已有 PRD/需求片段时净化成可验收的 requirements.md。当用户要「新建测试」「开始测试」「创建测试变更」「建一个测试项目」或执行 testspec-new / testspec new 时使用。也适用于用户说「我要测 XXX 功能」「帮我准备测试」「有个新需求要测」「帮我整理/审查 PRD」的场景——如果尚无 testspec/changes/ 目录，这是流程的起点。产出 testspec/changes/<name>/ 目录结构、proposal.md，必要时产出 requirements.md。
TestSpec 测试点（流程第 3 步）- 从需求分析中提炼「要测什么」的简短要点清单，产出 specs/testpoints.md。当用户要「写测试点」「提取测试要点」「列出要验证的内容」或执行 testspec-points / testspec points 时使用。也适用于用户说「这个功能要测哪些点」「帮我列测试清单」的场景。与测试用例区分：测试点只列验证目标（What），不写操作步骤（How）。产出供 testspec-generate 展开为完整测试用例。
TestSpec 需求源更新与口径收敛（可重复执行的轻量 rebaseline）- 当已有 testspec/changes/<name>/ 后，用户补充、修改、删除、澄清、替换 PRD、接口文档、UI 图、原型图、产品回答、验收规则、权限规则、时间口径、收益映射、字段说明或需求范围时使用。适用于「产品改需求了」「补充接口文档」「新增 UI 图」「删掉这个需求」「同步最新 PRD」「口径收敛」「更新 requirements」「标记旧 analysis 过期」「用例写完后需求变了」「testspec-update / testspec update」。产出更新后的上游需求源、变更影响摘要、blocking_open_questions/dynamic_followups 分类，并标记 stale 下游产物。
Static Android app reverse-analysis workflow for exporting APKs from ADB, handling split APKs, decompiling with JADX/apktool/Vineflower, inventorying static artifacts, detecting packers, extracting API endpoints, and producing evidence-labeled reports. Use when the user asks to reverse engineer, decompile, inspect APKs, pull installed apps, dump packages, run jadx/apktool/smali/vineflower/dex2jar, analyze /tmp APK or JADX outputs, detect Android packers/native code, extract Retrofit/OkHttp/Volley/custom HTTP endpoints, find leaked static secrets, trace Android call flows, or says '用jadx逆向', '从手机导出安装包', '提取接口', '查包名并反编译', '检测加固', '提取泄露'.
| name | testspec-review |
| description | TestSpec 用例评审（流程第 5 步）- 对生成的测试用例做 14 维度交叉验证（R1-R6 规则检查 + H1-H8 启发式检查），产出 review-report.md 评审报告。当用户要「评审用例」「检查用例质量」「审查测试用例」或执行 testspec-review / testspec review 时使用。也适用于用户说「用例写完了帮我看看」「检查一下覆盖度」「用例有没有问题」的场景。支持默认模式和 --deep 深度模式。 |
IRON LAW: Every review finding must name the failing case_id or TP_ID and a concrete fix.
TestSpec Review Progress:
- [ ] Step 1: Locate current change directory ⚠️ REQUIRED
- [ ] Step 2: Load required inputs and run health check ⛔ BLOCKING
- [ ] Step 3: Decide Strict/Legacy and review depth
- [ ] Step 4: Execute R1-R6 and H1-H8 checks
- [ ] Step 5: Write review-report.md with evidence
- [ ] Step 6: Seed feedback context and report next step
只给可执行、可定位、可修复的结论：每条问题必须指向具体 case_id 或 TP_ID，并给出明确整改动作。
以独立评审视角，对测试用例做 14 维度交叉验证，输出结构化 review-report.md，并为上游 skill 提供可落地的反馈闭环。
参见 ../_testspec-shared/references/common.md 中的「当前变更目录定位规则」。
review-report-template.mdreferences/review-dimensions.md../_testspec-shared/references/context-protocol.md默认执行 auto 模式：Agent 先判断复杂度和风险，再决定标准深度或加深深度。
auto（默认）：按信号自动选择--deep（显式）：强制加深深度，不再降级触发加深检查：
schema_version: 2 且 tp_refs 完整）material_quality = lowrisks_identified 非空blocking_open_questions 非空可保持标准深度：
material_quality = highrequirements-analysis.md，H3 对所有 TP 全解释，H5 最低覆盖类型要求提高到 3评审开始时必须向用户说明当前深度及理由。
testcases.json（变更目录根目录或 artifacts/ 下）specs/testpoints.mdrequirements-analysis.md（--deep 或 auto 加深时建议读取）testcases.json 存在且可解析testcases 数组且非空specs/testpoints.md 存在且包含 TP_IDstale_downstream_artifacts 命中 testcases.json 或 review-report.md，终止并提示先运行对应 next_skill 或上游 skill rebaselinesource_revision.version 高于 testcases.json context 记录的版本（或 testcases.json 缺少 source_revision），终止并提示上游已更新、需先重跑上游 skill若失败：终止评审并提示先补齐上游产物（testspec-generate 或 testspec-points）。
schema_version: 2 且所有用例有非空 tp_refsLegacy 模式仍可评审，但 R6/H3 置信度下调，并在报告中明确升级建议。
执行细则、判定阈值和输出字段见 references/review-dimensions.md。本文件只保留最小执行索引。
S1 只用于真正阻断问题，禁止滥用。
references/review-dimensions.mdreview-report-template.md 填写全部结果review-report.md 至少包含：
| 反模式 | 表现 | 修正 |
|---|---|---|
| 走形式检查 | 全部“通过”但无证据 | 每项至少给 1 个量化指标 |
| 模糊建议 | “建议优化”“需要改进” | 明确到字段和修改动作 |
| 遗漏 ID | 问题无 case_id/TP_ID | 所有问题绑定具体实体 |
| 比例至上 | 只看占比不看内容 | 先核实关键场景是否真实覆盖 |
| 忽视上游 | 不消费风险/阻塞澄清信息 | 强制读取上游 context |
| 过度报告 | 把细节问题都标 S1 | 严格按分级定义降噪 |
评审完成后必须给出三类结构化反馈：
id、title、steps、expected_result、tp_refs 等）在 review-report.md 末尾按 ../_testspec-shared/references/context-protocol.md 写入：
<!-- testspec-context
{
"source_skill": "testspec-review",
"risks_identified": ["<评审中新发现的风险>"],
"feedback_for_generate": ["<给 generate 的结构化反馈>"],
"feedback_for_points": ["<给 points 的结构化反馈>"],
"feedback_for_analysis": ["<给 analysis 的结构化反馈>"]
}
-->
✅ 评审完成 | 模式: <Strict/Legacy> | 深度: <标准/加深> | 置信度: <高/中/低>
📄 报告: testspec/changes/<name>/review-report.md
📊 总评: <S1> 个 S1 + <S2> 个 S2 + <S3> 个 S3
testspec/changes/<name>/review-report.md