用途
create-qa-list 用于把代码、规格文档、PR/diff、粘贴的需求、一句话请求，甚至当前对话内容，转化为一份非开发者 QA 测试人员可以阅读并执行的测试用例清单。目标是让不会打开代码的测试人员，也能根据清单运行产品并观察结果。
两条核心规则
该技能的所有决策都遵循两条规则，二者方向不同但必须同时满足：
- 规则一：读者是非开发者。他们运行产品并观察现象，不阅读代码。因此每个用例都用行为与场景语言书写——用户做什么、看到什么。函数名、文件路径、表/列名和代码符号绝不出现在输出中。这条规则决定语气、列结构和验证步骤。
- 规则二：每个用例必须与代码一致，不能编造。与真实行为不符的 QA 清单比没有更糟：测试人员会测试不存在的行为、提交不真实的 bug，或把真实 bug 标记为“通过”。因此每个场景和预期结果都必须基于实际验证过的内容（代码、规格或当前对话）。如果无法验证某个行为，需选择：阅读代码确认、询问用户，或删除该用例。不要把猜测的预期结果当作事实写出。任何基于未验证假设的用例都应标记为 needs-confirmation，而不是静默导出。
两条规则共同构成该技能的使命：把已验证的代码行为翻译成非开发者可执行的语言——翻译，但不编造，也不泄露代码。
输入
输入可以是任何内容：规格与规划文档、URL、PR/diff、粘贴的需求、一句话请求，或“为我们构建的东西做一个 QA 清单”。当前对话本身也是有效输入——如果一直在构建或讨论某个功能，该上下文就是输入。首要任务是确定目标功能/行为，先从所有可用信息中推断，再确认，不要假设。
工作流程
流程为分步进行，每一步都是检查点：自检是否有足够上下文，分享已有内容，并在投入下一步前获得用户确认。目的是避免在错误假设上构建 30 行的交付物。不要跳过步骤，也不要一次性抛出所有问题。
每一步之前，运行 references/context-checklist.md 中的自检问题。如果无法回答，说明尚未准备好，需要提问。
- 步骤一：范围。从代码/规格/对话中推断目标功能，然后复述理解并确认。对于会缩小到少数答案的决策（哪个功能、包含/排除哪些区域、哪个平台），提供选项并询问用户。要具体，引用实际发现的内容。至少确认：范围内是什么、明确排除什么、目标平台/角色是什么。
- 步骤二：分类与优先级方案。在写用例前，先商定清单如何分组和分级，这能保持 30 行的一致性。提出：分类集合——用例归入的功能区域（如输入验证/可见性条件/奖励/状态转换），从范围中推导，不要套用通用列表；优先级规则——什么算 P1/P2/P3，使用 references/consistency-guide.md 中的评分标准，但根据本功能调整示例并确认。两者都需达成一致，这是保持后续每行一致的契约。
- 步骤三：草稿用例清单（仅标题）。分享轻量大纲：每个用例包含 TC_ID + 分类 + 一行场景。此时不写完整列。这是发现“缺少用例 X”或“Y 不值得测试”成本最低的时机。按分类分组以便发现缺口。请求添加/删除/调整优先级。在此迭代直到大纲正确。
- 步骤四：导出格式。询问用户：CSV / HTML / 两者。CSV 适合导入测试管理工具或表格；HTML 是可读、可分享的报告，内置“Download CSV”按钮；两者适合交接加归档。
构建
将批准的大纲扩展为完整行。先阅读 references/consistency-guide.md，严格遵循列定义和写作规则。写每一行时应用规则二：预期结果必须反映已验证的行为，而非猜测。将用例写入工作目录中的 cases.json，并通过 --out 将输出放到工作目录下（如 qa_output/）或用户指定的路径。
使用内置脚本生成交付物，不要手写 CSV 或 HTML：
python3 scripts/build_export.py <cases.json> --format <csv|html|both> --out <dir>
如果不确定，先运行 --help。脚本负责格式化（CSV 转义、HTML 模板），确保输出一致，无需重新推导。
完成前验证
这是 QA 工具，需以 QA 标准要求自己的输出：
- 规则二检查（准确性）：每个预期结果是否匹配真实代码/规格行为？是否有行基于猜测？从代码重新确认或向用户标记。这是最重要的检查——错误的预期结果会让 QA 追逐不存在的 bug。
- 规则一检查（读者）：打开输出。是否有代码符号、函数名或文件路径泄露到单元格中？将该行改写为行为语言。
- 每行的列是否一致？优先级是否按商定的评分标准分配？
- 每个用例是否有具体、可观察的预期结果（不是“正常工作”）？
- 与步骤三大纲交叉核对——所有批准的用例是否都在？
修复并重新运行。不要停在第一次生成。
告诉用户如何打开。打印输出路径和打开命令，以便立即查看。例如：open "<path>/<title>.html"。如果环境能直接打开，就打开。
参考文件
- references/context-checklist.md——每一步的自检问题。步骤一前阅读。
- references/consistency-guide.md——列定义、非开发者语气规则、分类指导、优先级评分标准、好/坏行示例。构建前阅读（步骤二前浏览优先级评分标准）。
- references/export-formats.md——cases JSON 模式、三种导出格式及如何选择。步骤四/构建时阅读。
内置资源
- scripts/build_export.py——将 cases JSON 渲染为 CSV 和/或样式化 HTML 报告。仅使用标准库。
- assets/testcase_template.html——脚本填充的 HTML 报告外壳。布局一致、对非开发者友好，内置“Download CSV”按钮。
- assets/example_testcases.csv——写作示例和格式参考。
适用场景
适用于需要将开发产物（代码、规格、PR、对话）转化为非开发者可执行的 QA 测试用例，并导出为 CSV 或 HTML 报告的场景。
限制
资料未提供关于收费、价格、平台支持范围、具体效果或性能的说明。无法验证的行为需确认或删除，不能编造。