技能介绍

QA 写用例往往要啃 PDF、DOCX、XLSX 等碎片需求，还要对齐团队表格列名、步骤表述和命名习惯。手工对齐样例风格、再拆成可导入 TMS 的行级数据，既慢又容易漏列或口径不一致。

Casely 把流程拆成可重复的几步，并在项目目录里隔离输入、中间产物和结果：

/init：在 projects/{name}/ 下建立 input/、processed/、results/、exports/ 等目录；依赖在仓库根目录的 pyproject.toml，通过 uv 安装 docling、openpyxl。
/parse：调用 scripts/casely_parser.py，把需求与样例转成 Markdown。
/style：从 processed/examples/ 抽取表头顺序与写法，生成 test_style_guide.md（列结构必须与样例 1:1，不得擅自改名或删列）。
/plan：按模块划分 API / 集成 / E2E，估算用例量并输出 test_plan.md，附带可复制的 /generate 命令。
/generate [type]：按类型（functional、negative、integration、boundary 等）生成 原子用例——一个 Markdown 文件对应一条用例，内容为 单行横向表格（表头 + 一行数据），命名如 {type}_{id}_{short_description}.md。
/export：scripts/export_to_xlsx.py 将 results/ 中每个 .md 一对一 转为 exports/ 下的 .xlsx，单表 Test Case，列与风格指南一致。

技能会在每步后提示下一步（parse → style → plan → generate → export）。样例语言（含非英文）会被识别，生成用例与样例保持一致。

截图预览

产品发来 PDF/Word 需求后，需要按团队样例表的列顺序生成 functional、negative 等原子用例，并导出与 TMS 列映射一致的 Excel。
手头已有 XLSX 样例用例，要先跑 /style 固化 test_style_guide，再针对新模块批量 /generate，避免列名或步骤表述跑偏。
版本发布前要对多模块需求做 /plan，按 API、集成、E2E 分层估算用例量，并拿到各模块可直接复制的 /generate 命令。
results/ 里已有一批 Markdown 单行表格用例，需要与样例 1:1 的逐文件 xlsx，减少手工拼表再导入测试管理平台。

日常从 PDF、DOCX、XLSX 拆需求写用例的 QA，诉求是生成结果与团队样例表头、Mandatory 字段完全一致。
负责测试资产一致性的测试负责人，需要 style guide 作为唯一口径，并按模块分批执行 /generate 与 /export。
新项目上线的测试工程师，要把需求与样例放进 projects 目录，走完 parse→style→plan→generate 的隔离工作流。
要把 Casely 产出导入 Zephyr、TestRail 等 TMS 的用例维护者，需要 exports/ 下与 .md 一对一、单表 Test Case 的 xlsx。