team-qa

チーム QA

このスキルが呼び出されると、構造化されたテストサイクルを通じて QA チームを統括します。

意思決定ポイント： 各フェーズの移行時に、AskUserQuestion を使用して、サブエージェントの提案を選択肢としてユーザーに提示します。 エージェントの分析全文を会話に記載したうえで、簡潔なラベルで決定を記録します。 collaborative モードでは、次のフェーズに進む前にユーザーの承認が必要です。 guided モードでは、フェーズが BLOCKED でない限り、パイプラインは自動的に進行します。 autonomous モードでは、各フェーズの結果を log_decision で記録しながら、最初から最後まで実行します。automation_always_ask カテゴリ（is_always_ask_category ヘルパー）に属する決定では、モードにかかわらず必ず確認を求めます。.claude/docs/automation-modes.md を参照してください。

フェーズ 0：設定の解決

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,qa.level

上記で解決済みです。そのまま使用してください。--review は review_mode を上書きします。該当ブロックがない場合 → .claude/docs/config-resolution.md のデフォルトを使用します。

qa.level によって、Logic、Integration、Config/Data ストーリーのエビデンスが決まります。standard と full では自動テスト、テストが免除される minimal（.claude/docs/coding-standards.md）ではフェーズ 5 の受け入れ基準に沿った確認です。この場合、テストのないストーリーはエビデンスが欠けているのではなく、免除済みです。UI と Visual/Feel のスクリーンショットは、すべてのレベルで必須です。

review_mode はディレクターゲートの深度を設定しますが、このパイプラインにはディレクターゲートがありません。どの review_mode でも、以下のフェーズで CD-、TD-、PR-、AD-PHASE-GATE が起動されることはありません。そのフェーズゲートはパイプライン独自の意思決定ポイント（以下の team.size の項で定義）であり、そこで作業するエージェントはチームメンバーであって、ディレクターゲートではありません。

automation は上記の Decision Points の注記を制御します。各モードがパイプラインの動作をどのように変えるかについては、上記の Decision Points の注記と .claude/docs/automation-modes.md を参照してください。

team.size：アクティブなエージェントを指定します（review_mode のゲート深度やワークフローのドキュメントとは独立しています）。

• individual（デフォルト）：qa-tester のみ。qa-lead はフェーズゲートでのみ呼び出されます。
• small：qa-lead と qa-tester によるパイプライン（ドキュメントに記載のとおり）。
• studio：qa-lead と、ストーリーごとに起動される qa-tester、および承認。 individual で必要となるコア以外のエージェントは、情報メモを添えて最も近いアクティブなコアエージェントを通じて対応します。「フェーズゲート」とは、このパイプライン自体が記載する AskUserQuestion の意思決定ポイントで終わるあらゆるフェーズを指します。つまり、上記の Decision Points にある移行、または以下のパイプラインに記載された Gate ステップです。automation モードにかかわらず、guided または autonomous で質問が省略または記録される場合も、そのフェーズはゲートです。すべてのフェーズがゲートというわけではありません。基準を文字どおりに適用してください。以下のフェーズに意思決定ポイントが記載されていない場合、そのフェーズはゲートではなく、「フェーズゲートのみ」に限定されたエージェントは起動されません。このアクティブセットの適用範囲は、以下のパイプライン全体に及びます。アクティブセット外のエージェントを指定するフェーズでは、そのエージェントを起動するのではなく、最も近いコアエージェントを通じて対応します。

フェーズ 1 の前に、必ずアクティブセットを告知してください。省略して黙って進めてはいけません。 何かを起動する前に、この実行で実際に起動するエージェントと、以下のパイプラインに記載されているものの、解決済みの team.size では起動しないエージェントを、1 行で示してください。例：

Active set (team.size: <解決された値>): <上記でそのサイズに指定されたエージェント>. Not spawned this run: <このパイプラインに記載されたその他すべてのエージェント> — consulted through <最も近いアクティブなコアエージェント>. Raise team.size (or modes.rigor) to widen.

上記の team.size の一覧と、このファイルのパイプライン自体に記載されたエージェントをもとに記入してください。例から転記してはいけません。どちらのセットもオーケストレーターによって異なります。 解決されたサイズでフェーズゲート時にのみ起動されるエージェント（individual の qa-lead など）は、その条件を添えてアクティブセットに含めます。そのエージェントは起動されるのであり、別のエージェントを通じて相談されるのではありません。

