// TestSpec 新建测试工作（流程第 1 步）- 创建测试变更目录，编写 proposal.md，并在用户提供已有 PRD/需求片段时净化成可验收的 requirements.md。当用户要「新建测试」「开始测试」「创建测试变更」「建一个测试项目」或执行 testspec-new / testspec new 时使用。也适用于用户说「我要测 XXX 功能」「帮我准备测试」「有个新需求要测」「帮我整理/审查 PRD」的场景——如果尚无 testspec/changes/ 目录，这是流程的起点。产出 testspec/changes/<name>/ 目录结构、proposal.md，必要时产出 requirements.md。
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 测试点（流程第 3 步）- 从需求分析中提炼「要测什么」的简短要点清单，产出 specs/testpoints.md。当用户要「写测试点」「提取测试要点」「列出要验证的内容」或执行 testspec-points / testspec points 时使用。也适用于用户说「这个功能要测哪些点」「帮我列测试清单」的场景。与测试用例区分：测试点只列验证目标（What），不写操作步骤（How）。产出供 testspec-generate 展开为完整测试用例。
TestSpec 用例评审（流程第 5 步）- 对生成的测试用例做 14 维度交叉验证（R1-R6 规则检查 + H1-H8 启发式检查），产出 review-report.md 评审报告。当用户要「评审用例」「检查用例质量」「审查测试用例」或执行 testspec-review / testspec review 时使用。也适用于用户说「用例写完了帮我看看」「检查一下覆盖度」「用例有没有问题」的场景。支持默认模式和 --deep 深度模式。
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-new |
| description | TestSpec 新建测试工作（流程第 1 步）- 创建测试变更目录，编写 proposal.md，并在用户提供已有 PRD/需求片段时净化成可验收的 requirements.md。当用户要「新建测试」「开始测试」「创建测试变更」「建一个测试项目」或执行 testspec-new / testspec new 时使用。也适用于用户说「我要测 XXX 功能」「帮我准备测试」「有个新需求要测」「帮我整理/审查 PRD」的场景——如果尚无 testspec/changes/ 目录，这是流程的起点。产出 testspec/changes/<name>/ 目录结构、proposal.md，必要时产出 requirements.md。 |
IRON LAW: Never create a TestSpec change without a traceable requirement source or an explicit "information insufficient" marker; never turn a raw PRD into requirements.md by mere reformatting.
TestSpec New Progress:
- [ ] Step 1: Identify change name ⚠️ REQUIRED
- [ ] Step 2: Assess input material ⚠️ REQUIRED
- [ ] Step 3: Create change workspace
- [ ] Step 4: Write proposal.md with collaboration checkpoint
- [ ] Step 5: Run PRD intake and write requirements.md when raw PRD material is available
- [ ] Step 6: Review requirements.md quality when generated
- [ ] Step 7: Seed context metadata and report next step
新建一次 TestSpec 测试工作：创建变更目录并编写测试提案初稿，在 proposal 中关联或引用需求文档（PRD、用户故事、接口说明等）。当输入是已有 PRD 或需求片段时，额外执行 PRD Intake：先审查模糊和缺失，再把材料净化成 requirements.md，作为后续 testspec-analysis 的高质量需求源。
testspec-new 只负责准备可信需求源；不要在本阶段做测试风险拆解、测试点设计或用例生成。
若当前变更目录已存在，且用户是在补充、修改、删除或澄清 PRD/API/UI/产品口径，改用 testspec-update 做需求源口径收敛，不要重新创建变更。
references/proposal-template.mdreferences/requirements-template.md../_testspec-shared/references/output-contracts.md../_testspec-shared/references/context-protocol.md-（如「用户登录」→ user-login，release 2.0 → release-2.0）。确保根目录存在：若项目下没有 testspec/changes/，直接创建（mkdir -p testspec/changes）。
创建变更目录：testspec/changes/<name>/，以及子目录 specs/、artifacts/。
编写 proposal.md：在变更目录下创建 proposal.md。
模板见 references/proposal-template.md，核心字段：
协作检查点（写入 proposal.md 末尾、context 元数据之前）：
测试质量的上限取决于测试开始前的信息对齐程度。如果产品、开发、测试三方对需求范围和技术约束的理解不一致，后续分析和用例生成会建立在错误的假设之上。这个检查点的目的不是设置审批门禁，而是让 proposal 的信息质量从源头得到保障，减少下游返工。
## 协作确认
- [ ] 产品已确认需求范围和验收标准
- [ ] 开发已确认技术约束和可测试性（如：是否有测试环境、数据准备方式、已知的技术限制）
- [ ] 测试分析前需澄清的关键问题已列出（→ 将传递给 testspec-analysis 的质询清单）
使用说明：
PRD Intake（按需）：若用户提供已有 PRD 内容、PRD 链接/路径可读取内容，或明确要求审查/补全 PRD，则创建 requirements.md。
需求质量复核（按需）：若生成 requirements.md，执行六维质量复核并写入文档。
告知用户：变更目录路径、是否已生成 requirements.md，需求质量结论，以及下一步可执行 testspec-analysis 或 testspec-points。
触发条件：
执行规则：
requirements.md 不写 Redis、MQ、数据库表、接口拆分、算法选型等实现方案；未确认的技术约束按影响写入「阻塞澄清项」「执行期动态跟进」或「风险点」。requirements.md 中保留完整澄清清单，但对话中只推进一个阻塞点。readiness 不是 ready_for_analysis 或存在阻塞澄清项时，在 requirements.md 和最终回复中输出「可复制给产品的问题清单」；对话中仍只追问最高优先级的一个问题。按 references/requirements-template.md 生成 requirements.md。材料不足时也可以生成，但必须：
REQ-001 形式编号，并保留来源（原 PRD 章节/第 N 条/链接锚点等）RISK-001 形式编号，并说明影响、决策条件或备选处理testspec-context，source_skill 为 testspec-new，并包含 material_quality、signals_detected、blocking_open_questions、dynamic_followups、source_revision、requirements_intake、requirement_quality；完整字段以 references/requirements-template.md 为准生成 requirements.md 后，按六维给出 0-100 分：完整性、清晰性、一致性、可测试性、可追溯性、可行性。总分为六维平均值。
结论规则：
ready_for_analysis：总分 >= 90，且无阻断级澄清项needs_clarification：总分 75-89，或存在会影响测试设计但可继续分析的问题needs_revision：总分 60-74，需求需明显补写后再继续blocked：总分 < 60，或核心范围/验收标准缺失导致无法进入后续流程复核要求：
readiness 标为 ready_for_analysis当 readiness != ready_for_analysis 或 blocking_open_questions 非空时，最终回复必须输出可直接转发给产品/开发的问题清单：
## 可复制给产品的问题清单
1. [P0/P1/P2] <问题>（影响：<阻塞的分析/验收判断>；需要产品给出：<规则/范围/样例/口径>）
排序规则：阻塞澄清项在前，执行期动态跟进在后；每个问题必须关联 REQ/RISK/来源位置。不要把动态跟进计入阻塞问题数。
requirements.mdready_for_analysis在编写 proposal.md 之前，对用户提供的材料进行评估：
在 proposal.md 末尾，按 ../_testspec-shared/references/context-protocol.md 播种元数据：
<!-- testspec-context
{
"source_skill": "testspec-new",
"material_quality": "<high/medium/low>",
"signals_detected": ["<从材料中发现的关键信号>"],
"blocking_open_questions": ["<不确认就不能进入分析的问题>"],
"dynamic_followups": ["<测试执行中发现后再补充的问题>"],
"requirements_intake": {
"generated": "<true/false>",
"path": "<requirements.md 或空>",
"open_question_count": "<阻塞澄清项数量>"
},
"source_revision": {
"version": 1,
"summary": "<本轮需求源口径摘要>",
"updated_by_skill": "testspec-new"
},
"requirement_quality": {
"overall_score": "<六维平均分或空>",
"readiness": "<ready_for_analysis/needs_clarification/needs_revision/blocked 或空>"
}
}
-->
testspec/changes/<name>/proposal.md（含上下文元数据）testspec/changes/<name>/requirements.md（可选；当已有 PRD/需求片段可净化时生成）testspec/changes/<name>/specs/（空目录）testspec/changes/<name>/artifacts/（空目录）