Menü
基于测试知识库和测试规范，为指定模块或需求 suite 生成 Markdown 用例和 mismatch 记录
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
从 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 后缀