以下のパイプラインは、複数エージェントへのファンアウトとして書かれていますが、提供時のデフォルトではエージェントは 1 つか 2 つです。team-release は 10 人を記載して 1 人を実行し、team-narrative は 5 フェーズに 6 人を記載して writer のみを実行します。この縮退は意図どおりです。team.size は厳密性を優先した設定であり、狭いデフォルトはトークン節約のための設定です。これを明示しなければ、読み手は正しく縮退した実行と壊れたパイプラインを区別できません。また、上記のエージェントごとの「情報メモを添えて最も近いコアエージェントを通じて対応する」というルールは、ルーティング時に適用されるだけで、実行全体の形を明示することはありません。

これは、このファイルの他の箇所で行うスキップされたチェックの報告と同じルールです。適用されていても表に出されない制約は、出力を読む人にとって、そもそも適用されていなかった制約と見分けがつきません。

チーム構成

• qa-lead — QA 戦略、テスト計画の作成、ストーリーの分類、サインオフレポート
• qa-tester — テストケースの作成、バグレポートの作成、手動 QA ドキュメント

委任方法

Agent ツールを使用して、各チームメンバーをサブエージェントとして起動します。

• subagent_type: qa-lead — 戦略、計画、分類、サインオフ
• subagent_type: qa-tester — テストケースとバグレポートの作成

各エージェントには要点を伝え、コンテキストをそのまま渡さないでください。 共通の入力を一度だけ読み、簡潔にまとめたブリーフをインラインで渡します。各エージェントが実際に必要とする行だけを渡し、すでに読んだドキュメントのファイルパスは決して渡さないでください（パスを渡されたエージェントはファイル全体を再読します）。まだ読んでおらず、そのエージェントだけが必要とするドキュメントに限り、パスを渡してください。

すべてのエージェントへのプロンプトは、必ず次の返却条件で締めくくってください。「出力全体を [path] に書き込んでください。このパスは、以下の限定的な例外に基づく書き込み許可先として指定したものなので、別途承認を求めずに書き込んでください。返す内容は、（1）書き込んだパス、（2）判断事項の要約（箇条書きで最大5項目）、（3）BLOCKED/CONCERNS 項目（各1行）のみとしてください。読んだドキュメントの内容を再掲しないでください。」これがないと、エージェントは読んだ内容をすべてこのセッションに返してしまいます。

この例外が Collaboration Protocol に違反しない理由。 CLAUDE.md は Write/Edit の前に「このファイルパスに書き込んでもよいですか？」とエージェントが尋ねるよう定めています。ここで起動したサブエージェントは尋ねずに書き込みます。これは見落としではなく、意図的かつ限定的な例外です。consistency-check が active.md に追記するためにすでに適用されたのと同じ例外です。この例外が適用されるのは、次の3つすべてを満たす場合に限ります。（1）パスはプロンプト内であなたが指定したものであり、ユーザーはフェーズの承認時に出力先も承認していること。（2）既存のソースや設定ファイルの編集ではなく、production/、docs/、tests/ 配下に作成する新しい成果物であること。（3）成果物を作成するフェーズが、前述のフェーズゲートであること。つまり、パイプラインで、オートメーションのモードにかかわらず、次へ進む前に AskUserQuestion を実行して終了すると定められているフェーズであること。この3つに当てはまらない場合、エージェントは尋ねる必要があります。エージェントごとに尋ねることで「解決」しないでください。 フェーズごとにエージェント一体ずつプロンプトを送るとオーケストレーターが使い物にならなくなるため、この例外が設けられています。

team.size: studio の場合、フェーズ4ではストーリーごとに qa-tester を1体ずつ並列で起動します。それより小さい場合は、グループ全体を1体で担当します。

パイプライン

フェーズ 1：コンテキストの読み込み

何かを始める前に、対象範囲をすべて把握します。

