E2Eテスト実装

**仕様（チケットの完了条件・受入基準）**に基づき、E2Eテストを非対話で実装するスキルです。テストケースを完了条件にトレースし、実装→実行→解説まで行います。

画面を操作した動作確認が必要な場合は /demo（AIがブラウザを操作し、人間は観察して承認する）を使う。本スキルは動作確認ではなく、テストの設計・実装に専念する。

---

入力パラメータ

対象機能の指定: $ARGUMENTS

入力形式	解釈
Issue番号（例: #42）	指定Issueの機能に対するE2Eテスト
PR番号（例: PR #10）	指定PRの変更に対するE2Eテスト
機能名・パス	指定された機能に対するE2Eテスト
なし	対象を確認

---

Phase 1: テスト設計

Step 1-1: 仕様の把握

対象の仕様を把握する。テストの根拠は**仕様（完了条件・受入基準）**であり、設計書ではない。

スクリプトの実行形（重要）: 本スキルはプラグインとして配布されるため、以下で参照するスクリプトはユーザーのプロジェクトroot ではなく、プラグイン配下にある。実行する際は必ず PATH 上のランチャー経由で claude-harness-run scripts/<スクリプト名> の形式（パス・バージョン・引用符を付けない。この形だけが Bash(claude-harness-run:*) の1行で allowlist できる）を用い、相対パス scripts/<スクリプト名> では呼び出さないこと。claude-harness-run: command not found になった場合のみ bash "<プラグインルート>/scripts/<スクリプト名>" にフォールバックする（パスは引用符で囲む。プラグインルートはスキル起動時の「Base directory for this skill」から解決した絶対パス。${CLAUDE_PLUGIN_ROOT} は表記上のプレースホルダであり環境変数ではない）。フォールバックした場合はユーザーにランチャー導入を案内すること。

<!-- 正本: docs/plugin-path-conventions.md -->

• Issue/PRの場合: gh issue view / gh pr view で本文・完了条件・受入基準を取得する。加えて claude-harness-run extract-acceptance-criteria <番号> で完了条件を機械可読JSONとしても取得しておく（後続 Step 1-3 のトレーサビリティチェックの入力になる）。出力JSON形式の正本はプラグイン配下の scripts/specs/extract-acceptance-criteria.md を参照し、ここには複製しない（Read する場合はスキル起動時の「Base directory for this skill」から <base>/../../scripts/specs/extract-acceptance-criteria.md として解決する）。使うフィールドは criteria（各要素の id/text）と parse_status。この <番号> は常に Issue 番号（extract-acceptance-criteria.sh は内部で gh issue view のみを呼ぶ）。対象がPRの場合は、PR番号をそのまま渡さず、PRに紐づく Issue 番号（gh pr view <PR番号> --json closingIssuesReferences 等で特定）を渡す。紐づく Issue が無いPRの場合は Step 1-1 の「機能名」ケースと同様に扱い、このスクリプトチェックは対象外とする
• 機能名の場合（Issue番号が無いケース）: 関連チケット・コードを調査して完了条件に相当する期待挙動を特定する。この場合 extract-acceptance-criteria.sh は対象外（Issue本文が無いため）であり、Step 1-3 のトレーサビリティチェックも自動実行せず、従来通り目視でのトレーサビリティ表確認にとどめる
• 設計書がある場合は補助的に参照してよいが、テストケースの根拠は仕様に置く
• プロジェクトルートの CLAUDE.md でテスト方針・E2Eテスト実行コマンドを確認する

Step 1-2: 既存E2Eテストのパターン調査

既存のE2Eテストコードを調査し、プロジェクトのパターンを把握する:

• テストフレームワーク（Playwright, Cypress 等）
• ディレクトリ構成・ファイル命名規則
• 共通ユーティリティ・ヘルパー関数
• Page Object等の抽象化パターン（使用されている場合）
• 認証ヘルパー・テストデータのセットアップ方法

Step 1-3: テストケース設計（完了条件トレーサビリティ）

テストケースを以下の3分類で設計する:

分類	説明
正常系	ビジネス上重要なハッピーパス
異常系	エラーハンドリング・バリデーション
エッジケース	境界値・特殊条件

各テストケースを完了条件・受入基準に対応づけたトレーサビリティ表を作成し、過不足を確認する:

完了条件 / 受入基準	対応テストケース
{完了条件1}	{テストケース名}
{完了条件2}	（未カバー → 要追加）

