Menu
基于测试知识库和测试规范，为指定模块或需求 suite 生成 Markdown 用例和 mismatch 记录
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
从 target-aware case suite、task manifest 或 target/module/all selector 生成 pytest，执行 profile gate、Case IR、freshness check，并处理少量 UNPARSED 补写
构建模块级 fixture/module profile 或用例级 suite profile，把 Markdown 用例接入 test-codegen 管线
从已验证 pytest、Case IR 和 profile 中识别可沉淀模式，评估是否晋升为 assertion_rules、case_flows、fixture helper 或 emitter 规则
测试资产维护分诊台：诊断项目当前状态，定位管线断裂层，路由到正确的 skill 或 CLI 命令
将外部/历史/公司测试平台用例迁移为 AITest Markdown suite 用例，并保留语义追溯、阻塞分类和人工 review 清单
从源码和现有文档生成面向测试的设计文档，补全知识库构建所需的输入
| name | test-design |
| description | 基于测试知识库和测试规范，为指定模块或需求 suite 生成 Markdown 用例和 mismatch 记录 |
| when_to_use | 当用户需要为某个模块、L2 需求或独立用例 suite 生成/补充测试用例时 |
| argument-hint | <target> <module> [suite_dir] |
| arguments | ["target","module","suite_dir"] |
| user-invocable | true |
| allowed-tools | Read Glob Grep Write Edit Bash |
| effort | high |
为 $target 下的 $module 模块，或某个 L2 需求 suite 生成 Markdown 测试用例。
输出目录：$suite_dir。优先使用 test_workspace/suites/{target}/{suite}/ 或用户指定的任意 suite 目录，并在后续 test-scaffold / test-codegen 中由 suite.yaml 绑定 target/module。
优先读 aitest_config/aitest.yaml，获取：
workspace.paths.* — 知识库、用例、suite、文档等目录路径targets.registry / modules.registry — 已登记 target/module 的位置codegen.* — 模块缩写、断言规则、默认请求字段等 codegen 约束读取 aitest_config/aitest.yaml 获取 workspace 路径、codegen 默认规则和 target/module registry 配置。
读取 test_workspace/targets/{target}/target.yaml（存在时），获取公开接口、route/schema 搜索模式、默认 generated/reports 目录等 target 级信息。
读 {paths.test_spec}（TEST_SPEC），建立：
硬约束：在模块缩写对照表中查找 $module 对应的缩写。如果该模块未在表中登记，停止执行，提示用户先在 TEST_SPEC 的"模块缩写对照表"中补登记，避免编号冲突。同一 workspace 存在多个 target 时，仍以 $target/$module 作为定位范围。
读 {paths.l0_architecture}（L0），从模块索引表中找到 $module 对应的：
读目标 L1 文档，提取：
读关联 L2 文档，提取：
搜索已有用例，确定编号起点：
test_workspace/suites/ 中绑定该 module 的 suite，以及 aitest.yaml.workspace.paths.suites_dir读 aitest_config/refs/assertion-strategy.md，建立断言策略（结构断言 / 关系断言 / 不可程序化断言的选择标准）
信息边界：本步骤禁止读取源代码文件（.py/.java/.go/.ts 等）。
TBD-需确认，不猜测[!请求体待补全]aitest_config/refs/assertion-strategy.md 的三种策略接口覆盖：查看 L1 "接口"章节，确认模块暴露的接口类型（HTTP / gRPC / 两者）。共享配置可以列出多种接口，但默认 Markdown 用例只生成 JSON 基础请求体；写 协议：gRPC 或 基础请求体（gRPC） 不会阻断默认 JSON 路径，真实 gRPC、SDK 或多端点执行再在后续 suite profile 中通过 case_flows 或 case_bodies 显式接线。
输出格式：默认输出到 $suite_dir/business.md；如果用户指定需求 suite，可输出为 {suite_name}_business.md 等带语义的文件名。按 aitest_config/refs/case-format.md 的"共享配置 + 精简用例"格式。每条用例只写 优先级 / 场景变量 / 断言 三个字段（有特殊状态时加 标记 字段）。场景变量必须写成 key：value 条目列表，[manual]、[!可行性存疑] 等标记写在独立的标记字段，不内联到场景变量或断言中。test-design 只产出 Markdown 用例，不写 suite.yaml 和 suite profile；这些由 test-scaffold / test-codegen 接线。
$target/$module 相关的源代码文件target.yaml 声明了 service.route_patterns，按该模式搜索路由；否则以文档、OpenAPI/proto 或用户指定入口为准，必要时标 [!可行性存疑]target.yaml 声明了 service.schema_patterns，按该模式搜索 Schema；否则读取 OpenAPI/proto/JSON Schema 等公开接口定义，逐字段核对请求体（必填字段必须存在，嵌套结构也要检查）[!请求体待补全] 的用例[!可行性存疑: 原因]aitest_config/refs/mismatch-format.md 新建 mismatch 记录。如果 $suite_dir/mismatch.md 已存在，新条目追加在文件末尾，不删除/覆盖已有条目，编号从已有最大序号 +1 继续TBD-需确认 的预期结果，如果代码能给出答案，在 business.md 中更新并标注来源默认输出到 $suite_dir/boundary.md，使用与 business.md 相同的共享配置格式；suite 模式可使用 {suite_name}_boundary.md 等带语义的文件名。
Mismatch 输出到 $suite_dir/mismatch.md（无则不创建）。
## 覆盖变更
| 知识库文档 | 新增覆盖 | 仍未覆盖 |
|-----------|---------|---------|
| L1/xxx | 维度 A、维度 B | 维度 C |
执行完毕后，向用户输出：
## 用例生成摘要
目标：$target
目标模块：$module
输出目录：$suite_dir
### 生成文件
| 文件 | 用例数 | 类型 |
|------|-------|------|
| business.md | N 条 | 业务 + 异常 |
| boundary.md | N 条 | 边界 |
| mismatch.md | N 条 | 规格偏差 |
### 覆盖变更
| 知识库文档 | 新增覆盖维度 | 仍未覆盖维度 |
### TBD 项
（列出所有预期结果为 TBD-需确认 的用例，需用户或产品确认）
### 可行性存疑
（列出所有标注了 [!可行性存疑] 的用例）
然后询问用户：
如果用户给出排除/关注反馈 → 更新 {paths.test_spec} 对应章节。
生成每条用例后，对照以下两组规则逐条检查，不通过的用例必须修正后再输出：
当 $suite_dir 下已有 business.md 或 boundary.md 时，先询问用户选择处理方式：
*.md.bak，从零生成全部用例用户选择追加时，继续询问用例来源：
格式兼容检测：检查已有文件是否包含 ## 共享配置 块。
确认选择后再执行。
case-format.md 格式的用例：
key：value 条目列表assertion-strategy.md 的三种策略.bak 后缀