| name | case-draft |
| description | 依 Lanhu/Axure 链接(lanhuapp.com，含 axure/产品设计 URL)、Markdown PRD、设计稿、截图、fixture 或功能描述等需求源，生成、扩写或复核 QA 测试用例，产出 archive.md + cases.xmind。仅发送一条 Lanhu/Axure 链接即可直接触发，无需附带文字说明。仅做 Archive/XMind/CSV 格式转换请转至 case-edit；基于已有用例做自动化请转至 playwright-automation；单条 bug 记录（bug ID / ZenTao bug URL bug-view-NNN）请转至 case-hotfix。 |
| argument-hint | <Lanhu/Axure URL | Markdown PRD 路径 | 截图 | 功能描述> |
| user-invocable | true |
| model | sonnet |
| effort | high |
| allowed-tools | Bash(kata *) |
case-draft
依需求源生成 QA 用例。每条事实必须有 SourceRef 支撑；缺证据即阻塞，不得编造。
路由边界
以下场景不属本 skill 范围，请转至对应 skill：
- 纯 Archive/XMind/CSV 格式转换 → case-edit
- 基于已有用例做自动化 → playwright-automation
静默模式（Lanhu/Axure URL-only）
Lanhu/Axure URL-only 输入：从第一条消息起全程静默执行 source-intake。期间不得：
- 宣布自己在用哪个技能；
- 给出处理计划；
- 播报执行进度。
唯一可见输出是以下之一：
- 阻塞说明（两行）：首行写阻塞原因或缺口，次行写需用户补充的内容；正式记录落
cases/unresolved-summary.md。
- 最终交付：阻塞解除后直接给出产出文件。
工作流
flowchart TD
SRC["需求源：Lanhu/Axure URL、PRD、截图、描述"] --> Q0{"仅 Lanhu/Axure URL?"}
Q0 -->|是| SILENT["静默执行：不播报，仅阻塞两行或最终交付"]
Q0 -->|否| VIS["TodoWrite 建可见阶段进度"]
SILENT --> MI["module-identify：features resolve → featureDir"]
VIS --> MI
MI --> W["Worker 三阶段：historical-context → requirement-atomize → case-draft"]
W -->|缺证据 BlockedEnvelope| BK["阻塞：写 unresolved-summary.md，不直接问用户"]
W --> GATE["闸门：kata cases lint + validate，修完再审"]
GATE --> SR{"spec review 主会话"}
SR -->|不过| W
SR -->|过| QR{"quality review fresh 子代理"}
QR -->|不过| W
QR -->|过| BP{"blocking pending 清零?"}
BP -->|否| DRAFT["只出 draft / confirmation / unresolved 产物"]
BP -->|是| AR["cases/archive.md"]
AR --> XM["kata xmind-gen → cases/cases.xmind"]
非静默路径用 TodoWrite 建可见阶段进度，逐阶段推进：
- module-identify：先自行推断 workspace 项目（仅在无候选或多候选无法消歧时问用户）；首步执行
kata features resolve --project <project> --module <module> --feature-version <vX.Y.Z> [--lanhu-page <pageId>] --json，取返回的 featureDir；featureId 写入 metadata.yaml#id。漏传 --feature-version 会落 features/_standing/（长期主流程/冒烟区）；版本类需求必须显式传，版本号由 CLI 按 VERSION_DIR_RE（v6.4.11 式）归一化、模型不得自拼，未知时先 AskUserQuestion 确认再 resolve。
- historical-context / requirement-atomize / case-draft：这三阶段派 Worker 执行繁重处理（加载哪个文件见下方表）；Worker 以 Status/BlockedEnvelope 回传结果，遇到阻塞不直接询问用户。
- case-review → output：spec review（主会话）通过后派 quality review（fresh subagent）；blocking pending 清零后生成 cases/archive.md，再运行
kata xmind-gen --input cases/archive.md --output cases/cases.xmind 产出 XMind。
何时加载哪个文件
| 文件 | 何时读 | 作用 |
|---|
| prompts/agent-worker.md | 派发 case-draft Worker 时 | Worker 输入字段、写入范围、Status/BlockedEnvelope |
| prompts/agent-spec-reviewer.md | case-review 阶段 | spec 合规、SourceRef 分层、case_id 核对机械检查 |
| prompts/agent-quality-reviewer.md | output 前内容质量审查 | 步骤完整性、标题、覆盖与一致性 |
| rules/naming-convention.md | 新建 feature 目录时 | 目录命名格式与客户缩写 |
| references/source-refs.md | 需要核对 source_ref 锚点语法或 SR 前缀时 | source_ref 的 scheme#anchor 规范、SR- 注册前缀、证据分层 |
| .claude/prompt/_shared/case-format-sample.md | 需要用例节点格式参照时 | 格式样例（含 DQ 子集），不作事实来源；其菜单名是岚图定制，禁照抄 |
| .claude/prompt/_shared/case-qa.md | 交付前自审（共享引用） | 字段一致性、标题、前置条件、表单逐字匹配 |
workspace/<project>/_shared/knowledge/_index.md → sites/<host>/dom-*.md | module-identify 后、起草任何含菜单/页面/表单字段的用例前（必读） | 真实菜单名、路由、向导步骤、表单字段与统计函数文案基线；按 _index.md Sites 节逐条加载目标环境 DOM |
workspace/<project>/_shared/knowledge/_index.md → modules/<module>.md（存疑再查 source-repo-map.md 指向的 .kata/repos 源码枚举） | 起草任何含业务规则语义的用例前（必读） | 规则类型/统计函数清单/字段类型约束/多字段 AND 逻辑/规则集·多表比对·自定义SQL 机制等产品级语义事实来源；缺证据按规则臆测会写出错误用例，必须查证 |
产物与引用规范
- 所有产物写入
kata features resolve 返回的 featureDir。
- 每个 requirement atom 必须包含
evidence_kind、ambiguity_class、confidence，以及至少一个 source_ref。
- 事实引用走
metadata.yaml#case_drafting.requirement_atoms 的 SourceRef ID：轻量行写 {id, source_ref}，完整信息保留在 source_refs / case_id / requirement_atom_ids。
- 证据分层（SourceRef 标识不进交付正文、只存结构化数据层）的权威细则见
references/source-refs.md 的「证据分层」。
- 用例与证据的对照关系用
case_id 与 requirement_atom_ids 核对，不得用单一字段组合充当唯一键——单字段组合容易撞键，无法把证据精确对应到用例。
history_inferred 仅作为参考证据，新增行为一律以产品反馈为准。
落盘位置（产物 → 目录）
| 产物 | 落盘目录 |
|---|
archive.md、cases.xmind、confirmation-package.md、unresolved-summary.md 等用例产物 | cases/ 子目录 |
metadata.yaml | feature 根目录 |
source-snapshot.json、coverage-matrix.json 等过程与证据产物 | .process/ 子目录 |
清单与字段细则见 .claude/prompt/_shared/output-artifacts.md 与 .claude/prompt/_shared/case-qa.md（共享引用）。
事实字段：严禁编造，缺失即阻塞
suite_name（需求名）、case_id/prd_id（ZenTao 需求 id）、prd_version（lanhu-prd 迭代版本，与目录版本一致）、product_line（产品线名）、目标版本目录（--feature-version）是需向用户/ZenTao 确认的外部事实，不是可自由填的格式字段——它们会渲染进 xmind 可见节点或决定归类。任一字段无 SourceRef/用户明示时，主会话必须用 AskUserQuestion 一次性批量索要（推荐项置顶并附理由），严禁编造编号、自创需求名、拿 basename/迭代号/目录版本等默认值兜底后产出 cases/archive.md / cases/cases.xmind。字段→xmind 渲染映射见 .claude/prompt/_shared/case-format-sample.xmind.md。
起草前确认测试范围
需求开放、能拆出多条场景时（枚举多取值、衍生交互、优先级分配未定），起草用例前先用 AskUserQuestion 把测试点清单与覆盖范围摆给用户确认，再动笔——把范围缺口挡在起草前，避免用例跑出预期后整批返工。一轮确认覆盖三件事：
- 测试点清单：按需求+证据梳理出的场景列表（编号呈现），让用户增删；
- 枚举覆盖：需求/PRD 列出的多取值（数据源类型、状态、层级等）覆盖到哪些、是否抽样；
- 优先级分配：P0 用例集以核心交付/回归严重度定级，占比通常 25%~30% 左右作参考（小用例集允许偏离，不为凑比例硬升降级），让用户确认或改派。
这轮范围确认与上一节「事实字段缺证据的批量索要」合并在同一组 AskUserQuestion 内完成（推荐项置顶并附理由），是 URL-only 静默模式下「阻塞/索要」的既有例外，不算违反静默约束。
菜单/页面文案：以环境 DOM 证据为准（缺证据即阻塞）
用例步骤里的左导航/菜单名、页面与向导步骤、按钮文案、表单字段与统计函数枚举，都是客户/环境定制的外部事实，必须逐字来自目标环境的 sites/<host>/dom-*.md（或用户提供的截图）：
- module-identify 确定 project/客户/环境 host 后，先按
_index.md Sites 节加载该 host 的 dom-dataAssets.md 建立菜单·字段基线，再起草。
- 菜单文案只认
sites/<host>/dom-*.md：fewshot（case-format-sample.md）的菜单名是岚图定制，禁止照抄；modules/data-quality.md 现为产品级规则语义（不含具体客户菜单名），是规则类型/统计函数/校验语义的事实来源，但菜单·按钮文案仍以 sites DOM 为准；历史用例里的菜单名不作事实来源。
- 目标环境无专属 DOM、
_index.md 也无对应条目时：主会话 AskUserQuestion 向用户索要真实菜单截图/左导航清单，禁止降级套用其它环境（ltqc/ci63 等）的 DOM 或 fewshot 菜单名——岚图与标品菜单结构本就不同。worker 遇此返回 BLOCKED(missing_evidence)。
交付约束
-
blocking pending 未清零时，只允许产出草稿与确认类产物（cases/confirmation-package.md / cases/archive.draft.md / cases/unresolved-summary.md；error-fallback 下豁免并保留 URL token 表与 SourceRef ID）。清零后才生成 cases/archive.md，再由 kata xmind-gen 产出 cases/cases.xmind。
-
产物落盘后、交付前，按 lint→validate→verify 顺序跑三条 exit-code 门，全部为零再进入 review——把机械可查的字段/结构错误挡在人工审查之前，避免 reviewer 把精力浪费在命令本可发现的问题上：
kata cases lint --scope <featureDir> --exit-codekata cases validate <featureId> --project <project>kata cases verify --project <project> --feature <featureId> --exit-code（默认 --required-kinds lanhu.fixture,knowledge.entry,repo.line，flag 以 kata cases verify --help 为准）
verify 是三层硬校验门（L1 结构 / L2 输入消费 / L3 内容质量）；L1/L2/L3 全量触发只在 feature metadata case_drafting.status=completed 时发生，blocked/in-progress 路径跳过，不会误报。
-
metadata.yaml#automation.intents[] 中状态为 ready 的 AutomationIntent，移交给 playwright-automation。
-
生成 cases/archive.md 后、产 cases.xmind 前，必须回读核对：实际用例数须等于 frontmatter case_count（该一致性由 kata cases lint 的 archive-case-count-mismatch 硬校验，FAIL 即阻塞）；产 xmind 后回读根节点版本段、各二级节点标题与 (#N) label，与 module-identify 阶段确认的需求名/需求 id/版本基线逐字比对，任一不符先修正再交付。
表单用例规则
- 用户提供源码、平台 DOM/YAML、环境配置或截图作为表单证据时，这些证据必须进入必读集。
- 生成表单用例前必须先建立「表单字段基线」，不得写入基线之外的字段、选项或按钮。QA 需按实际文案逐字核对——写入基线外的字段、选项会让用例与真实表单脱节，执行时对不上，等于失真。
- 表单证据不可读时，或「事实字段」小节列出的外部事实字段缺证据时，用
AskUserQuestion 一次性批量索要缺口（推荐项置顶并附理由）；不得凭历史记录、few-shot 或模板补齐后产出最终 cases/archive.md / cases/cases.xmind。
