qa

QA オーケストレーションの入口（qa）

「この要件をテストして」と依頼された内容を、中断地点から再開できるパイプラインに変換します。この skill は薄いオーケストレーション層です。テスト手法やフレームワークの知識は含みません（すべて各フェーズの skill と core/ にあります）。ユーザーに代わって判断を下すこともありません。

使用する場面

• 「この要件／機能をテストして」「この機能を一通り確認して」「要件からレポートまで、テストを一通り進めて」
• 以前のパイプラインが中断され、ディスク上の成果物から再開する必要がある場合

使用しない場面

• 単一フェーズの成果物だけが必要な場合 → 対応するフェーズの skill を使用します：要件モデリング requirement-analysis、テスト戦略 test-strategy、テストケース作成 test-case-writing、既存テストケースのレビュー test-case-review、E2E 実行 automated-e2e-testing、API 実行 api-testing、探索的テストセッション exploratory-testing、バグの根本原因分析 bug-analysis、回帰範囲 regression-testing
• 特定のフェーズ skill 自体の方法論を作成／変更する場合 → この skill は経由しません

オーケストレーションセッションモデル（フェーズ間のコンテキスト分離）

• 各フェーズは独立したコンテキストで実行します（ホストがサブセッション／サブエージェントに対応している場合）：現在のフェーズの skill の SKILL.md と、必要に応じて references、前フェーズのディスク上の成果物ファイルのみを読み込みます。常に有効な指示は ≤ 1–2 個の skill（現在のフェーズとこのオーケストレーション）だけです
• メインセッションが保持するのはパイプラインの状態だけです：フェーズ一覧、各成果物ファイルのパス、チェックポイントの状態です。フェーズの専門知識は読み込みません
• フォールバック：ホストがサブセッションに対応していない場合、またはユーザーが単一セッション内で手動でパイプラインを進める場合は、順次セッション＋ディスク上のファイルによる引き継ぎに切り替えます。正確性への影響はありません（状態はすべてファイル内にあります）。失われるのはコンテキストの衛生面だけです
• アンチパターン：単一セッション内で、すべての SKILL.md を順次読み込み続けること（数百行の指示を含む 9 個の skill が同時に存在する状態）
• 指示の事前注入形式における例外：事前注入型のデプロイ（評価またはホストがすべての指示を一度に注入する場合）では、この節の分離メカニズムは適用されません。この場合はフェーズの順序によって混在を防ぎます。常に現在のフェーズの指示だけを実行し、その他のファイルは読み込まれていないものとして扱います。「ファイルがそのままパイプラインの状態」という原則は、どちらの形式にも適用されます（2 形式については ../core/evidence.md の第 6 節を参照）

パイプラインとディスク上の成果物（ファイルがそのままパイプラインの状態）

#	フェーズ	skill	ディスク上の成果物	人手によるチェックポイント
0	（任意のバイパス）探索を先行	exploratory-testing	{プロジェクト}/探索メモ_{テーマ}.md	—
1	要件の理解	requirement-analysis	{プロジェクト}/要件モデル.md（確認記録を含む）	⏸ 確認チェックポイント：曖昧／矛盾する項目などについてユーザーの判断を仰ぐ
2	テスト戦略	test-strategy	{プロジェクト}/テスト戦略.md（Risk Map＋2 つの領域の 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 テストスクリプト）＋実行分レポート テストレポート_{ソース}_{日付}.md（命名規則は ../core/report-template.md 冒頭の注記を参照。最低限 §2 実行統計＋§3 バグ一覧の項目。フィールドは report-template に従う）。手動パス 手動実行記録_{日付}.md	⏸ 実行方針の判断：automation_plan の案（手動／e2e／api）を確認します。手動パスでは、実行後に ⏸ 結果回収チェックポイント（TC × 結果）を設けます
6	バグ分析	bug-analysis（確認済みのバグがある場合）	中間成果物 {プロジェクト}/バグ項目_{日付}.md（項目の構造と根本原因分析など、5 つの拡張フィールドは report-template §3 に従う）——このフェーズでは最終テストレポートを新規作成または書き換えてはいけません	⏸ バグの評価チェックポイント：想定どおりか、欠陥か
7	回帰検証	regression-testing（コード変更／バグ修正がある場合）	{プロジェクト}/回帰チェックリスト_{日付}.md	—
8	最終レポート	この skill（../core/report-template.md に従う）	{プロジェクト}/テストレポート_{日付}.md	—

