QA 编排入口（qa）
把"帮我测试这个需求"翻译成一条可断点续跑的流水线。本 skill 是薄编排：不含任何测试方法与框架知识（全部在阶段 skill 与 core/），不替用户做裁决。
When to Use
- "帮我测试这个需求 / 功能"、"把这个功能完整过一遍"、"从需求到报告走一遍完整测试"
- 之前的流水线中断了，需要从落盘产物续跑
When NOT to Use
- 只要单阶段产出 → 对应阶段 skill：需求建模
requirement-analysis、测试策略test-strategy、写用例test-case-writing、审查已有用例test-case-review、E2E 执行automated-e2e-testing、API 执行api-testing、探索会话exploratory-testing、Bug 根因bug-analysis、回归范围regression-testing - 编写/修改某个阶段 skill 自身的方法论 → 不经过本 skill
编排会话模型（阶段间上下文隔离）
- 每个阶段运行在独立上下文中（宿主支持子会话/子代理时）：只加载当前阶段 skill 的 SKILL.md + 按需 references + 上一阶段的落盘产物文件；任一时刻活跃指令 ≤ 1–2 个 skill（当前阶段 + 本编排）
- 主会话只持有流水线状态：阶段清单、各产物文件路径、检查点状态——不加载任何阶段 skill 的领域知识
- 降级路径：宿主不支持子会话、或用户在单会话内手动走流水线时，退化为顺序会话 + 落盘文件衔接——正确性不受影响（状态全在文件里），损失的只是上下文卫生
- 反模式：单会话内顺序累加加载全部 SKILL.md（9 个 × 数百行指令同时在场）
- 注入式形态的例外（2026-08-23 R4）：预注入部署（评测或宿主一次性注入全部指令）下本节隔离机制不存在——此时靠阶段顺序防串扰：任一时刻只执行当前阶段的指令，其余在场文件视为未加载；"文件即流水线状态"的原则两形态通用（双形态声明见
../core/evidence.md第 6 节）
流水线与落盘产物（文件即流水线状态）
| # | 阶段 | skill | 落盘产物 | 人工检查点 |
|---|---|---|---|---|
| 0 | （旁路，可选）探索先行 | exploratory-testing | {项目}/探索笔记_{主题}.md | — |
| 1 | 需求理解 | requirement-analysis | {项目}/需求模型.md（含澄清记录） | ⏸ 澄清检查点：模糊/矛盾项等用户裁决 |
| 2 | 测试策略 | test-strategy | {项目}/测试策略.md（Risk Map + 两域 scope 含 type_scope）+ 专项移交_{轴}_{日期}.yaml（有 handoff/blocked/外部执行器轴时） | ⏸ 预算裁决：full 预算裁剪触及 Critical 轴时呈现排序提案等用户裁决 |
| 3 | 用例编写 | test-case-writing | {项目}/测试用例_markmap.md + 测试用例.schema.yaml | — |
| 4 | 用例审查 | test-case-review | 修订后用例文件 + 审查记录（重新抽取 Schema） | — |
| 5 | 执行 | automated-e2e-testing / api-testing / 手动 | 自动路径：执行代码或脚本（playwright/ 或 API 测试脚本）+ 执行分报告（至少 §2 执行统计 + §3 Bug 清单条目，字段按 ../core/report-template.md）；手动路径 手动执行记录_{日期}.md | ⏸ 执行策略裁决：确认 automation_plan 提案（手动/e2e/api）；手动路径执行后 ⏸ 结果回收（TC × 结果） |
| 6 | Bug 分析 | bug-analysis（有已确认 Bug 时） | 中间产物 {项目}/Bug条目_{日期}.md（条目结构与根因分析等五个扩展字段按 report-template §3）——此阶段禁止新建或改写最终测试报告 | ⏸ Bug 定性检查点：预期 vs 缺陷 |
| 7 | 回归验证 | regression-testing（有代码变更/Bug 修复时） | {项目}/回归清单_{日期}.md | — |
| 8 | 收尾报告 | 本 skill（按 ../core/report-template.md） | {项目}/测试报告_{日期}.md | — |
旁路触发条件：文档缺失 / 系统陌生时，阶段 0 在阶段 1 之前先行，探索产出（系统理解 + 风险清单）作为需求建模输入。
手动执行路径无 skill 与自动产物——执行后按 ⏸ 结果回收检查点向用户索取结果，落盘
手动执行记录_{日期}.md（TC 编号 × 结果〔通过/失败/阻塞〕，失败附 Bug 编号或现象）：作为阶段 8 报告 §2 执行统计与 §3 Bug 清单的数据来源，防"未执行"列成为永久状态。阶段 6 的
Bug条目_{日期}.md是中转中间产物：最终报告在阶段 8 才生成，此期间 Bug 条目无处追加——先落中转文件，阶段 8 拼装进报告 §3 后以报告为准，该文件归档留痕，不形成双数据源。阶段 2 生成的专项移交_{轴}_{日期}.yaml同样进入主会话的状态跟踪：后续任一阶段产出或用户反馈使移交轴状态变化时同步更新 yaml 内execution_status，防移交包生成即失联。
工作流
1. 启动：意图识别与路由
- 用户意图是端到端流水线 → 继续本 skill
- 用户意图是单阶段产出 → 移交对应阶段 skill，本 skill 退出
- 开工先收输入（用户提供或指路，产物对应位置留 TODO 指明"找谁拿什么"）：需求材料、代码仓库、测试环境与账号
2. 断点检查（续跑）
检查 {项目}/ 下已有哪些落盘产物，从最后一个完整阶段之后继续，不重做已完成阶段。产物缺失/损坏则从该阶段重跑。
3. 按流水线顺序调度阶段 skill
- 每个阶段：在独立上下文中调用对应 skill（或降级为顺序调用），输入 = 上一阶段的落盘产物文件路径（不是会话记忆）
- 检查点暂停：遇到 ⏸ 环节，向用户呈现该阶段 skill 汇总的问题/提案，等待用户答复后再进入下一阶段；用户在澄清环节的明确答复具有最终裁决力（见
../core/evidence.md裁决规则），后续阶段不得推翻 - 阶段产出落盘失败（文件未生成）→ 该阶段重跑，不进入下一阶段
4. 收尾：生成测试报告
全部阶段完成后（或用户要求提前收尾），按 ../core/report-template.md（此时加载）汇总生成 {项目}/测试报告_{日期}.md：范围、执行统计（自动运行结果与手动执行记录合并）、Bug 清单（拼装阶段 6 的 Bug条目_{日期}.md 并逐条同步状态——有回归结果的按结果更新为已验证关闭/已修复待验证，未回归的保持新建）、风险残留、回归摘要、类型域专项结果按 report-template §7 逐轴归一化回收（handoff / 外部执行 / blocked / exclude）、未闭环事项（含移交 yaml 各轴当前状态与去向）、各阶段产物路径索引。
5. 交付
向用户报告：最终报告路径 + 各阶段产物清单 + 未闭环事项（TODO 归属）。
硬规则
- 不做裁决：澄清、执行策略、Bug 定性、预算裁决一律呈现问题与建议后等用户，不代替用户决定
- 不含领域知识：测试方法、框架知识全部在阶段 skill 与
core/；本 skill 失败的唯一合理原因是编排错误，不是测试判断错误 - 状态全在文件：任何会话中断后，凭
{项目}/落盘产物即可续跑 - 阶段产物消费走文件：跨阶段传递的是产物路径，不是会话内转述
Common Mistakes
| 错误 | 后果 | 正确做法 |
|---|---|---|
| 把所有阶段 skill 的 SKILL.md 都加载进同一会话 | 指令冲突、上下文爆炸 | 阶段间上下文隔离，主会话只持状态 |
| 单阶段意图也启动流水线 | 过度执行、浪费 | 意图识别后移交对应阶段 skill |
| 检查点自答（替用户裁决） | 裁决失效，后续阶段基于错误假设 | ⏸ 环节必须等用户答复 |
| 凭会话记忆续跑（不读落盘文件） | 中断后状态丢失/不一致 | 断点检查只认文件 |
| 编排层塞入测试方法论 | 破坏薄编排、难以维护 | 方法论全部下沉阶段 skill 与 core/ |
| 阶段 6 提前新建/改写最终测试报告 | 与阶段 8 收尾同名双写、双数据源 | Bug 条目先落 Bug条目_{日期}.md 中转文件，收尾统一拼装 |