Create E2e Ci

---
name: create-e2e-ci
description: "プロジェクトのリポジトリに、外部との境界をモックに向けたe2eテスト（Playwright）と、依存の監査・型検査・テスト・e2eを動かすGitHub ActionsのCIを作る。e2eのケースは検証スキルの機能一覧から出し、承認された計画の一覧を書く。'/create-e2e-ci'、'e2eテストを入れて'、'CIでe2eを回したい'で使う。"
disable-model-invocation: true
---

# モックを相手にしたe2eのCIの生成

PRを開くと、CIでモックとアプリを起動し、利用者と同じ操作でe2eテストを動かし、結果とスクリーンショットがPRに付く状態を、プロジェクトのリポジトリに作る。外には何も作らない。プレビュー環境は`/create-preview-env`が作り、このスキルが作ったモックを使う。

## 1. リポジトリに聞く

次をコードベースから答え、観測できないことだけをユーザーに聞く。

- **アプリ**: フレームワークと版、ビルド・起動・型検査・テストのコマンド、ロックファイル（パッケージマネージャー）
- **環境変数**: 名前と用途（`src/env.ts`、`.env.example`、READMEなど）。値は読まない。`.env`を開かない
- **外部との境界**: 環境変数で向き先を変えているURLや、資格情報を使う通信。e2eでは、ここをモックに向ける
- **既存のモック**: 開発用のモックサーバー、フィクスチャ、MSWなど。あれば使い、二重に作らない
- **既存のテストとCI**: Playwrightなどのe2e、`.github/workflows/`。あれば、そこに足す
- **状態の分離**: e2eが使うポート、データ、結果の出力先と、同時に2つ動かせるか。手元の開発サーバーや別の検証と取り合わないようにする。既存の分離で足りれば、新しい仕組みは足さない
- **検証スキル**: `.claude/skills/verify-<app>/`と、その`features/`の機能一覧。操作手段（セレクタ、起動の手順）とケースの候補はここから取る。なければ、先に`/create-verification-skill`を実行するよう伝えて止まる

## 2. 計画を示して承認を得る

次を会話に示し（作業の重さがレベル2なら`spec`の仕様書にし）、ユーザーの承認を得る。

- **ケースの候補**: 機能一覧の「動いたと言える観測可能な結果」から、1行に「操作 → 期待する結果」と対応する機能を書く。期待する結果は`spec`の受け入れ条件と同じ基準で決め、今の実装の動きを正解の根拠にしない。保存・更新は開き直したあとの状態まで、不正な入力は変更・送信されないことまで含める。画面の経路を確かめるケースを、APIの直接呼び出しで代用しない。スクリーンショットを保存しただけで、描画が正しいとは判定しない。候補ごとに、確かめない範囲（例: 線の描画は目視）も書く。モックの状態を変えて見る異常系（データなし、上流のエラー）も候補にする。テストしないこと（理由付き）も添える。承認された計画の一覧にあるケースを実装し、ユーザーが外したケースは実装しない。1ケース1本にする
- **モック**: 既存のものを使うか、新しく作るか。新しく作るなら、境界の応答の形（正常、空、エラー、認証の失敗）をコードとテストから読んで作る。モックはe2eと、`/create-preview-env`のプレビューの両方から使える形にする（別プロセスのサーバーだけでなく、アプリに同梱して有効・無効を切り替えられる形を選べるようにする）。本番と手元の既定の動きは変えない
- **足す依存と版**: `@playwright/test`など。新しいパッケージは週間DL数、メンテナー、最終更新日を確かめ、公開から数日たった版に固定する
- **作るファイル**: テスト、Playwrightの設定、モック、ワークフロー、READMEの節

## 3. 作る

