qa-report

実ユーザーのためのQA計画

積み重なるテストケースではなく、実際の人々がたどるジャーニーとしてQAを計画します。このスキルは、プロジェクトの継続的なQAドキュメント（コミット済みの単一ツリー <qa-docs-path>、既定値は docs/qa/）を管理します。各ラウンドでこのツリーに追記し、qa-execution が実行するペルソナ主導のセッションを計画します。

すべての基準となるルールは2つです。

1. ラウンドごとの成果物ではなく、継続的なドキュメント。 長期的に保持するQAの知識はすべて、コミット済みの単一ツリーに保存します。各ラウンドでそこに追記します（構成、永続性、アンチパターンについては references/qa-docs-layout.md を参照）。
2. ケースではなく、セッション。 計画の最小単位はセッション憲章（ペルソナ＋ジャーニー＋ツアー＋時間枠）で、ジャーニーのフローチャートから導きます。網羅性とは「今サイクルで、計画したすべてのジャーニーをペルソナが実際にたどったこと」を意味します。管理するのはセッション台帳であり、ケースごとの件数ではありません。

関連する手順に進む前に、依頼された変更に基づいてスモーク／対象限定／全体の範囲を選択します。現在のペルソナ、ジャーニー、憲章、エビデンスを再利用し、必要なスキーマや手順を定めているリファレンスのセクションだけを読みます。対象限定の更新では、QAツリー全体を再構築したり監査したりしません。

必須入力

• qa-docs-path（任意）：継続的なツリーのルート。既定値はリポジトリルートの docs/qa です。長期的に保持されるコミット可能な場所とし、一時ディレクトリは使用しません。明示的に指定されたパスを尊重し、指定がない場合はリポジトリ管理下の永続的なツリーを既定で使用します。出力先が未確定の場合に限り、確認してください。

手順

Step 1 — ツリーの解決または初期化。 references/qa-docs-layout.md（標準ツリー、gitignore ブロック、初期化手順、散在するレガシー成果物の取り込み手順）を読みます。<qa-docs-path> を解決します。ツリーが存在する場合は、まずその README.md と、影響を受ける scenarios/ および関連する未解決の bugs/ を調べ、以下のすべての判断の基盤とします。ブランチで並行QA作業をマージした直後の場合は、計画前に内容を整理します。同じ動作または症状を記述するファイルが2つある場合は、古いIDに統合します（last_report の新しい順に判定フィールドをマージし、参照を更新して重複を削除し、その統合内容をサイクルのレポートに記録します）。ツリーが存在しない場合は、レイアウトのリファレンスに従って初期化します。ディレクトリツリー、初期データを入れた templates/、gitignore ブロックを用意します。レガシーQA成果物の取り込みは、その移行が対象に含まれる場合に限って行います。通常の対象限定更新では、過去のエビデンスを保持します。

Step 2 — プロジェクトのペルソナを確定。 references/personas.md（初期カタログ＋導出ルール）を読みます。ペルソナは <qa-docs-path>/personas.md に保存する永続的なインスタンスデータです。製品の対象ユーザーが変わった場合にのみ更新します。ファイルが存在しない場合は、対象となるジャーニーに必要なペルソナを定義します。対象ユーザーの網羅に必要な場合は、カタログを拡張します。

Step 3 — シナリオを作る前に、ジャーニーをフローとしてマッピング。 references/journeys-and-flows.md（ジャーニーの構成、Mermaid によるマッピング、マトリックスより先にフローを作る手順）を読みます。マッピングの範囲を定めます。ブランチ／PRサイクルでは、差分に含まれるユーザーに見える変更をすべて対象とします。リリースサイクルでは、製品の価値の高いジャーニーを対象とします。それぞれについて <qa-docs-path>/journeys/J-<slug>.md を作成または更新します。YAML形式のジャーニーマップに加え、開始地点 → 操作 → 分岐点 → 副作用 → 実際の最終状態を示す Mermaid フローチャートを記述し、少なくとも1つの途中離脱経路を含めます。まずフローをマッピングし、そこからシナリオを導きます。

