从需求文档生成测试用例。支持飞书项目单URL、飞书云文档URL或本地文件路径。采用四阶段工作流：需求分析→测试点生成→用例设计→智能优化。
Generates OPML format test cases from requirement documents using a four-stage workflow.
/plugin marketplace add mookechee/mookechee-cc-plugins/plugin install testflow-generator@mookechee-cc-plugins从需求来源 "$ARGUMENTS" 自动生成 OPML 格式的 XMind 测试用例。
# 从飞书项目单生成
/testflow-generator:generate https://project.feishu.cn/xxx/story/detail/xxx
# 从飞书云文档生成
/testflow-generator:generate https://xxx.feishu.cn/docx/xxx
# 从本地文件生成
/testflow-generator:generate ./docs/requirement.md
根据 $ARGUMENTS 判断输入类型：
类型1：飞书项目单 URL（包含 project.feishu.cn 和 story/detail）
从 URL 提取：
project_key: 空间标识（如 uts5wn）work_item_id: 工作项 ID（如 6589464068）URL 格式：https://project.feishu.cn/{project_key}/story/detail/{work_item_id}
类型2：飞书云文档 URL（包含 .feishu.cn/docx/）
从 URL 提取 doc_token（链接最后一段）
类型3：本地文件路径
使用 Read 工具读取文件内容
调用 mcp__lark-prj-remote__get_workitem_brief：
project_key: {提取的project_key}
work_item_id: {提取的work_item_id}
fields: ["description", "field_803289", "field_13a9cf", "wiki"]
字段说明：
description: 需求描述field_803289: 验收标准field_13a9cf: 技术设计文档链接调用 mcp__lark-mcp-remote__docs_v1_content_get：
query:
doc_token: {提取的doc_token}
doc_type: docx
content_type: markdown
使用 Read 工具直接读取
如果存在技术设计文档链接（field_13a9cf）：
mcp__lark-mcp-remote__docs_v1_content_get 获取内容角色定位： 你是专业的需求分析专家，专精于软件需求拆分与测试规划。
分析流程：
需求理解
需求拆分
优先级评估
质量检查
输出格式：
需求点列表：
1. [P0] {需求点描述} - {所属模块}
2. [P1] {需求点描述} - {所属模块}
...
完成后： 向用户展示需求点列表，然后自动继续下一阶段。
角色定位： 你是资深测试架构师，擅长设计全面且高效的测试策略。
核心原则：
测试分类：
| 分类 | 说明 | 典型优先级 |
|---|---|---|
| PRD UI/交互设计测试 | 界面布局、组件显示、交互操作 | P0 |
| 功能测试 | 核心功能验证 | P0 |
| 状态切换测试 | 状态转换正确性 | P0-P1 |
| 边界值测试 | 最大值、最小值、默认值 | P1 |
| 异常场景测试 | 错误处理、异常恢复 | P0-P1 |
| 兼容性测试 | 多平台、多配置 | P1-P2 |
| 稳定性测试 | 重复操作、极端场景 | P2 |
设计方法：
输出格式：
需求点 RP-001 的测试点：
- TP-001 [P0] {测试点描述} - {测试类型}
- TP-002 [P1] {测试点描述} - {测试类型}
...
完成后： 向用户展示测试点列表，然后自动继续下一阶段。
角色定位： 你是经验丰富的测试用例设计专家。
核心原则：
用例编写规范：
| 要素 | 说明 | 示例 |
|---|---|---|
| 用例名称 | 简洁明了，格式：{功能点}{测试场景} | 登录功能-正确密码登录成功 |
| 前置条件 | 测试开始前必须满足的条件 | 用户已注册，处于登出状态 |
| 执行步骤 | 具体操作步骤，简洁描述 | 输入正确用户名和密码，点击登录按钮 |
| 预期结果 | 明确、可量化、可观测 | 登录成功，跳转到首页，显示用户信息 |
| 优先级 | P0/P1/P2 | P0 |
角色定位： 你是资深测试专家，负责测试用例的质量评估和优化。
验收标准覆盖检查（必须）：
逐条分析验收标准，确保每条验收标准都有对应的测试用例：
验收标准1 → 测试用例1, 测试用例2, ...
验收标准2 → 测试用例3, 测试用例4, ...
优化策略：
生成的 OPML 文件必须符合以下 链式结构：
<?xml version="1.0" encoding="UTF-8"?>
<opml version="2.0">
<head>
<title>{工作项名称}测试用例</title>
</head>
<body>
<outline text="{工作项名称}测试用例">
<outline text="用例名称">
<outline text="前置条件描述">
<outline text="执行步骤描述">
<outline text="预期结果描述">
<outline text="P0"/>
</outline>
</outline>
</outline>
</outline>
</outline>
</body>
</opml>
关键要求：
用例名称 → 前置条件 → 执行步骤 → 预期结果 → 优先级⚠️ OPML 格式规范（必须遵守）：
| 规则 | 说明 | 错误示例 | 正确示例 |
|---|---|---|---|
| 禁止XML注释 | 不要使用 <!-- --> 注释，会导致XMind解析异常 | <!-- 模块1 --> | 直接删除注释 |
| 转义双引号 | 属性值中的双引号必须转义为 " | text="显示"hello"" | text="显示"hello"" |
| 转义尖括号 | 属性值中的 < 和 > 必须转义 | text="a<b>c" | text="a<b>c" |
| 转义&符号 | 属性值中的 & 必须转义为 & | text="A&B" | text="A&B" |
| 禁止emoji | 不要使用emoji字符，改用文字描述 | text="状态🟢" | text="状态（绿色）" |
XML实体转义对照表：
| 字符 | 实体编码 | 说明 |
|---|---|---|
" | " | 双引号 |
< | < | 小于号 |
> | > | 大于号 |
& | & | 与符号 |
' | ' | 单引号（可选） |
将 OPML 文件保存到：~/Testcase/opml/{工作项名称}_测试用例_{时间戳}.opml
时间戳格式：YYYYMMDD_HHmmss（如 20250106_143052）
如果目录不存在，先创建目录。
输出格式化的总结信息：
## 需求摘要
**需求名称**：{工作项名称} (m-{work_item_id})
**需求描述**：{description}
**验收标准**：
1. {验收标准1}
2. {验收标准2}
...
## 验收标准覆盖情况
| 验收标准 | 对应测试用例数 | 覆盖状态 |
|----------|---------------|----------|
| {验收标准1} | X | ✅ 已覆盖 |
| {验收标准2} | X | ✅ 已覆盖 |
## 测试用例统计
| 分类 | 用例数 | P0 | P1 | P2 |
|------|--------|----|----|-----|
| PRD UI/交互设计测试 | X | X | X | X |
| 功能测试 | X | X | X | X |
| {其他分类} | X | X | X | X |
| **合计** | **X** | **X** | **X** | **X** |
## 文件路径
`~/Testcase/opml/{工作项名称}_测试用例_{时间戳}.opml`
| 优先级 | 重要性 | 适用场景 |
|---|---|---|
| P0 | 最高 | 核心功能、验收标准直接相关、主流程、编译验证 |
| P1 | 中等 | 重要功能、边界条件、配置验证、异常处理 |
| P2 | 较低 | 辅助功能、极端场景、稳定性测试、可选特性 |
/generateGenerate ready-to-execute hypershift cluster creation commands from natural language descriptions
/generateGenerate documentation from TypeScript/JavaScript code, OpenAPI specs, GraphQL schemas, and SpecWeave specifications.