Menu
用例评审。由 qalore 调用，不独立触发。 对测试用例执行多层质量检查，输出问题报告。不产生持久化产物，报告仅在对话中呈现。 修复路径由 qa-functional-test 承接。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
测试用例执行。读取 TC 文件中的断言规则，通过 Playwright MCP + CDP Network MCP 在浏览器中逐条执行，产出执行报告。不修改 TC 文件。
功能测试用例设计与产物输出。由 qalore 调用，不独立触发。 以断言集合为输入，设计覆盖正向/边界/异常/上下游的测试用例，产出 story 和脑图产物。 业务逻辑由 qa-understand 提炼后传入，或已存在于 story 文件中。
测试意图理解与提炼。将任意信息源转化为可测试的理解，写入 story，供 qa-functional-test 和 qa-case-review 使用。 调度层设计：按需加载对应适配器，不预加载所有内容。 内置适配器：文本（PRD/需求/口述）、代码（文件/目录/片段，支持 N 个代码仓库）。 多源时顺序执行各适配器（文本适配器完成后依次执行各代码适配器），完成后加载综合层产出统一交接块。 由 qalore 调用，不独立触发。
全栈测试工程师网关。满足以下任一条件时使用： 1. 收到测试相关任务（生成用例、需求分析、覆盖率检查、用例评审等） 2. 涉及读写 story 的操作——story 是本 skill 管理的结构化测试知识库（路径存于 ~/.claude/qalore-config.json），含业务逻辑/测试用例/代码逻辑/变更日志四类文件， 按项目-模块两级目录组织。用户说「更新story/沉淀/写入story」时必须调用本 skill， 不得自行在其他路径创建文件代替。 已建设能力：测试意图理解、功能测试、用例评审。未建设（Phase 2）：自动化、性能、安全、混沌。 执行前必须先读 ~/.claude/qalore-config.json 获取 practices 和 story 路径， 验证路径有效后继续。路径无效时立即停止，不得使用通用知识代替。
Token 使用统计能力。由 Claude Code Stop Hook 自动触发，不由 qalore 主动调用。 从 transcript JSONL 累加本轮所有 API call 的 usage 数据，以固定格式打印到对话。 仅统计本轮；通过 last_assistant_message 信号词过滤，非 qalore 会话静默退出；无需额外 API 调用。
| name | qa-case-review |
| description | 用例评审。由 qalore 调用，不独立触发。 对测试用例执行多层质量检查，输出问题报告。不产生持久化产物，报告仅在对话中呈现。 修复路径由 qa-functional-test 承接。 |
| practices_min_version | 2026-06-12-v11 |
| 变量 | 来源 | fallback |
|---|---|---|
{practices_path} | qalore 注入 | 自动恢复：读 ~/.claude/qalore-config.json 重建 context |
{story_path} | qalore 注入 | 自动恢复：读 ~/.claude/qalore-config.json 重建 context |
{确认项目名} | qalore 注入 | 临时模式下不强制要求；story 模式下暂停向用户确认 |
评审的目标不是找格式问题，而是回答一个问题：这批用例拿去执行，会漏掉什么、卡在哪里？
从三个层次思考：
结构层：用例本身是否可执行？字段是否完整？每个触发性步骤是否有对应预期？每个 → 预期： 是否有对应 → 断言：？
遵循 {practices_path}/tech-stacks/functional/cases.md「用例格式」「用例质量标准」「断言规则」章节。
覆盖层：该测的场景是否都测了？
归因层：发现问题时，追溯根源在哪一层？
{practices_path}/common/handbook.md「评审规范」章节的严重级别定义。评审基准优先级：
联动模式（同会话）：context 中的【测试意图已提炼】交接块 → 三层完整比对
独立评审（跨会话）：story 中的业务逻辑.md + 代码逻辑.md → 有什么用什么
临时模式（粘贴内容）：无基准 → 只做结构层和覆盖层（L2a 四维度）
独立评审模式下两个文件都存在时的合并规则：
⚠️（文本-代码冲突）的断言：在评审报告中列出冲突并标注「需先与 PM/开发确认后再判断覆盖」，跳过该断言的覆盖检查，不阻断后续评审⚠️(代码)（多源代码冲突）的断言：在评审报告中标注「多源代码冲突未解决，需先在 qa-understand 确认以哪个仓库逻辑为准」，跳过该断言的覆盖检查，不阻断后续评审按需加载规范遵循 {practices_path}/common/handbook.md「context 标记规范」章节。
本 capability 使用的 practices 文件：
tech-stacks/functional/assertions.md（评审断言覆盖时）tech-stacks/functional/cases.md（评审用例格式、质量标准、断言规则时）tech-stacks/functional/execution.md（评审断言类型合法性时）handbook.md 已由网关预加载，直接使用；评审严重级别和结论判定规则见 handbook.md「评审规范」章节。
遵循 handbook.md「执行前确认规范」章节。本 capability 的计划摘要格式：
【用例评审执行计划】
项目：{确认项目名}
模块：{模块名}
输入模式：{story 模式 / 临时模式 / 联动模式}
评审用例数：{n} 条
基准：{交接块 / 业务逻辑.md + 代码逻辑.md / 无}
规范版本：{practices version}
【用例评审报告】
项目：{确认项目名} 模块：{模块名} 评审时间：{YYYY-MM-DD}
评审用例数：{n} 条 规范版本：{practices version}
■ 阻断问题（{n} 条，必须修复）
[{TC-ID 或 覆盖项}] {问题描述} → 根源：{执行层 / 理解层}
■ 需改进（{n} 条）
[{TC-ID 或 覆盖项}] {问题描述}
■ 建议优化（{n} 条）
[{TC-ID 或 覆盖项}] {建议内容}
总结：{n} 条阻断 / {m} 条需改进 / {k} 条建议
结论：{通过 / 需修复后通过 / 不通过}
结论判定规则遵循 {practices_path}/common/handbook.md「评审规范 · 结论判定规则」。
有阻断问题时：
如需修复：执行「修复 {模块名} 以下用例的阻断问题：{TC-ID-001, ...}」
评审是过程验证，不写入 story，不更新 index.json。
评审记录（可选持久化，仅 story 模式和联动模式可用）：
临时模式下无项目路径，跳过此步骤。
story 模式或联动模式时，报告输出完成后询问用户：
是否将本次评审结果写入评审记录？（方便后续跟踪质量趋势）
路径：{story_path}/{项目}/{模块}/{模块名}-功能-评审记录.md
用户同意 → 追加写入，格式见 {practices_path}/tech-stacks/functional/story-formats.md「评审记录文件」章节。
用户拒绝 → 不写入任何文件，流程结束。