機械可読チェック（Issue/PRが対象の場合）: 上記トレーサビリティ表と同じ内容を cases 配列のJSONとしても用意し、claude-harness-run check-e2e-traceability "<criteria.json>" "<trace.json>" を実行する（正本・所在は Step 1-1 参照）。未カバー0件・未知ID0件を返すまで設計を追補する（上限2周）。2周しても残る場合はループを打ち切り、残存する未カバー条件・未知IDを返却内容に明記したうえで次のPhaseに進む（黙って進めない）。このスクリプトが検証するのは「完了条件とテストケースの対応付けの網羅性」であり、テストが完了条件を意味的に満たしているかの検証ではない（意味的妥当性の検証は /explain-e2e の責務）。

入力が「機能名」（Issue番号が無い）の場合は Step 1-1 の記載の通りこのスクリプトチェックは適用外であり、目視でのトレーサビリティ表作成のみで代替する。

Issue/PRが対象なのに check-e2e-traceability.sh が status: no_criteria を返した場合（見出し表記揺れ・ネストリスト等でパーサが完了条件を1件も拾えなかったケース）、それは「未カバー0件を達成した」ことを意味しない。この場合は機能名ケースと同様に、目視でのトレーサビリティ表確認にフォールバックする。

---

Phase 2: 実装

設計したテストケースを、プロジェクトの既存パターンに従って実装する。

• 既存の抽象化パターン・共通ユーティリティ・認証ヘルパーを再利用する
• data-testid 属性が必要な場合は、先にコンポーネントへ追加する

e2e-engineer への委譲（任意）

実装は e2e-engineer エージェントに委譲してもよい。委譲する場合、e2e-engineer は Phase 1〜3（テスト設計・実装・全テスト実行）までを担当し、次を返却する:

• 作成・変更したテストファイル一覧
• テスト実行結果（パス／失敗／スキップ件数。全テストがパスした状態で返す。失敗があれば e2e-engineer 自身が修正・再実行する）
• 完了条件↔テストケースのトレーサビリティ表
• 残存トレーサビリティ問題（未カバー条件・未知ID。無ければ「なし」）

委譲しない場合は、本スキルの呼び出し元が Phase 3 まで実行する。いずれの場合も、Phase 3 が全パスで完了してから「次のステップ」へ進む。

---

Phase 3: 全テスト実行

CLAUDE.md の「よく使うコマンド」に記載されたE2Eテスト実行コマンドで全テストを実行する。CLAUDE.md が無い場合は先に /init-project を実行すること。失敗テストは修正し、再実行する。

trace 有効化: 後段の /explain-e2e で実行エビデンス（trace / 動画 / スクリーンショット）を参照するため、実行時は trace を有効化する（Playwright なら --trace on 等、フレームワークに応じた設定）。

## E2Eテスト実装結果

### サマリー
- 正常系: N件 / 異常系: N件 / エッジケース: N件（合計: N件）

### テスト実行結果
- パス: N件 / 失敗: N件

### 残存トレーサビリティ問題（Step 1-3 の2周チェックで解消しなかった場合のみ）
- 未カバー: {完了条件ID・内容} / 未知ID: {ID}

### 作成・変更したファイル
- {ファイルパス}: {概要}

---

次のステップ: テストシナリオ解説と独立検証

Phase 3 で全テストがパスした状態になったら、レビュー用に /explain-e2e を実行する（テスト失敗が残る場合は修正・再実行してパスさせてから進む）。 このスキルは、人間がコードを読まずにE2Eをレビューできるよう「テストシナリオ解説」（Phase 1）と「独立検証」（Phase 2）の2層を提供する。Phase 1 はメインセッションで対話的に、Phase 2 は Task ツールによる直接委譲（e2e-explanation-verifier の並列 fan-out と e2e-mutation-injector の逐次実行）として実施する。

e2e-engineer に委譲していた場合は、メインに戻ってから /explain-e2e を実行する。その際、e2e-engineer の返却内容（テストファイル一覧・実行結果・トレーサビリティ表）を /explain-e2e の入力コンテキストとして渡す。

呼び出し元がサブエージェントの場合（star 型並列実装の ticket-worker 等）: /explain-e2e は Phase 1 が対話前提のため実行せず、上記の返却内容をリードに返す。リードがメインセッションで実施する。

---

注意事項

• コンポーネントに data-testid 属性が必要な場合は、先に追加する
• メール送信を伴うテストは、送信トリガーまでの検証に留める
• テストコードはプロジェクトの既存パターンに厳密に従う