testkit

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 用例评审（流程第 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逆向', '从手机导出安装包', '提取接口', '查包名并反编译', '检测加固', '提取泄露'.

服务端日志智能分析与日志检索最佳实践 - 解读应用日志、JSON/structured logs、HTTP/access log、数据库慢查询、消息队列、定时任务、网关/代理和系统组件日志；适配本地文件、grep/rg/zgrep/jq 输出及主流日志平台线索。按 traceId/correlationId/requestId/spanId/线程/业务 ID 拆分链路，还原请求、任务、消息或批处理时间线，诊断报错、超时、慢调用、字段为空、数据不一致、重试降级、敏感信息泄露、日志质量、索引/标签/高基数和查询范围问题。用户粘贴日志、提供日志文件路径、贴查询结果、询问“分析日志”“查日志最佳实践”“帮我看下这段 log”“接口为什么慢”“为什么失败/超时/为空”“字段在哪一跳丢了”“日志里有没有报错”“怎么搜 trace”“慢查询/消息消费/access log/任务日志排查”时使用。

TestSpec 用例入库（流程第 6 步）- 将评审通过的测试用例从变更工作区发布到 testlib 知识库，按模块/功能自动分类、增量合并、生成变更日志。当用户要「发布用例」「入库」「合并到知识库」「沉淀用例」「publish」「用例入主干」「存到知识库」或执行 testspec-publish 时使用。也适用于用户说「这些用例保存下来」「把用例归档到库里」「测完了，入库吧」的场景。产出 testspec/testlib/ 知识库更新及 changelog 条目。

评估 SQL 查询的安全性、规范性和性能风险。覆盖 OLAP（Spark/Hive、Impala、ClickHouse）和 OLTP（MySQL）两大场景。审查维度：命名规范、编码格式、查询优化、索引策略、DDL/DML 规范、引擎特性、锁与事务。当用户贴出 SQL 问"能不能跑"、"会不会查爆"、"帮我 review"、"格式对不对"、"命名规范吗"、"这个 EXPLAIN 怎么看"、"为什么这么慢"、"能不能在生产跑"、"帮我看看这条 SQL"、"这个查询有没有问题"、"Code Review 一下"、"建表语句有问题吗"、"ETL 上线前审查"、"慢查询优化"、"索引怎么建"、"会不会死锁"、"大批量删除怎么做"时触发。即使用户只是贴了一条 SQL 没说别的，也应触发。支持 SELECT/DDL/DML/EXPLAIN 输出分析。

API 文档转 JMX 工具 - 根据 API 接口文档或自然语言输入自动生成 Apache JMeter 的 JMX 测试脚本。当用户要「生成 JMX」「创建 JMeter 脚本」「API 性能测试」「压测脚本」或从 curl/Postman/Swagger/OpenAPI 生成测试计划时使用。也适用于用户说「帮我把这个接口做成压测脚本」「这几个 API 要做性能测试」「把 Postman 导出转成 JMeter」的场景。支持输入：OpenAPI 3.0/Swagger 2.0 (YAML/JSON)、Markdown API 文档、curl 命令、Raw HTTP 请求/响应、Postman Collection v2.1。输出标准 JMX XML 格式。

将接口文档、OpenAPI、Markdown 接口说明、请求/响应示例转换成可执行的框架原生 API spec（YAML/JSON），并按需导出 Excel/CSV。只要用户的主要输入是 API 文档并且目标是生成可执行 case 或场景规格，都应优先使用这个 skill。当用户说"根据接口文档生成测试用例""先出一版可执行 spec""把这份 OpenAPI 转成 case"时务必使用。即使用户同时提到后续的 flow 配置或执行，当前阶段仍应先由本技能产出原生 spec 再交接。

为 API 自动化测试补齐可复用的前置 flow、项目级默认请求配置和环境变量约定。只要用户主要在说登录接口、token 提取、tenant 切换、默认 headers、project.yaml、flows/*.yaml、.env.example、config/.env 的增量补齐，或希望把前置依赖沉淀成可复用配置，都应优先使用这个 skill。当用户说"帮我配一下登录 flow""补一下 token 提取""项目缺 project.yaml"时务必使用。

在不重新执行测试的前提下消费已有 API 测试产物。只要用户主要想查看 allure-results、allure-report、结构化 JSON 结果、确认报告是否已生成、把已有 allure-results 转成可看报告、排查为什么报告打不开、或判断仓库里有哪些现成结果可以直接看，都应优先使用这个 skill。当用户说"打开 Allure 报告""看看这次测试结果""报告打不开"时务必使用。

执行已有的框架原生 API spec，并返回明确的通过、失败和归因证据。只要用户已经有 cases.yaml、cases.json、Excel 或 CSV 用例，并且当前主要目标是运行、看 pass/fail、看失败原因、生成 allure-results 或结构化 JSON 结果，都应优先使用这个 skill。当用户说"跑一下""执行测试""看看哪些 case 挂了""直接跑别重写"时务必使用。

扫描后端源码，发现 HTTP API 接口，并将接口清单写成 Markdown 或 JSON 文档。只要用户主要输入是 Java、Go、Python、Node.js 等后端代码，并且目标是盘点接口面、扫描某个模块或服务目录、按 URL 前缀过滤接口、或先根据源码形成一份可读接口清单时，都应优先使用这个 skill。当用户说"扫一下后端接口""盘点 API""从源码里找接口"时务必使用。

内部共享资源库，不直接触发。供其他 apitestspec-* 技能引用的 spec 格式定义、示例项目、路由表和共享脚本模块。不要在任何用户场景下直接使用这个 skill。