/dev-webtest-plan

name: dev-webtest-plan
description: This skill should be used when the user asks to "dev-webtest-plan", "Webテスト計画を生成", "テスト計画を作成", "webtest plan", "E2Eテスト計画", "画面テスト計画", "generate webtest plan", "create test plan from requirements", "webtest計画を更新", "テスト計画の差分更新", "update webtest plan", "画面仕様からテスト更新". dev-planの出力からPlaywright用のWebテスト計画ファイルを自動生成する。画面仕様の変更差分からテスト計画を更新する差分更新モードも対応。
argument-hint: '<dev-plan-name> | update [plan-name]'

Dev Webtest Plan

dev-plan の出力（acceptance-criteria.md の Given/When/Then、タスクファイルの Test Strategy 等）から、dev-webtest が実行する Playwright 用 Web テスト計画ファイルを自動生成するスキル。画面仕様ドキュメント（Screen Spec）の変更差分から既存テスト計画を更新する差分更新モードも備える。

前提知識

dev-* スキルフロー内の位置

dev-context → dev-plan → [dev-webtest-plan] → dev-impl → dev-verify → dev-webtest
                              ↓                                           ↑
                    docs/dev/webtests/plans/*.md ─────────────────────────┘

dev-screen-spec → [dev-webtest-plan update] → dev-webtest
                        ↓ (差分更新)              ↑
              docs/dev/webtests/plans/*.md ───────┘

引数フォーマット

/dev-webtest-plan <dev-plan-name>          # 新規生成モード
/dev-webtest-plan update                   # 差分更新モード（全webtest計画対象）
/dev-webtest-plan update <plan-name>       # 差分更新モード（特定webtest計画のみ）

• `dev-plan-name`: 既存の Plan 名（`docs/dev/plans/<dev-plan-name>/` が存在すること）
• `update`: 差分更新モードのキーワード
• `plan-name`: 更新対象のwebtest計画名（省略時は全計画を対象）

モード自動判定

引数で自動判定する（ユーザー質問不要）:

引数が "update" で始まる → 差分更新モード
それ以外 → 新規生成モード（現行通り）

新規生成モードのサブ判定

acceptance-criteria.md の存在で自動判定する:

| モード | 判定条件 | 特徴 | |-------|---------|------| | Full-spec | `docs/dev/plans/<name>/acceptance-criteria.md` が存在 | AC の Given/When/Then から直接変換（🔵 多い） | | Lightweight | acceptance-criteria.md が存在しない | タスクの Test Strategy から推論（🟡 主体、🔵 なし） |

差分更新モード

| モード | 判定条件 | 特徴 | |-------|---------|------| | 差分更新 | 引数が `update` で始まる | 画面仕様の変更差分からテスト計画を更新（🟡 source: screen-spec update） |

サブエージェント制約（重要）

サブエージェントは Task ツールを使用できない（ネスト不可のアーキテクチャ制約）。そのため:

• コード探索は Glob/Grep/Read を直接使用する
• TodoWrite は使用しない（TaskCreate/TaskUpdate で進捗管理する）
• サブエージェントに渡すのはファイルパスのみ。サブエージェントが自分で Read する

コンテキスト管理戦略

メインコンテキストの肥大化を防ぐため、**中間ファイルとパス参照** を使用する:

• メインエージェントはファイルの全文を Read しない（パス存在確認・Grep での部分情報取得のみ）
• サブエージェントに渡すのはファイルパス。サブエージェントが自分で Read する
• Phase 間のデータ受け渡しは中間ファイル経由（`tmp/webtest/plan/<plan-name>/`）
• サブエージェントの返却はマーカー＋ファイルパス＋行数のみ

中間ファイル（新規生成モード）

tmp/webtest/plan/<plan-name>/
├── task-summary.md          # Phase 2a で生成（タスクサマリー）
├── explore-plan-result.md   # Phase 2a の出力（Plan 分析結果）
├── explore-code-result.md   # Phase 2b の出力（UI 要素情報）
└── design-result.md         # Phase 3 の出力（構造設計結果）

中間ファイル（差分更新モード）

tmp/webtest/update/
└── analyze-<plan-name>.md   # Phase 2 の出力（変更分析結果）

ワークフロー（新規生成モード）

> 以下は引数が `update` で始まらない場合のワークフロー。

Phase 1: コンテキスト確認と入力検証（メイン）

1. `docs/dev/context.md` の存在を確認する。存在しない場合は `/dev-context` の実行を案内して終了する 2. `docs/dev/plans/<dev-plan-name>/` の存在を確認する。存在しない場合は `/dev-plan` の実行を案内して終了する 3. **モード自動判定**: `docs/dev/plans/<dev-plan-name>/acceptance-criteria.md` の存在を確認する

• 存在する → **Full-spec モード**
• 存在しない → **Lightweight モード**

4. Full-spec 時: `acceptance-criteria.md`, `user-stories.md`, `requirements.md` のパスを記録する（Read はしない） 5. `docs/dev/plans/<dev-plan-name>/tasks/` 配下のタスクファイルパス一覧を Glob で取得する（Read はしない） 6. Grep で `status: done` のタスクがあるか確認する（Phase 2b 実行判定用） 7. タスクの Files セクションに記載されたファイルが実際に存在するか Grep + Glob で確認する（Phase 2b 実行判定用） 8. 既存 webtest plan との重複確認:

• `docs/dev/webtests/plans/` 配下を Glob で確認
• 同一 `source-plan` の webtest plan が存在する場合は AskUserQuestion で上書き確認する

9. 中間ファイルディレクトリを作成する: `mkdir -p tmp/webtest/plan/<plan-name>/`

Phase 2: 画面・フロー・API分析（Explore サブエージェント x2 並列）

**2a. dev-plan 分析**（Explore, haiku）と **2b. 実装コード探索**（Explore, haiku、オプション）を並列で実行する。API セットアップ/クリーンアップに必要なエンドポイント情報も同時に収集する。

2a. dev-plan 分析

1. `references/explore-plan-prompt-template.md` を Read で読み込む 2. テンプレートのプレースホルダーを置換する:

• `{{PLAN_MD_PATH}}` ← plan.md の絶対パス
• `{{ACCEPTANCE_CRITERIA_PATH}}` ← acceptance-criteria.md の絶対パス（Lightweight 時は「なし」）
• `{{TASK_FILE_PATHS}}` ← 全タスクファイルの絶対パス一覧（1行1パス）
• `{{MODE}}` ← "Full-spec" または "Lightweight"
• `{{TMP_DIR}}` ← `tmp/webtest/plan/<plan-name>/` の絶対パス

3. Explore サブエージェント（haiku）を起動する 4. 出力のマーカーを確認する:

• `EXPLORE_PLAN_SUCCESS` → Phase 3 へ進む
• `EXPLORE_PLAN_FAILED` → エラー理由をユーザーに報告して終了

2b. 実装コード探索（オプション）

以下のいずれかの条件を満たす場合のみ実行する:

• タスクファイルに `status: done` が1つ以上存在する
• タスクの Files セクションに記載されたファイルが実際に存在する（Glob で確認）

条件を満たさない場合はスキップし、Phase 3 で `draft: true` として設計する。

**追加探索**: API セットアップ/クリーンアップ用のエンドポイント情報も収集する:

• API仕様ファイルの自動探索（openapi.yaml, swagger.json 等）
• ルーティング定義からのCRUD APIエンドポイント抽出
• 認証フローの調査（ログインAPI、トークン取得方法）

1. `references/explore-code-prompt-template.md` を Read で読み込む 2. テンプレートのプレースホルダーを置換する:

• `{{CONTEXT_MD_PATH}}` ← context.md の絶対パス
• `{{TARGET_FILES}}` ← タスクの Files セクションから抽出したファイルパス一覧
• `{{TMP_DIR}}` ← `tmp/webtest/plan/<plan-name>/` の絶対パス

3. Explore サブエージェント（haiku）を起動する 4. 出力のマーカーを確認する:

• `EXPLORE_CODE_SUCCESS` → Phase 3 へ進む
• `EXPLORE_CODE_FAILED` → スキップ、`draft: true` で進行

Phase 3: webtest plan 構造設計（Plan サブエージェント）

API セットアップ/クリーンアップの設計も含む。Phase 2 の分析結果からAPIエンドポイント情報を活用し、各 webtest plan に実行可能な curl コマンドを設計する。

1. `references/design-prompt-template.md` を Read で読み込む 2. テンプレートのプレースホルダーを置換する:

• `{{MODE}}` ← "Full-spec" または "Lightweight"
• `{{EXPLORE_PLAN_RESULT_PATH}}` ← `tmp/webtest/plan/<plan-name>/explore-plan-result.md` の絶対パス
• `{{EXPLORE_CODE_RESULT_PATH}}` ← `tmp/webtest/plan/<plan-name>/explore-code-result.md` の絶対パス（スキップ時は「なし」）
• `{{TASK_SUMMARY_PATH}}` ← `tmp/webtest/plan/<plan-name>/task-summary.md` の絶対パス
• `{{WEBTEST_PLAN_FORMAT_PATH}}` ← `references/webtest-plan-format.md` の絶対パス
• `{{TMP_DIR}}` ← `tmp/webtest/plan/<plan-name>/` の絶対パス

3. Plan サブエージェントを起動する 4. 出力のマーカーを確認する:

• `DESIGN_SUCCESS` → Phase 4 へ進む
• `DESIGN_FAILED` → エラー理由をユーザーに報告して終了

Phase 4: TaskCreate で並列生成タスク登録（メイン）

Phase 3 の中間ファ