バイパスのトリガー条件：ドキュメントがない／システムに不慣れな場合は、フェーズ 0 をフェーズ 1 より先に実施します。探索の成果物（システムの理解＋リスク一覧）は、要件モデリングの入力として使用します。

手動実行パスには skill も自動生成される成果物もありません。実行後、⏸ 結果回収チェックポイントでユーザーに結果を求め、手動実行記録_{日付}.md に記録します（TC 番号 × 結果〔合格／失敗／ブロック〕。失敗の場合はバグ番号または現象を記載）。これはフェーズ 8 レポートの §2 実行統計と §3 バグ一覧のデータソースとなり、「未実行」の列が恒久的に残るのを防ぎます。

フェーズ 6 の バグ項目_{日付}.md は中継用の中間成果物です。最終レポートはフェーズ 8 で初めて生成されるため、それまでバグ項目を追記する場所がありません。まず中継ファイルに記録し、フェーズ 8 でレポートの §3 に組み込んだ後はレポートを正とします。このファイルはアーカイブして記録を残しますが、二重のデータソースにはなりません。フェーズ 2 で生成した 特別引き継ぎ_{軸}_{日付}.yaml も、メインセッションの状態追跡に含めます。後続のいずれかのフェーズの成果物、またはユーザーからのフィードバックによって引き継ぎ軸の状態が変化した場合は、yaml 内の execution_status も同時に更新し、引き継ぎパッケージの生成直後に追跡されなくなるのを防ぎます。

セッションをまたぐ知識：フェーズの成果物に、セッションをまたいで保持する価値のある QA 知識（環境特有の挙動／flaky 判定／欠陥パターンなど）が含まれる場合は、qa-memory に従って判断し、プロジェクトの .qa/ ナレッジベースに書き込みます。セッション内の状態は引き続きディスク上の成果物を正とし、両者を相互に置き換えることはできません。

ワークフロー

1. 開始：意図の識別とルーティング

• ユーザーの意図がエンドツーエンドのパイプライン → この skill を続行します
• ユーザーの意図が単一フェーズの成果物 → 対応するフェーズの skill に引き継ぎ、この skill を終了します
• 作業開始前に入力を収集します（ユーザーから提供してもらうか、入手先を案内してもらいます。成果物の該当箇所には TODO を残し、「誰から何を入手するか」を明記します）：要件資料、コードリポジトリと比較ベースライン（base ブランチ／tag／commit。フェーズ 7 で回帰範囲を決める基準となるため、要件モデルファイルのヘッダーに記録し、再開時に基準情報が欠けるのを防ぎます）、テスト環境とアカウント

2. チェックポイントの確認（再開）

再開する際は、まず {プロジェクト}/パイプライン状態.md を読み込みます。未決事項にユーザーが判断を記入済みの場合は、該当するフェーズの成果物を差分修正してから（要件モデルの前提を更新する、budget_review に approved_by: ユーザー を追加するなど。フェーズは再実行しません）、以下の基準に従って再開します。未記入の未決事項は保守的な分岐を維持し、未決のマークも残します。判断済みとして扱ってはいけません。次に {プロジェクト}/ 内の既存の成果物を確認し、最後に完了したフェーズの次から再開します。完了済みのフェーズはやり直しません。フェーズ完了の判定基準（フェーズ 3／4 は成果物名が同じです。ファイルの存在だけで推測せず、判定基準で区別してください）：

• フェーズ 1：要件モデル.md が存在する
• フェーズ 2：テスト戦略.md が存在し、../core/scripts/validate_schema.py の V1–V5 に合格している（type_scope に handoff／blocked の軸または外部実行器が含まれる場合、対応する 特別引き継ぎ_{軸}_{日付}.yaml が生成済みであること）
• フェーズ 3：テストケースが 2 つの形式でディスク上に保存され、../core/scripts/validate_schema.py {テストケースファイル}（テストケース Schema の単一ファイル検証）に合格している
• フェーズ 4：テストケースファイルの末尾に test-case-review の署名を含むレビュー記録セクション「## レビュー記録（test-case-review …）」があり、Schema が再抽出・検証済みであること。フェーズ 3 の作成時の自己レビューによる同名の「レビュー記録」セクションは対象外です（これはフェーズ 3 の完了マークです。再開時に独立したレビューが誤って省略されないよう、両者を区別します）
• フェーズ 5：テストレポート_{ソース}_{日付}.md（自動パス）または 手動実行記録_{日付}.md（手動パス）がディスク上に保存されている
• フェーズ 6：中継ファイル バグ項目_{日付}.md がディスク上に保存されている。バグがない場合は、{プロジェクト}/パイプライン状態.md に「フェーズ 6：確認済みのバグなし、スキップ」という行を追加します（スキップ／未決など、パイプラインの状態は一律このファイルに記録します。再開に必要な記録は、ルール 3「状態はすべてファイル内」に従います。この行がない場合、フェーズに到達していないものと見なします）
• フェーズ 7：回帰チェックリスト_{日付}.md がディスク上に保存されている。コード変更がない場合は、{プロジェクト}/パイプライン状態.md に「フェーズ 7：変更なし、スキップ」という行を追加します