- **テスト**: 検証スキルの操作手段に合わせ、ARIAのロールやラベル、data属性など安定したセレクタを使う。内部のsetterやテスト専用のエンドポイントではなく、利用者と同じ経路を通す。Playwrightの`webServer`で、モックとアプリの起動と準備完了の判定を書く。各テストにケースIDのタグを1つ付ける（`{ tag: '@case:<id>' }`）
- **対応表**: 抽出器がある構成（今はSvelteKitとHono）では、`.claude/bin/e2e-inventory-sveltekit.ts write`か`.claude/bin/e2e-inventory-hono.ts write --app <file>`で`e2e/ledger/inventory.json`を作り、`e2e/ledger/scenarios.json`に、抽出した対象ごとに受け持つケースか理由付きの例外を書く。受け持つケースのない対象には、ケースを足す。足せない理由があれば例外か`pending`にする。`tsconfig.json`の`include`に`.claude/bin/*.ts`を足す。`.claude/bin/`に抽出器と`verify-map`がなければ、`~/.claude/references/verification-map.md`の「つなぎ方」に従って入れる。書き方は`~/.claude/references/verification-map.md`に従う
- **APIのテスト**: 画面から呼ばれないAPIなど、e2eで受け持てない`api`・`action`の対象があれば、計画のケースの候補に、APIのケース（`runner: "api"`。DB・外部APIをモックしたVitestのテスト。書き方は`write-api-case`）を挙げてよい。画面の経路を確かめるケースは、APIのケースで代用しない。Vitestの設定は`strictTags: false`にする
- **機能一覧**: ケースのIDを、確かめるサブ機能の札に書く（`［e2e: <id>］`、APIのケースは`［api: <id>］`）。ケースがサブ機能の一部だけを確かめるなら範囲付きの札にし、残りの範囲に`手動`か`未確認`の札を付ける。書き方は`~/.claude/references/verification-map.md`に従う
- **ワークフロー**: [`references/workflows.md`](references/workflows.md)に従う
- **資格情報**: 本物の資格情報を使わない。モックの資格情報はダミーの値にし、ワークフローに直接書いてよい。モックで確かめたことを、実際の認証や外部サービスとの接続の証拠にしない。接続を変える作業では、モックでは確かめられない範囲を別に挙げる
- **README**: e2eの節を足す（手元での動かし方、ケースの足し方）

区切りごとに、手元で型検査、テスト、e2eを通してから次に進む。

## 4. 渡す前に1回動かす

ユーザーの承認を得て作業用のブランチをpushし、試験用のPRを開く。次を確かめ、対象リポジトリの`.tmp/evidence/<task>/evidence.md`に残す（形式は`~/.claude/references/evidence.md`）。

- CIで監査、型検査、テスト、e2eが動き、結果とスクリーンショットのリンクがPRのコメントに付く。pushし直してもコメントが増えない
- 実装したケースが、期待する理由で通る。1つのケースの期待値をわざと変えて落ちることを手元で確かめ、元に戻す（落ちないテストは条件を検証していない）
- ケースごとに、その回の実行結果を成功・失敗・不安定（再試行で通った）・スキップ・未実行に分けて照合する。結果にないケースや、前回の結果を、成功に数えない。実行前に前回の結果ファイルを消すか証拠へ移し、今回の実行が書いた結果だけを読む。照合は`python3 .claude/bin/verify-map check --skill <検証スキル> --results <PlaywrightのJSON>`で行い、不整合なしにする
- 手元の開発コマンドが今までどおり動く

失敗したら直してから渡す。直せなければ、原因と止まった箇所を報告する。

## 5. 伝える

日々の変更では、`playbook`の手順書に沿って、変更した機能の一覧と対応表とe2eを一緒に直し、足りないケースはAIが`/write-e2e-case`（画面）か`/write-api-case`（API）で書いて対応表に載せ、e2eを動かすと伝える。落ちたケースの直し方も同じスキルにある。プレビューも要るなら`/create-preview-env`を案内する。

生成したファイルのコミットは、ユーザーの依頼か承認を経て、CLAUDE.mdのGitの規則に従って行う。