e2e-test-generator

name	e2e-test-generator
description	テスト仕様書（Excel/Notion）からFlutter integration_testコードを自動生成するスキル。 Page Objectパターン + Key規約に基づき、仕様ステップとコードの対応を示すマッピングレポートも生成する。 「E2Eテストを生成」「テスト仕様からテストコードを作って」「integration_testを生成」などの発言で発動。

Flutter E2E テスト自動生成スキル

目的

テスト仕様書（Excel / Notion）を Source of Truth として、Flutter の integration_test コードを自動生成する。 テストコードは「自然言語仕様の Dart へのデコード結果」であり、使い捨ての中間生成物として扱う。

核心思想

「壊れにくくする」のではなく「再生成コストを限りなくゼロにする」

• テスト失敗 → コードがバグっている → コードを直す（テストは正しい）
• 仕様変更 → テストが古い → テストを再生成（仕様が正しい）
• テストコードを手で保守しない。仕様書を更新し、テストを再生成する。

使用タイミング

以下の発言で発動：

• 「E2E テストを生成して」「integration_test を作って」
• 「テスト仕様書からテストコードを生成」
• 「ST-AUTH-001 のテストを生成して」
• 「マッピングレポートを作成」

前提条件

• Flutter プロジェクトであること
• テスト仕様書が存在すること（Excel ファイルまたは Notion ページ）
• integration_test/ ディレクトリが使用可能であること

---

実行フロー

Phase 0: プロジェクト解析（必須・最初に実行）

Step 0-1: プロジェクト構造の確認

1. pubspec.yaml を読み込み、以下を検出：
   - flutter_test / integration_test の依存
   - 状態管理（riverpod, bloc, provider 等）
   - ルーティング（auto_route, go_router 等）

2. lib/ のディレクトリ構造を解析：
   - 画面ファイルのパス（lib/ui/, lib/presentation/, lib/features/ 等）
   - 既存の Keys クラス（*_keys.dart）
   - 既存の integration_test/

3. 結果をユーザーに確認：
   「プロジェクト構造を解析しました：
   - UI層: lib/ui/{module}/
   - 状態管理: Riverpod
   - ルーティング: auto_route
   - 既存Keys: なし / 3ファイル検出
   この認識で合っていますか？」

ここでユーザーの回答を待つ。次のステップに進まない。

Step 0-2: Key 規約の確認

既存の Key 運用を確認し、Key 規約を提案する。

既存の Key を検索：
- `Key('...')` や `ValueKey('...')` のパターン
- 既存の Keys クラス

結果に応じて：
- 既存規約あり → それに従う
- 既存規約なし → 標準規約を提案（references/key-convention.md 参照）

ここでユーザーの回答を待つ。