成果物がない、または破損している場合は、そのフェーズから再実行します。

3. 按流水线顺序调度阶段 skill

• 每个阶段：在独立上下文中调用对应 skill（或降级为顺序调用），输入 = 上一阶段的落盘产物文件路径（不是会话记忆）
• 检查点暂停：遇到 ⏸ 环节，向用户呈现该阶段 skill 汇总的问题/提案，等待用户答复后再进入下一阶段；用户在澄清环节的明确答复具有最终裁决力（见 ../core/evidence.md 裁决规则），后续阶段不得推翻
• headless / 非交互运行（CI 流水线等无对话场景）：⏸ 检查点不等待、不代答，按 ../core/pipeline-integration.md（此时加载）约定一降级为未决项落盘——有保守默认值的取保守分支并记录依据，其余记未决项；未决项与跳过标记统一落 {项目}/流水线状态.md 未决区，人工回流回填裁决后由断点检查（§2）增量消费；带留痕要求的裁决产物（如 budget_review）按约定一第 4 条如实记 headless 未决，不得写成用户已批准
• 阶段产出落盘失败（文件未生成）→ 该阶段重跑，不进入下一阶段

4. 收尾：生成测试报告

全部阶段完成后（或用户要求提前收尾），按 ../core/report-template.md（此时加载）汇总生成 {项目}/测试报告_{日期}.md：范围、执行统计（自动运行结果与手动执行记录合并）、Bug 清单（拼装阶段 6 的 Bug条目_{日期}.md 并逐条同步状态——有回归结果的按结果更新为已验证关闭/已修复待验证，未回归的保持新建）、风险残留、回归摘要、类型域专项结果按 report-template §7 逐轴归一化回收（handoff / 外部执行 / blocked / exclude）、未闭环事项（含移交 yaml 各轴当前状态与去向）、各阶段产物路径索引、机读摘要片段（按 report-template「机读摘要片段」节生成，供报告聚合系统消费）。

5. 交付

向用户报告：最终报告路径 + 各阶段产物清单 + 未闭环事项（TODO 归属）。

硬规则

1. 不做裁决：澄清、执行策略、Bug 定性、预算裁决一律呈现问题与建议后等用户，不代替用户决定
2. 不含领域知识：测试方法、框架知识全部在阶段 skill 与 core/；本 skill 失败的唯一合理原因是编排错误，不是测试判断错误
3. 状态全在文件：任何会话中断后，凭 {项目}/ 落盘产物即可续跑
4. 阶段产物消费走文件：跨阶段传递的是产物路径，不是会话内转述

Common Mistakes

错误	后果	正确做法
把所有阶段 skill 的 SKILL.md 都加载进同一会话	指令冲突、上下文爆炸	阶段间上下文隔离，主会话只持状态
单阶段意图也启动流水线	过度执行、浪费	意图识别后移交对应阶段 skill
检查点自答（替用户裁决）	裁决失效，后续阶段基于错误假设	⏸ 环节必须等用户答复
凭会话记忆续跑（不读落盘文件）	中断后状态丢失/不一致	断点检查只认文件
编排层塞入测试方法论	破坏薄编排、难以维护	方法论全部下沉阶段 skill 与 core/
阶段 6 提前新建/改写最终测试报告	与阶段 8 收尾同名双写、双数据源	Bug 条目先落 Bug条目_{日期}.md 中转文件，收尾统一拼装
跨会话知识与流水线产物混写	知识不沉淀 / 流水线状态被污染	会话内状态看落盘产物，跨会话知识看 .qa/（qa-memory）