メニュー
TestSpec 测试点（流程第 3 步）- 从需求分析中提炼「要测什么」的简短要点清单，产出 specs/testpoints.md。当用户要「写测试点」「提取测试要点」「列出要验证的内容」或执行 testspec-points / testspec points 时使用。也适用于用户说「这个功能要测哪些点」「帮我列测试清单」的场景。与测试用例区分：测试点只列验证目标（What），不写操作步骤（How）。产出供 testspec-generate 展开为完整测试用例。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | testspec-points |
| description | TestSpec 测试点（流程第 3 步）- 从需求分析中提炼「要测什么」的简短要点清单，产出 specs/testpoints.md。当用户要「写测试点」「提取测试要点」「列出要验证的内容」或执行 testspec-points / testspec points 时使用。也适用于用户说「这个功能要测哪些点」「帮我列测试清单」的场景。与测试用例区分：测试点只列验证目标（What），不写操作步骤（How）。产出供 testspec-generate 展开为完整测试用例。 |
IRON LAW: Test points describe what to verify, never how to execute it.
TestSpec Points Progress:
- [ ] Step 1: Locate current change directory ⚠️ REQUIRED
- [ ] Step 2: Load requirements-analysis.md or proposal.md ⚠️ REQUIRED
- [ ] Step 3: Consume upstream context and testlib signals
- [ ] Step 4: Generate specs/testpoints.md with naming dictionary
- [ ] Step 5: Validate naming contract and reflect
- [ ] Step 6: Seed context metadata and report next step
从需求分析结论中提炼出简短的测试覆盖要点清单，作为 testspec-generate 的直接输入。
与 analysis 的关系：analysis 做深度拆解（等价类、边界值、状态迁移、风险点），points 是 analysis 的"精华版"——把分析结论转化为一条条简短的"要验什么"。如果已有 requirements-analysis.md，points 应该从中提炼而非重复分析；如果没有 analysis，points 按默认策略直接从 proposal.md 提炼。
每个测试点必须归属以下一种类型：
格式：TP_<MODULE>_<FEATURE>_<SEQ>
当 testspec/testlib/index.json 存在时，优先参考 testlib 中已有的 module_key/feature_key 缩写，避免同一模块在不同变更中使用不同缩写。仅对 testlib 中不存在的新模块/功能新建缩写。
TP_ID 是当前变更工作区内的测试点标识，SEQ 编号在每次变更内独立分配（从类别起始值开始），无需与 testlib 中的历史编号衔接。testlib 的更新管理基于仓库当前状态（ID + 标题语义匹配）；index.json 中的 tp_ids 仅用于检索“该功能的用例覆盖过哪些测试点”，不参与 TP_ID 编号分配，也不要求跨变更唯一。
每个测试点必须标注优先级：
每个测试点可选标注回归套件层级，用于指导后续回归测试的选取范围。未标注时默认 Full。
Agent 根据以下信号自主判断层级，不套用固定比例：
详见 ../_testspec-shared/references/naming-contract.md。生成 testpoints.md 后必须按其中的自检清单逐项验证。
生成 testpoints.md 后，对照以下反模式自查。发现符合的情况时自动修正。
| 反模式 | 表现 | 正确做法 |
|---|---|---|
| 字段级拆分 | 把"用户名""密码""验证码"各拆一个测试点 | 合并为"登录表单验证"一个测试点，字段级差异在 generate 阶段用等价类覆盖 |
| 等价类误认为测试点 | "密码长度 8-20"拆成"7位""8位""20位""21位"四个测试点 | 只设一个"密码长度边界验证"测试点，具体边界值在 generate 阶段展开 |
| 测试步骤泄漏 | 测试点描述中出现"点击""输入""选择"等操作动词 | 测试点只描述验证目标（What），不描述操作方法（How） |
| 模块失衡 | 某模块只有 1-2 个测试点而其他模块 10+ 个 | 检查是否遗漏了该模块的异常/边界/集成类别 |
| 类别缺失 | 全部测试点都是 Functional，没有 Boundary/Exception | 每个核心模块至少覆盖 Functional + 1 个其他类别 |
| 伪测试点 | "验证功能正常""确认系统可用"等无具体验证意图的描述 | 验证要点必须指向具体的业务行为或质量属性 |
参见 ../_testspec-shared/references/common.md 中的「当前变更目录定位规则」。
按
../_testspec-shared/references/thinking-protocol.md执行推理式决策。
requirements-analysis.md（优先）或 proposal.md<!-- testspec-context ... -->）risks_identified → 确保对应风险有高优先级测试点blocking_open_questions → 标注为"需确认"的测试点material_quality → 影响推理深度testlib_coverage（若有）→ 直接使用 analysis 的扫描结论stale_downstream_artifacts：若命中 testpoints.md 或当前输入产物，停止执行并提示先运行 next_skill 或 testspec-analysis rebaselinesource_revision.version：若上游版本高于当前输入产物 context 中记录的版本（或输入产物缺少 source_revision），停止执行并提示上游已更新、需先重跑上游 skill若上游 testlib_coverage 不存在或 scanned = false，points 自行扫描：
testspec/testlib/index.json 是否存在tp_ids 字段）：该功能历史用例曾覆盖过的测试点，用于理解覆盖范围related_features）：可能需要回归的关联功能tp_ids 判断哪些区域需要回归工作流中不应只找问题和风险——发现"我们已经有什么"同样重要，能显著提升效率。
在 testlib 检索完成后、覆盖策略推理前，回答以下问题：
产出：在 testpoints.md 的「知识库复用摘要」之后增加「可复用资产」小节：
## 可复用资产
- testlib 可直接复用：<功能点列表及对应 testlib 路径>
- 自动化友好区域：<模块列表及原因>
- 可共享测试数据：<数据类型及适用模块>
- 快速收益点：<TP_ID 及收益说明>
下游影响：
通过 4 个核心问题决定覆盖深度：
requirements-analysis.md（从中提炼）proposal.md（直接提炼）为确保大文件写入成功，按以下优先级执行：
# 测试点：<被测对象>
## 概述
<一两句话说明本次测试覆盖范围与重点>
## 知识库复用摘要
> 仅当 testlib 中存在相关覆盖时输出。无 testlib 或无匹配时跳过此节。
| 模块 | 功能点 | testlib 历史覆盖 TP 数 | 本次策略 |
|------|--------|-------------------|----------|
| <模块> | <功能> | N | 复用 / 新增 / 替代 |
**说明**：以下 TP_ID 表示历史用例覆盖过的测试点，供判断复用/回归范围参考：
- TP_XXX_YYY_001（testlib 路径：<module>/<feature>.json）
## 可复用资产
> 仅当 testlib 扫描发现可复用项时输出。无 testlib 或无匹配时跳过此节。
- testlib 可直接复用：<功能点列表及对应 testlib 路径>
- 自动化友好区域：<模块列表及原因>
- 可共享测试数据：<数据类型及适用模块>
- 快速收益点：<TP_ID 及收益说明>
## 命名字典
### 模块字典
| 模块名称 | MODULE |
|---|---|
| <模块名称> | <2-5 位大写缩写> |
### 功能点字典
| 模块名称 | 功能点名称 | FEATURE |
|---|---|---|
| <模块名称> | <功能点名称> | <2-10 位大写缩写> |
### [模块名称]模块
#### [功能点名称]功能
##### 功能验证点 (Functional)
- TP_<MODULE>_<FEATURE>_001: <测试点名称（格式：{模块}_{功能点}_{验证意图}）>
- 验证要点: <验证什么（What），不写步骤/数据>
- 优先级: P1/P2/P3
- 回归层级: Smoke/Full/Targeted（可选，默认 Full）
- 关联需求: <需求编号/段落>
##### 边界验证点 (Boundary)
##### 异常验证点 (Exception)
##### 集成验证点 (Integration)
##### 非功能性验证点 (Non-Functional)
完整模板见 references/testpoints-template.md。
按
../_testspec-shared/references/reflection-protocol.md执行产物反思。
产物首次生成后，执行反思循环：
反思后修正产物，最多 2 轮迭代。告知用户迭代次数和修正摘要。
在 specs/testpoints.md 末尾，按 ../_testspec-shared/references/context-protocol.md 播种元数据：
<!-- testspec-context
{
"source_skill": "testspec-points",
"coverage_estimate": "<各类别覆盖情况>",
"risks_identified": ["<从上游继承或新发现的风险>"],
"regression_tiers": {
"smoke": ["<Smoke 层级的 TP_ID>"],
"full": ["<Full 层级的 TP_ID>"],
"targeted": ["<Targeted 层级的 TP_ID>"]
},
"testlib_reuse": {
"existing_tp_ids": ["<testlib 中已覆盖的 TP_ID>"],
"new_tp_ids": ["<本次新增的 TP_ID>"]
}
}
-->
testspec/changes/<name>/specs/testpoints.mdTestSpec 需求分析和梳理（流程第 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 用例评审（流程第 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逆向', '从手机导出安装包', '提取接口', '查包名并反编译', '检测加固', '提取泄露'.