1. 引数から現在のスプリントまたは機能の対象範囲を特定します。

   • 引数がスプリント識別子（例：sprint-03）の場合：production/sprints/sprint-*.md を Glob し、スプリント番号で一致させます。sprint-3、sprint-03、sprint-003 はすべてスプリント 3 を指します（/sprint-plan は sprint-NNN.md を作成します）。一致したファイルを読み込みます。複数一致した場合は、最終更新日時が最も新しいものを使用します。
   • 引数が feature: [system-name] の場合：そのシステムのタグが付いたストーリーファイルを glob します。
   • 引数がない場合：production/session-state/active.md と production/sprint-status.yaml（存在する場合）を読み込み、アクティブなスプリントを推定します。スプリントがない場合（rigor: minimal では存在しません）は、対象とするエピックを尋ね、feature: [epic-slug] を使用します。スプリントをでっち上げてはいけません。

2. project.yaml の project.stage を読み込みます（なければ production/stage.txt）。現在のプロジェクトフェーズを確認します。

3. 対象範囲内の未解決バグを読み込みます — QA で新しいバグが見つかる前に、すでに登録されているバグです。/bug-triage と同様に、production/qa/bugs/*.md の **Severity**、**Status**、**System** の各行を grep します。Status が Closed または Verified Fixed でないバグは未解決です。対象ストーリーが属するシステムのバグ、または対象ストーリーを指定しているバグが対象範囲内です。判断に迷う場合は一覧に含めます。これらはフェーズ 2 とフェーズ 6 の概要に 対象範囲内の未解決バグ として記載します。ここに未解決の S1 または S2 がある場合、QA で何が見つかるかにかかわらず、承認判定（フェーズ 6）はすでに NOT APPROVED です。バグファイルがない場合は、「対象範囲内の未解決バグ：登録なし」とします。

4. 見つかったストーリーの数を数え、次の内容をユーザーに報告します。

   「[スプリント／機能] の QA サイクルを開始します。[N] 件のストーリーが見つかりました。対象範囲内の未解決バグ：[N 件 — S1：n 件、S2：n 件、または登録なし]。現在のステージ：[stage]。QA 戦略の策定を開始してよいですか？」

フェーズ 2：QA 戦略（qa-lead）

Agent 経由で qa-lead を起動し、スコープ内のすべてのストーリーをレビューして QA 戦略を作成します。

フェーズ 1 の スコープ内の未解決バグ（ID、重大度、ストーリーまたはシステム）を qa-lead に渡し、次の作業を依頼します。

• 各ストーリーファイルを読む

• 各ストーリーを種類別に分類する：ロジック／統合／ビジュアル／操作感／UI／設定／データ

• 自動テストの証拠が必要なストーリーと、手動 QA が必要なストーリーを特定する — qa.level: minimal の場合、テストが必須のストーリーはありません。テストのないロジック、統合、設定／データのストーリーは、「自動テスト必須」の欄に WAIVED と記載し、受け入れ条件を手動 QA で確認します

• 受け入れ条件の欠落、または QA の妨げとなるテスト証拠の不足があるストーリーにフラグを付ける

• 手動 QA の工数（必要なテストセッション数）を見積もる

• スモークテストの状況を評価する前に、既存のスモークテストレポートを確認する：production/qa/smoke-*.md を Glob で検索し、見つかった場合は最終更新日時が最も新しいファイルを読む。レポートがあれば、その判定と所見を直接使用し、ユーザーに再度確認しない。レポートがなければ、「以前のスモークテストレポートが見つかりません — 続行する前に /smoke-check sprint を実行してください。」と記載し、スモークテストの状況を UNKNOWN に設定する（続行のための判定では PASS WITH WARNINGS として扱います）。スモークテストの判定を作成する：PASS／PASS WITH WARNINGS [一覧]／NOT ASSESSED [未実行の項目]／FAIL [一覧]／UNKNOWN（レポートなし）

• 戦略の概要表とスモークテストの結果を作成する：

  ストーリー	種類	自動テスト必須	手動テスト必須	ブロッカー？

  スモークテスト：［PASS／PASS WITH WARNINGS／NOT ASSESSED／FAIL／UNKNOWN］ — ［出典：production/qa/smoke-[date].md または「レポートなし」］ — ［PASS 以外の場合は詳細］

  スコープ内の未解決バグ：［BUG-ID — S[n] — ストーリーまたはシステム、1 行につき 1 件。または「記録なし」］ — 未解決の S1 または S2 は、既知の障害としてここに記載します

スモークテストの結果が FAIL の場合、qa-lead は失敗内容を目立つように列挙する必要があります。スモークテストに失敗した場合、QA は戦略フェーズを先に進められません。

qa-lead の戦略全体をユーザーに提示してから、AskUserQuestion を使用します。

question: "QA Strategy Review"
options:
  - "Looks good — proceed to test plan"
  - "Adjust story types before proceeding"
  - "Skip blocked stories and proceed with the rest"
  - "Smoke check failed — fix issues and re-run /team-qa"
  - "Cancel — resolve blockers first"

スモークテストが FAIL の場合：フェーズ 3 に進まないでください。スモークテストレポートの失敗内容を提示して停止します。ユーザーが修正し、/smoke-check sprint を再実行してから、/team-qa を再実行する必要があります。 スモークテストが UNKNOWN の場合：「スモークテストレポートが見つかりません。QA の前に /smoke-check sprint を実行することを推奨します。注意して続行します。」という警告を提示します。 スモークテストが NOT ASSESSED の場合：レポートに記載されている未実行の項目を提示します：「前回のスモークテストでは［未実行の項目］を評価できませんでした。実行可能になったら /smoke-check sprint を再実行することを推奨します。注意して続行します。」— UNKNOWN と同様に続行します。ただし、フェーズ 6 でサインオフを APPROVED にすることはできません。 スモークテストが PASS WITH WARNINGS の場合：警告をサインオフレポートに記載し、続行します。 ブロッカーがある場合：明示的に列挙します。ユーザーはブロックされたストーリーをスキップするか、サイクルをキャンセルできます。

フェーズ 3：テスト計画の作成

フェーズ 2 の戦略に基づいて、構成されたテスト計画書を作成します。

テスト計画には、以下を含めてください。

• 対象範囲：スプリント／機能名、ストーリー数、日付
• ストーリー分類表：フェーズ 2 の戦略に基づくもの
• 自動テスト要件：テストファイルが必要なストーリー、tests/ 内の想定パス（qa.level: minimal の場合はなし。その場合は免除されたストーリーを「手動 QA の対象範囲」に記載）
• 手動 QA の対象範囲：手動でのウォークスルーが必要なストーリーと、検証する内容
• 対象外：今サイクルではテストしないことと、その理由を明記
• 開始条件：QA を開始する前に満たすべき条件。必ず以下を含めてください。（1）PASS または PASS WITH WARNINGS のスモークチェックレポートが production/qa/smoke-*.md に存在すること、（2）ビルドが安定していること（起動時にクラッシュしない）、（3）スプリント対象の場合、すべての Must Have ストーリーが production/sprint-status.yaml で in-progress、review、または done であること。feature: 対象の場合、対象範囲内の各ストーリーファイルの Status が In Progress、In Review、または Complete であること。これらに加えて、スプリント固有の条件があれば追加してください。
• 終了条件：QA サイクルの完了とみなす条件（すべてのストーリーが PASS、またはバグを起票したうえで FAIL であること）

「QA 計画を production/qa/qa-plan-[sprint]-[date].md に書き込んでもよろしいですか？」と尋ねてください。

承認を受けてから書き込んでください。

フェーズ 4：テストケースの作成（qa-tester）

スモークチェックはフェーズ 2（QA 戦略）の一環として実施します。フェーズ 2 でスモークチェックが FAIL となった場合、そこでサイクルは停止します。このフェーズは、フェーズ 2 のスモークチェックが PASS、PASS WITH WARNINGS、NOT ASSESSED、または UNKNOWN の場合にのみ実行します。

手動 QA が必要な各ストーリー（ビジュアル／操作感、UI、自動テストのない統合。さらに qa.level: minimal でテストが免除される場合、テストのないロジック、統合、設定／データの各ストーリー。これらのケースでは受け入れ条件を確認します）について、Agent 経由で qa-tester を起動します。team.size: studio の場合はストーリーごとに 1 つずつ、並行して起動します。small と individual の場合は、グループ全体を対象に 1 つ起動します。各ストーリーについて、以下を提示してください。

• ストーリーファイルのパス
• そのストーリーに関する QA 計画の該当セクション
• テスト対象システムの GDD 受け入れ条件（入手可能な場合）
• すべての受け入れ条件を網羅する詳細なテストケースを作成する指示
• 出力先パス：production/qa/test-cases/[story-slug]-cases.md。 ストーリーごとに 1 つ指定し、プロンプト内に明記してください。

出力先をオーケストレーターに任せず、ここで指定する理由。 上記の書き込み制限の例外は、「プロンプトであなたが指定したパス」である場合に限られます。このフェーズではエージェントを並行して起動するため、出力先を指定しないと最も大きな問題が起こります。各エージェントがそれぞれ独自に出力先を決め、同じ成果物が 2 つの実行で別々の場所に保存されてしまいます。2 つのエージェントが出力先を必要とする直前までは、このフェーズの指示に問題はないように見えます。

各テストケースのセットには、以下を含めてください。

• 前提条件：テスト開始前に必要なゲームの状態
• 手順：番号付きで、曖昧さのない操作
• 期待結果：想定される動作
• 実際の結果：テスターが記入できるよう空欄にする
• 合否：空欄にする

実行前に、テストケースをユーザーに提示してレビューを受けてください。ストーリーごとにまとめてください。

ストーリーグループごとに AskUserQuestion を使用してください（1 回につき 3～4 グループ）：

question: "Test cases ready for [Story Group]. Review before manual QA begins?"
options:
  - "Approved — begin manual QA for these stories"
  - "Revise test cases for [story name]"
  - "Skip manual QA for [story name] — not ready"

フェーズ 5：手動 QA の実行

承認済みの手動 QA リストにある各ストーリーを順に確認します。

ストーリーを 3～4 件ずつのグループに分け、各グループで AskUserQuestion を使用します。テスターの回答を待ち、テスターが述べた内容だけを記録します。テスターが伝えていない結果を、代わりに記入してはいけません。回答がなかったストーリーは未実行のままとし、サインオフは NOT ASSESSED になります。テスターがそう述べない限り、BLOCKED にはなりません。

question: "Manual QA — [Story Title]\n[brief description of what to test]"
options:
  - "PASS — all acceptance criteria verified"
  - "PASS WITH NOTES — minor issues found (describe after)"
  - "FAIL — criteria not met (describe after)"
  - "BLOCKED — cannot test yet (reason)"

FAIL の結果が出るたびに、AskUserQuestion を使って失敗の説明を聞き、その後 Agent 経由で qa-tester を起動し、production/qa/bugs/ に /bug-report の形式で正式なバグレポートを作成させます。Severity と Priority のラベルは、/bug-report のテンプレートに記載されているとおり（S2-High、P1-Fix this sprint、…）正確に記載してください。/bug-triage がこれらを解析するためです。

Visual/Feel または UI ストーリーで PASS または PASS WITH NOTES になったら、その証拠を production/qa/evidence/ に記録してください。 保存されたスクリーンショットが証拠になります。テスターに、ストーリーで対象となった画面または効果ごとにスクリーンショットを 1 枚ずつ production/qa/evidence/[story-slug]/ に保存してもらい、ディスク上にあることを確認します。/story-done が確認するのは保存された画像であり、文章だけではありません。UI ストーリーはこれらのスクリーンショットによってクローズされます。Visual/Feel ストーリーでは、さらにリードのサインオフが必要です。その後、「[story titles] の証拠を production/qa/evidence/ に書き込んでもよいですか？」と、ストーリーの各グループにつき 1 回尋ね、.claude/docs/templates/test-evidence.md を基に、スクリーンショットを参照し、サインオフ表をそのまま残した証拠成果物 production/qa/evidence/[story-slug]-evidence.md を作成します。スクリーンショットが保存されていない場合は、そのストーリーについて、保存済みの証拠が不足していることをフェーズ 5 の概要に記載してください。スクリーンショットがあるかのように示す文書を作成してはいけません。

これは任意の事務作業ではありません。次のスキルが判定に使用する成果物です。 /story-done は Visual/Feel および UI ストーリーについて production/qa/evidence/ をグロブ検索し、サインオフ表を読み取ります。/story-readiness、/test-evidence-review、gate-release も同じディレクトリを参照します。別の場所に書き込むと、ここで手動 QA サイクルに合格したストーリーが、/story-done に視覚的な証拠がないと指摘されることがあります。Visual/Feel および UI のゲートはデフォルトで BLOCKING のため、QA に合格してもストーリーをクローズできない状態になります。これは、testing.strict.ui または .visual が明示的に false に設定されている場合に限り、単に混乱を招くフラグにとどまります。

このセッションで実際にサインオフが行われていない限り、サインオフの行にはチェックを付けないでください。承認に事前にチェックが付いた証拠ファイルは、何もない場合より悪い状態です。署名がないことを、署名済みとして記録してしまうためです。

バグレポートの命名規則：BUG-[NNNN].md。番号は /bug-report と同じ方式で、production/qa/bugs/ 内の最大 ID に 1 を加え、4 桁になるようゼロ埋めします。これにより、/bug-report verify と close が ID でレポートを検索できます。

すべての結果を収集したら、次のように要約します。

• PASS のストーリー：[count]
• PASS WITH NOTES のストーリー：[count]
• FAIL のストーリー：[count] — 起票したバグ：[IDs]
• BLOCKED のストーリー：[count]

フェーズ 6：QA サインオフレポート

Agent 経由で qa-lead を起動し、フェーズ 2～5 のすべての結果を使ってサインオフレポートを作成させます。ここでの返却契約は、返信に含まれるレポート本文です。ファイルではありません。 オーケストレーターがこのフェーズの最後に確認を求めてからサインオフレポートを書き込むため、qa-lead は何も書き込みません。

証拠と以下の判定ルールを qa-lead に伝えてください。判定結果は絶対に伝えてはいけません。 戦略表、スモークチェックの判定とその根拠、各ストーリーの結果、フェーズ 5 で起票したバグ、フェーズ 1 の スコープ内のオープンバグ、および以下の判定ルールを、そのまま渡してください。判定結果を述べたり、### Verdict: の行をあらかじめ埋めたり、どの事実で判定が決まるかを伝えたりしないでください。qa-lead が証拠に基づいてルールを適用します。その後、書き込みを依頼する前に、qa-lead の判定を同じルールで確認してください。判定が食い違う場合は両方を示して確認を求めてください。自分の判定に黙って差し替えてはいけません。

サインオフレポートの形式：

## QA Sign-Off Report: [Sprint/Feature]
**Date**: [date]

### Test Coverage Summary
| Story | Type | Auto Test | Manual QA | Result |
|-------|------|-----------|-----------|--------|
| [title] | Logic | PASS | — | PASS |
| [title] | Logic | WAIVED (qa.level: minimal) | PASS — criteria walked | PASS |
| [title] | Visual | — | PASS | PASS |
| [title] | Integration | — | BLOCKED | BLOCKED — [reason]; no executed evidence |

### Bugs Found
| ID | Story | Severity | Status |
|----|-------|----------|--------|
| BUG-0001 | [story] | S2 | Open |

[every open bug in scope — those Phase 1 found on file and those filed in Phase 5]

### Verdict: NOT ASSESSED / APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED

**Conditions** (if any): [list what must be fixed before the build advances]

### Next Step
[guidance based on verdict]

スコープ内のすべてのストーリーについて、テストカバレッジ概要に行を設けます — BLOCKED のストーリーや未実行のストーリーも対象に含め、Result に理由を記載します。これにより、実行されなかったストーリーがレポートから漏れることはありません。

判定ルール：

順序。 まず NOT APPROVED を確認します。スコープ内に未解決の S1/S2 バグがある場合（Phase 1 ですでに記録されていたものも、Phase 5 で記録されたものも同様）、または文書化された回避策のない FAIL のストーリーがある場合、未実行のものがほかにあっても判定は NOT APPROVED です。既知の失敗は未知の状態より優先されます。これを NOT ASSESSED に格下げすると問題を覆い隠すことになります（.claude/rules/skill-authoring.md、obligation 1）。

次に前提条件を確認します。 APPROVED と APPROVED WITH CONDITIONS のどちらも、スコープ内のすべてのストーリーについて、実行済みの証拠が得られていることが必要です。つまり、実行されたテスト、または実施された手動テストケースが必要です。qa.level: minimal の場合、Logic、Integration、Config/Data ストーリーの受け入れ条件の確認が実行済みの証拠になります。そのテストは WAIVED であり、欠落しているわけではありません。いずれかのストーリーが BLOCKED、未実行、または証拠なしの場合、判定はどちらの APPROVED でもなく、NOT ASSESSED です。Phase 2 のスモークチェックが UNKNOWN（レポートが見つからない）または NOT ASSESSED の場合も、ビルドの健全性が確認されていないため、NOT ASSESSED になります。

• NOT ASSESSED — NO EVIDENCE：1 つ以上のストーリーで実行済みの証拠が得られていません（BLOCKED、qa.level の standard/full に準拠したテストが未作成、ケースが未実施、またはスモークチェックが FAIL／UNKNOWN／NOT ASSESSED）。これは 合格でも 不合格でもありません。QA が実施されなかったことを意味します。該当するストーリーと理由を明記してください。
• APPROVED：すべてのストーリーが PASS または PASS WITH NOTES で、未解決の S1/S2 バグがない
• APPROVED WITH CONDITIONS：S3/S4 バグが未解決、または PASS WITH NOTES の問題が文書化されていて、S1/S2 バグはない
• NOT APPROVED：S1/S2 バグが未解決、または文書化された回避策のない FAIL のストーリーがある

前提条件が必要な理由。 その下の 3 つのルールは、すべてのストーリーが PASS または FAIL になることを前提としています。何も実行されなかったスプリントでは NOT APPROVED の条件に該当せず、「未解決の S1/S2 バグがない」という条件を自明に満たします。実行済みのテストが 0 件なら、観測された失敗も 0 件になるためです。この前提条件がなければ、ルールを文字どおりに解釈した場合、まったくテストされていないビルドでも APPROVED になり得ます。意図的に NOT APPROVED とした qa-lead も、ルールの文面に根拠がないと判断することになります。サインオフは検証済みの品質を保証するものです。この前提条件がなければ、ルールでは「品質が確認されている」状態と「未確認」の状態を区別できません。

判定別の次のステップ：

• NOT ASSESSED：「QA は完了していません。不足している証拠を用意してください。Logic テストを作成する（qa.level が standard/full の場合）、または免除されたストーリーの受け入れ条件を確認する（minimal の場合）、手動テストケースを実施する、/smoke-check を実行するなどしてから、/team-qa を再実行してください。この判定のままビルドを次に進めないでください。」
• APPROVED：「ビルドは次のフェーズに進む準備ができています。/gate-check を実行して、次への移行を検証してください。」
• APPROVED WITH CONDITIONS：「次に進む前に条件を解消してください。S3/S4 バグは仕上げの工程まで延期できます。」
• NOT APPROVED：「次に進む前に S1/S2 バグを解消し、/team-qa を再実行するか、対象を絞った手動 QA を行ってください。」

次のように確認してください：「この QA サインオフレポートを production/qa/qa-signoff-[sprint]-[date].md に書き込んでもよろしいですか？」

承認を受けてからのみ書き込んでください。

エラー復旧プロトコル

まず、成果物を確認してください。 戻り値の契約でパスが指定されている場合は、そのフェーズが完了したと判断する前に、パスが存在することを確認してください。指定された成果物がディスク上にない場合、どれほど流暢な応答でも、そのフェーズは失敗です。 エージェントがフェーズ全体を費やしたうえで、何も書き込まずにもっともらしい前置きを返すことがあります。これは BLOCKED でもエラーでも「完了できない」でもないため、以下のトリガーは作動しません。未達成の契約を明示して再開してください。通常、コンテキストはそのまま残っています。

起動したエージェントから BLOCKED、エラー、または完了できないという報告があった場合は、直ちに明らかにし、そのエージェントが妨げている依存関係を越えて先に進まず、必ず部分レポートを作成してください。 手順の全容は .claude/docs/error-recovery-protocol.md を参照してください。

よくあるブロッカー：

• 入力ファイルがない（ストーリーが見つからない、GDD が存在しない）→ ファイルを作成するスキルに誘導します
• ADR のステータスが Proposed → 実装しないでください。決定されたら、/architecture-decision accept ADR-NNNN で承認します
• スコープが大きすぎる → /create-stories で 2 つのストーリーに分割します
• ADR とストーリーの指示が矛盾している → 矛盾を明らかにし、推測で判断しないでください

出力

以下を網羅した概要：対象範囲のストーリー、スモークチェックの結果、手動 QA の結果、登録したバグ（ID と重大度を含む）、最終判定（APPROVED／APPROVED WITH CONDITIONS／NOT APPROVED／NOT ASSESSED）。

判定：COMPLETE — QA サイクルが完了しました。 判定：BLOCKED — スモークチェックが失敗したか、重大なブロッカーによってサイクルを完了できませんでした。部分レポートを作成しました。

セッション状態の更新

最終フェーズの完了後（サインオフレポートの作成、または BLOCKED 判定に到達した後）、production/session-state/active.md に次の内容を黙って追記します。