Step 4 — シナリオを導出してトラッカーに記録。 references/state-schema.md（フィールド、列挙値、IDの採番方法を厳密に定義）と references/taxonomy.md（5つの網羅性の観点）を読みます。各フローチャートをたどってシナリオを導出します。各シナリオにつき scenarios/<AREA>-<slug>.md ファイルを1つ作成し、内容に基づくIDを付けてファイルをその場で更新し、重複する部分は overlaps フィールドに記録します。変更されたジャーニーに関連する分類軸を使用します。リリース全体の計画では、5つすべての分類軸を確認できます。シナリオファイルは計画の成果物です。qa-execution が実行するまでは qa_status を untested のままにします。 ステップ 5 — セッションのチャーターを計画します。 references/session-charters.md（チャーターの構成要素、実施頻度のティア、カバレッジの逆転）を読みます。実施頻度のティア（smoke / targeted / full / sanity）を選びます。ティアによって対象のジャーニーが決まります。各セッションにつき1つのチャーターを、<qa-docs-path>/templates/charter.md（ひな型：assets/charter-template.md）を使って <qa-docs-path>/charters/CH-<slug>.md に作成し、見出し（ミッション、ペルソナ、ジャーニー、1つだけのツアー、時間枠、必ず試すべき項目のガイダンス）を維持します。リスクの高い順に並べ、影響が最も大きいジャーニーと影響範囲が最も広いツアーの組み合わせを最初にします。ミッションが今も適合する既存のチャーターがあれば、同じ内容の別チャーターを書く前に再利用します。

ステップ 6 — バグを登録します。 references/bug-registry.md（ID の採番、重複排除、両スキル共通の標準的な深刻度モデルである、ユーザーへの影響を測る5段階の基準）を読みます。登録前に重複を確認します。症状について <qa-docs-path>/bugs/ を検索し、重複登録せず既存ファイルを更新します。再発見されたバグの履歴は、1つのIDにまとめて保持する価値があります。真に新しい症状の場合に限り、新しいコンテンツアドレス方式のID BUG-<YYYYMMDD>-<slug> を採番し、<qa-docs-path>/templates/bug.md（ひな型：assets/bug-template.md）からファイルを作成して、見出しを維持します。そのIDを、影響を受けるシナリオファイルの bug_ids に追加します。

ステップ 7 — サイクルの完全性を検証します。 新規サイクルまたは full サイクルでは、次の計画上の要件を確認します。targeted サイクルでは、変更のないマップとチャーターを再利用し、影響を受ける項目のみを確認します。不足があれば、内容を水増しせず、正直に記録します。

• 対象範囲内の各ジャーニーに、実際の終了状態と1つ以上の離脱経路を示すフローチャートがあること。
• 対象範囲内の各ジャーニーに、割り当てられたペルソナを含むチャーターが1つ以上あること。
• 対象範囲内の各シナリオファイルに、コンテンツアドレス方式のID、関連付けられたジャーニー、実態を反映した qa_status があること。
• 未解決の各バグに、登録ファイルがあり、1つ以上のシナリオの bug_ids に記載されていること。
• 各ジャーニーについて、5つの分類軸を検討していること。検討しなかった軸があれば、その理由を記録すること。

完全性の基準は「各ジャーニーをペルソナが実際にたどったこと」です。これはセッション単位の記録であり、ケース数ごとの記録ではありません。ケースを積み上げることこそ、このスキルが防ぐべき失敗です。

ジャーニーが安定した、またはリグレッションが起きやすくなり、自動 E2E 仕様に値するようになったら、references/automation-backlog.md の該当セクションを読み、意図を <qa-docs-path>/automation-backlog/ 内のファイルとして1つ記録します。バックログは1つにまとめ、個々のシナリオやチャーターに自動化用のフィールドを追加してはいけません。

関連スキル

• qa-execution — このスキルが計画したセッションを実施し、結果（ステータス、バグ、レポート）を同じツリーに書き戻します。このツリーが継続的に更新されることが、両スキル間の契約です。
• agent-output-audit — CI 検証ゲート、AI テストの衛生状態スキャン、タスクステータスの整合確認を担当します。技術的な統合、セキュリティ、パフォーマンス、負荷の各テストスイートは、そちらまたは専用ツールに振り分けます。振り分けの判断を記録し、作業を取り込まないでください。

エラー処理

• シナリオファイルのフロントマターを解析できない場合（区切りの欠落、不明なフィールド、ネストされた値）：後続の手順に進む前に修復し、修復内容を報告します。各手順は、読み込み可能なトラッカーを前提とします。
• 異なるスラッグの2つのファイルが、同じ挙動または同じ症状を記述している場合（並行する QA ブランチのマージ後によく発生）：後続の手順で重複を前提に計画を立てる前に、ステップ 1 の統合を実行します。
• ブランチサイクルの差分にユーザーから見える変更がない場合： その旨を伝えて停止します。ドッグフーディングの対象はありません。サイクルを埋めるためにシナリオを作り出してはいけません。
• <qa-docs-path> を作成できない場合（権限、読み取り専用のチェックアウト）：エラーを伝えて停止します。一時ディレクトリに切り替えてはいけません。