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テスト計画ファイルを自動生成する。
画面仕様の変更差分からテスト計画を更新する差分更新モードも対応。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
dev-plan の出力（acceptance-criteria.md の Given/When/Then、タスクファイルの Test Strategy 等）から、dev-webtest が実行する Playwright 用 Web テスト計画ファイルを自動生成するスキル。画面仕様ドキュメント（Screen Spec）の変更差分から既存テスト計画を更新する差分更新モードも備える。
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 ツールを使用できない（ネスト不可のアーキテクチャ制約）。そのため:
メインコンテキストの肥大化を防ぐため、中間ファイルとパス参照 を使用する:
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で始まらない場合のワークフロー。
docs/dev/context.md の存在を確認する。存在しない場合は /dev-context の実行を案内して終了するdocs/dev/plans/<dev-plan-name>/ の存在を確認する。存在しない場合は /dev-plan の実行を案内して終了するdocs/dev/plans/<dev-plan-name>/acceptance-criteria.md の存在を確認する
acceptance-criteria.md, user-stories.md, requirements.md のパスを記録する（Read はしない）docs/dev/plans/<dev-plan-name>/tasks/ 配下のタスクファイルパス一覧を Glob で取得する（Read はしない）status: done のタスクがあるか確認する（Phase 2b 実行判定用）docs/dev/webtests/plans/ 配下を Glob で確認source-plan の webtest plan が存在する場合は AskUserQuestion で上書き確認するmkdir -p tmp/webtest/plan/<plan-name>/2a. dev-plan 分析（Explore, haiku）と 2b. 実装コード探索（Explore, haiku、オプション）を並列で実行する。API セットアップ/クリーンアップに必要なエンドポイント情報も同時に収集する。
references/explore-plan-prompt-template.md を Read で読み込む{{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>/ の絶対パスEXPLORE_PLAN_SUCCESS → Phase 3 へ進むEXPLORE_PLAN_FAILED → エラー理由をユーザーに報告して終了以下のいずれかの条件を満たす場合のみ実行する:
status: done が1つ以上存在する条件を満たさない場合はスキップし、Phase 3 で draft: true として設計する。
追加探索: API セットアップ/クリーンアップ用のエンドポイント情報も収集する:
references/explore-code-prompt-template.md を Read で読み込む{{CONTEXT_MD_PATH}} ← context.md の絶対パス{{TARGET_FILES}} ← タスクの Files セクションから抽出したファイルパス一覧{{TMP_DIR}} ← tmp/webtest/plan/<plan-name>/ の絶対パスEXPLORE_CODE_SUCCESS → Phase 3 へ進むEXPLORE_CODE_FAILED → スキップ、draft: true で進行API セットアップ/クリーンアップの設計も含む。Phase 2 の分析結果からAPIエンドポイント情報を活用し、各 webtest plan に実行可能な curl コマンドを設計する。
references/design-prompt-template.md を Read で読み込む{{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>/ の絶対パスDESIGN_SUCCESS → Phase 4 へ進むDESIGN_FAILED → エラー理由をユーザーに報告して終了Phase 3 の中間ファイル tmp/webtest/plan/<plan-name>/design-result.md を Read し、webtest plan の一覧を抽出する。各 webtest plan ごとに TaskCreate を実行する:
TaskCreate:
subject: "webtest-plan: <webtest-plan-name>"
description: "<webtest-plan-name> の webtest plan ファイルを生成する"
activeForm: "Generating webtest-plan: <webtest-plan-name>"
ID マッピングテーブルを構築する: {"login-form": "<TaskCreate_ID>", ...}
通常は依存関係なし（並列生成可能）。
TaskList で status: pending のタスクを取得し、各タスクについて:
in_progress にするreferences/generate-prompt-template.md を Read で読み込む{{WEBTEST_PLAN_NAME}} ← webtest plan 名{{TARGET_URL}} ← target-url{{DRAFT_FLAG}} ← true / false{{MODE}} ← "Full-spec" または "Lightweight"{{DESIGN_RESULT_PATH}} ← tmp/webtest/plan/<plan-name>/design-result.md の絶対パス{{TASK_SUMMARY_PATH}} ← tmp/webtest/plan/<plan-name>/task-summary.md の絶対パス{{EXPLORE_CODE_RESULT_PATH}} ← tmp/webtest/plan/<plan-name>/explore-code-result.md の絶対パス（ない場合は「なし」）{{WEBTEST_PLAN_FORMAT_PATH}} ← references/webtest-plan-format.md の絶対パス{{SIGNAL_GUIDELINES}} ← 信号機基準（Full-spec / Lightweight で異なる）{{ACCEPTANCE_CRITERIA_PATH}} ← acceptance-criteria.md の絶対パス（Full-spec 時のみ、Lightweight 時は「なし」）GENERATE_SUCCESS → TaskUpdate で completed にするGENERATE_FAILED → エラー理由を記録、TaskUpdate で completed（レポートに失敗として記載）ユーザーに以下のレポートを出力する:
## dev-webtest-plan 完了レポート
### 生成概要
- Source Plan: <dev-plan-name>
- モード: Full-spec / Lightweight
- 生成ファイル数: N
### 生成ファイル一覧
| ファイル | target-url | draft | シナリオ数 | 🔵 | 🟡 | 🔴 | APIセットアップ |
|---------|-----------|-------|----------|-----|-----|-----|--------------|
| login-form.md | http://app:8080/login | false | 5 | 3 | 1 | 1 | あり（共通1, 固有0） |
| dashboard.md | http://app:8080/dashboard | true | 3 | 0 | 2 | 1 | あり（共通1, 固有2） |
### 対象外タスク
- task-NNN: <理由（API のみ、バッチ処理等）>
### ⚠️ 🔴 警告
以下のシナリオは前工程に根拠がなく、AI が推論で追加しました。内容を確認してください:
- <ファイル名> シナリオN: <シナリオ名>
### 📋 draft ファイルの補完方法
draft: true のファイルは UI 要素名が推定です。
dev-impl 完了後に `/dev-webtest-plan <dev-plan-name>` を再実行すると、
実装コードから UI 要素を確認し draft: false に更新できます。
### 🚀 次のステップ
- 実装前の場合: `/dev-impl <dev-plan-name>` で実装を進める
- 実装後の場合: `/dev-webtest <webtest-plan-name>` でテストを実行する
レポート出力後、中間ファイルをクリーンアップする:
rm -rf tmp/webtest/plan/<plan-name>/
| 信号 | 基準 |
|---|---|
| 🔵 | AC の Given/When/Then から直接変換、requirements.md の明示的要件に基づく |
| 🟡 | タスクの Test Strategy から推論、一般的 Web テストベストプラクティス |
| 🔴 | 前工程に根拠なし、AI が Web テストとして必要と判断した項目 |
| Phase | タイプ | モデル | 用途 | 並列 |
|---|---|---|---|---|
| 2a | Explore | haiku | dev-plan分析・画面分割判定 | 2bと並列 |
| 2b | Explore | haiku | 実装コード探索（オプション） | 2aと並列 |
| 3 | Plan | (default) | webtest plan構造設計 | 単独 |
| 5 | general-purpose | (default) | ファイル生成 | plan数分並列 |
以下の場合は自動処理を停止し、ユーザーに確認する:
/dev-context を案内して終了/dev-plan を案内して終了| マーカー | 意味 |
|---|---|
EXPLORE_PLAN_SUCCESS | dev-plan 分析成功 |
EXPLORE_PLAN_FAILED | dev-plan 分析失敗 |
EXPLORE_CODE_SUCCESS | 実装コード探索成功 |
EXPLORE_CODE_FAILED | 実装コード探索失敗 |
DESIGN_SUCCESS | 構造設計成功 |
DESIGN_FAILED | 構造設計失敗 |
GENERATE_SUCCESS | ファイル生成成功 |
GENERATE_FAILED | ファイル生成失敗 |
以下は引数が
updateで始まる場合のワークフロー。新規生成モードとは完全に独立。
docs/dev/context.md の存在を確認する。存在しない場合は /dev-context の実行を案内して終了するdocs/dev/screen-specs/_index.md の存在を確認する
/dev-screen-spec の実行を案内して終了するdocs/dev/webtests/plans/ 配下の既存テスト計画一覧を取得する
plan-name が指定されている場合はそのファイルのみ対象last-run 日付を取得するupdated_at を取得するupdated_at > last-run の画面仕様 → 変更ありと判定するlast_synced_commit とテスト計画の screen_spec_commit フィールドを比較するscreen_id / path とテスト計画の target-url を突き合わせるmkdir -p tmp/webtest/update/影響のあるテスト計画ごとに Explore サブエージェントを起動する（並列）:
references/update-analyze-prompt-template.md を Read で読み込む{{WEBTEST_PLAN_PATH}} ← 既存テスト計画ファイルの絶対パス{{CHANGED_SCREEN_SPEC_PATHS}} ← 変更のあった画面仕様ファイルの絶対パス一覧{{SCREEN_SPEC_INDEX_PATH}} ← docs/dev/screen-specs/_index.md の絶対パス{{TMP_DIR}} ← tmp/webtest/update/ の絶対パスUPDATE_ANALYZE_SUCCESS → Phase 3 へ進むUPDATE_ANALYZE_FAILED → エラー理由をユーザーに報告して終了するテスト計画ごとに general-purpose サブエージェントを起動する（並列）:
references/update-apply-prompt-template.md を Read で読み込む{{WEBTEST_PLAN_PATH}} ← 既存テスト計画ファイルの絶対パス{{ANALYZE_RESULT_PATH}} ← tmp/webtest/update/analyze-<plan-name>.md の絶対パス{{CHANGED_SCREEN_SPEC_PATHS}} ← 変更のあった画面仕様ファイルの絶対パス一覧{{WEBTEST_PLAN_FORMAT_PATH}} ← references/webtest-plan-format.md の絶対パスUPDATE_APPLY_SUCCESS → Phase 4 へ進むUPDATE_APPLY_FAILED → エラー理由を記録、レポートに失敗として記載するユーザーに以下のレポートを出力する:
## dev-webtest-plan 差分更新レポート
### 変更元
- 画面仕様の変更: N 画面
### 更新されたテスト計画
| テスト計画 | 追加 | 修正 | 削除 | 合計シナリオ |
|-----------|------|------|------|------------|
| login-form.md | +2 | ~1 | -0 | 7 |
| dashboard.md | +0 | ~3 | -1 | 5 |
### 変更詳細
#### login-form.md
- ✅ 追加: シナリオ「電話番号バリデーション」（画面仕様: login.md のバリデーション追加に対応）
- ✅ 追加: シナリオ「2要素認証フロー」（画面仕様: login.md のインタラクション追加に対応）
- ✏️ 修正: シナリオ「パスワードバリデーション」（ルール変更: 8文字→10文字）
### 🚀 次のステップ
- `/dev-webtest <plan-name>` でテストを実行する
レポート出力後、中間ファイルをクリーンアップする:
rm -rf tmp/webtest/update/
差分更新の追跡のため、既存のfrontmatterに以下を追加する:
---
# ... 既存フィールド ...
screen_spec_commit: abc1234 # この計画が参照した画面仕様の last_synced_commit
last_updated: "2026-03-09" # 差分更新の最終日
update_history: # 更新履歴（直近3回）
- date: "2026-03-09"
changes: "+2 ~1 -0"
source: "screen-spec update"
---
screen_spec_commit: 新規生成時にも画面仕様が存在する場合は設定するlast_updated: 差分更新を実行した日付update_history: 直近3回の更新履歴。古いものから削除する| 画面仕様セクション | テスト計画の更新対象 |
|---|---|
| 画面項目（追加） | 新規シナリオ追加（要素の表示確認） |
| 画面項目（変更） | 既存シナリオの手順・期待結果を修正 |
| 画面項目（削除） | 該当シナリオを削除 |
| バリデーション（追加） | フォームバリデーション確認テーブルに行追加 + シナリオ追加 |
| バリデーション（変更） | フォームバリデーション確認テーブル更新 + シナリオ修正 |
| バリデーション（削除） | フォームバリデーション確認テーブルから行削除 + シナリオ削除 |
| インタラクション（追加） | 新規シナリオ追加 |
| インタラクション（変更） | 既存シナリオの手順・期待結果を修正 |
| インタラクション（削除） | 該当シナリオを削除 |
| 状態（追加/変更） | 状態遷移テストの追加・修正 |
| フロー定義（追加） | フロー全体のE2Eシナリオを新規追加 |
| フロー定義（変更） | フロー内の遷移順序・アクションが変わった場合、関連するE2Eシナリオを修正 |
| フロー定義（画面変更） | フロー内の1画面が変更された場合、そのフローのE2Eシナリオ全体を更新対象とする |
_index.md のフロー定義から、画面単体テストとは別にフロー全体のE2Eシナリオを生成する。
フロー定義:
user-create --[登録ボタン]--> user-detail --[一覧に戻る]--> user-list
生成されるテストシナリオ:
### シナリオ: ユーザー登録→確認→一覧フロー
**手順**:
1. `/users/new` にアクセスする
2. 各項目を入力する（user-create の画面項目を参照）
3. 「登録」ボタンをクリックする
4. `/users/:id` に遷移することを確認する
5. 登録したデータが詳細画面に表示されていることを確認する
6. 「一覧に戻る」をクリックする
7. `/users` に遷移することを確認する
8. 登録したデータが一覧に表示されていることを確認する
**期待結果**:
- [ ] 登録後、詳細画面に遷移する
- [ ] 詳細画面に登録したデータが正しく表示される
- [ ] 一覧画面に戻れる
- [ ] 一覧画面に登録したデータが表示される
Phase 2 の分析時に以下を追加で判定する:
_index.md から特定する_index.md の「到達不能画面チェック」でいずれのフローにも含まれない画面を検知する| 信号 | 基準 |
|---|---|
| 🟡 | 画面仕様の変更に基づく追加・修正（source: screen-spec update） |
| 🔵 | 既存シナリオで変更なし（元の信号を維持） |
| 🔴 | 画面仕様に根拠なし、AI が必要と判断した追加項目 |
差分更新で追加・修正されるシナリオには 🟡 source: screen-spec update を付与する。既存シナリオの信号機は変更しない。
| Phase | タイプ | モデル | 用途 | 並列 |
|---|---|---|---|---|
| 2 | Explore | haiku | 変更差分の分析 | テスト計画数分並列 |
| 3 | general-purpose | (default) | テスト計画の更新適用 | テスト計画数分並列 |
以下の場合は自動処理を停止し、ユーザーに確認する:
/dev-context を案内して終了/dev-screen-spec を案内して終了| マーカー | 意味 |
|---|---|
UPDATE_ANALYZE_SUCCESS | 変更分析成功 |
UPDATE_ANALYZE_FAILED | 変更分析失敗 |
UPDATE_APPLY_SUCCESS | テスト計画更新成功 |
UPDATE_APPLY_FAILED | テスト計画更新失敗 |
/dev-context を案内して終了するdocs/dev/webtests/plans/ が存在しない場合は自動作成する$(git rev-parse --show-toplevel) でルートを取得）/dev-plan を案内して終了するtmp/webtest/plan/<plan-name>/）経由draft: true → false に更新可能/dev-screen-spec を案内して終了するtmp/webtest/update/）経由🟡 source: screen-spec update を付与するscreen_spec_commit, last_updated, update_history を更新するreferences/webtest-plan-format.md — 出力フォーマット定義（dev-webtest の test-plan-template.md を拡張）references/ac-to-scenario-mapping.md — Given/When/Then → webtest シナリオ変換ルールreferences/lightweight-inference-guide.md — Lightweight モードでのタスク情報→シナリオ推論ガイドreferences/explore-plan-prompt-template.md — Phase 2a: dev-plan 分析 Explore サブエージェント用プロンプトreferences/explore-code-prompt-template.md — Phase 2b: 実装コード探索 Explore サブエージェント用プロンプトreferences/design-prompt-template.md — Phase 3: 構造設計 Plan サブエージェント用プロンプトreferences/generate-prompt-template.md — Phase 5: ファイル生成 general-purpose サブエージェント用プロンプトreferences/update-analyze-prompt-template.md — Phase 2: 変更分析 Explore サブエージェント用プロンプトreferences/update-apply-prompt-template.md — Phase 3: テスト計画更新適用 general-purpose サブエージェント用プロンプトNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
This skill should be used when the user asks to "dev-context", "プロジェクトコンテキストを生成", "プロジェクトを分析", "generate project context", "analyze project", "コンテキストを更新". プロジェクトの技術スタック・テストフレームワーク・コーディング規約・アーキテクチャを自動分析し、コンパクトなコンテキストファイルを生成する。
The English summary is being prepared. Showing the original description.
This skill should be used when the user asks to "dev-debug", "テストが失敗する", "ビルドエラーを直して", "デバッグ", "debug failing tests", "fix build error", "エラーを修正", "コンパイルエラー", "環境の問題を解決". テスト失敗、ビルドエラー、環境問題など様々なエラーパターンをカテゴリ別に診断し、最小コンテキストで修正する。
The English summary is being prepared. Showing the original description.
This skill should be used when the user asks to "dev-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". TDDをガードレールとしたテストファースト実装を行う。通常モード（Plan+タスク指定）とクイックモード（直接指示）に対応。
The English summary is being prepared. Showing the original description.
This skill should be used when the user asks to "dev-init", "技術スタックを選定", "新規プロジェクト初期化", "initialize tech stack", "プロジェクトをセットアップ", "setup project", "scaffold project", "プロジェクト作成", "tech stackを決める". インタラクティブなヒアリングでプロジェクトの技術スタックを決定し、dev-context互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。
The English summary is being prepared. Showing the original description.
This skill should be used when the user asks to "dev-navigate", "どこから始めれば", "何を使えばいい", "スキルを選んで", "ナビ", "navigate", "which skill", "how to start", "開発の進め方", "何から始める". 開発者がやりたいことをヒアリングし、最適なtsumikiスキルとその実行順序をナビゲーションする。
The English summary is being prepared. Showing the original description.
This skill should be used when the user asks to "dev-plan", "実装計画を作成", "要件からタスク分解", "create implementation plan", "plan tasks", "タスクを分割", "設計してタスクにする", "詳細要件定義", "full-spec plan", "EARS要件". ユーザーの要件をインターフェースファースト設計とテスト可能なタスクに分解し、Plan単位でdocs/dev/plans/に保存する。Lightweight（素早い計画）とFull-spec（EARS要件定義付き）の2モードに対応。
The English summary is being prepared. Showing the original description.