// 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モードに対応。
IPA「安全なウェブサイトの作り方 改訂第7版」「安全なSQLの呼び出し方」「ウェブ健康診断仕様」「セキュリティ実装チェックリスト」「安全なウェブサイトの運用管理に向けての20ヶ条」に基づき、ソースコードを静的に検査して脆弱性候補を検出する。発見した問題には IPA 原典の出典 (文書名・章・ページ・URL) を必ず付与する。
ipa-security-check をはじめとするセキュリティ診断ツールが出力したレポートを読み込み、各検出項目を優先順位付きの dev-debug 依頼リストに変換する。対象プロジェクトの言語・FWを問わず汎用的に使える。コードベースを直接読んでアーキテクチャ判断を行う。
This skill should be used when the user asks to "dev-context", "プロジェクトコンテキストを生成", "プロジェクトを分析", "generate project context", "analyze project", "コンテキストを更新". プロジェクトの技術スタック・テストフレームワーク・コーディング規約・アーキテクチャを自動分析し、コンパクトなコンテキストファイルを生成する。
This skill should be used when the user asks to "dev-debug", "テストが失敗する", "ビルドエラーを直して", "デバッグ", "debug failing tests", "fix build error", "エラーを修正", "コンパイルエラー", "環境の問題を解決". テスト失敗、ビルドエラー、環境問題など様々なエラーパターンをカテゴリ別に診断し、最小コンテキストで修正する。
This skill should be used when the user asks to "dev-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". TDDをガードレールとしたテストファースト実装を行う。通常モード（Plan+タスク指定）とクイックモード（直接指示）に対応。
This skill should be used when the user asks to "dev-init", "技術スタックを選定", "新規プロジェクト初期化", "initialize tech stack", "プロジェクトをセットアップ", "setup project", "scaffold project", "プロジェクト作成", "tech stackを決める". インタラクティブなヒアリングでプロジェクトの技術スタックを決定し、dev-context互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。
| name | dev-plan |
| 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モードに対応。 |
| argument-hint | <plan-name> "<requirements>" | <plan-name> <prd-file-path> |
ユーザーの要件を分析し、インターフェースファーストの設計とテスト可能なタスクに分解する。Plan名で名前空間を分離し、複数要件の並行開発をサポートする。出力は docs/dev/plans/<plan-name>/ に保存される。
dev-context → [dev-plan] → dev-impl → dev-verify
docs/dev/context.md が存在すること（dev-contextで生成済み）/dev-context の実行を案内する/dev-plan <plan-name> "<要件の説明>"
/dev-plan <plan-name> <PRDファイルパス>
plan-name: 英数字とハイフンのみ（例: auth, payment-integration, user-profile）
.md 等）。ファイル内容を要件として読み込む| モード | 説明 | 出力 |
|---|---|---|
| Lightweight | 素早い要件明確化→設計→タスク分解 | plan.md + tasks/ |
| Full-spec | EARS要件定義→ユーザーストーリー→受入基準→設計→タスク分解 | requirements.md + user-stories.md + acceptance-criteria.md + plan.md + tasks/ |
AskUserQuestion で実行モードを選択する:
選択されたモードに応じて以降の Phase の振る舞いが変わる。
plan-name に日本語（非ASCII文字）が含まれる場合、以下のルールで英数字ケバブケースに自動変換する:
user-auth-systemdata-exportpassword-resetfavorite-managementsearch-filterplan-name が既に英数字とハイフンのみの場合はこのフェーズをスキップする。
/ を含む、または .md 等の拡張子で終わる）→ Read ツールでファイルを読み込み、内容を要件として使用する
model: haiku）で要約を取得するdocs/dev/context.md を読み込み、プロジェクトコンテキストを把握する確認すべき観点:
Full-spec モードの場合の追加確認（3-5ラウンド）:
Full-spec モードの場合のみ実行する。Lightweight の場合はスキップして Phase 2 に進む。
コンテキスト節約のため、3ドキュメント生成はサブエージェントに委譲する（dev-run パターン）。
references/fullspec-prompt-template.md を Read してプロンプトテンプレートを取得するdocs/dev/context.md から Tech Stack + Project Structure セクションを 100行以内 に抽出する{{HEARING_SUMMARY}} ← ヒアリング結果の要約{{PLAN_NAME}} ← Plan名{{CONTEXT_EXCERPT}} ← context.md 抜粋docs/dev/plans/<plan-name>/requirements.md — EARS形式の機能要件・非機能要件・制約・用語集docs/dev/plans/<plan-name>/user-stories.md — ペルソナ・エピック・ストーリー（As a/I want/So that）・MoSCoW優先度・ジャーニーdocs/dev/plans/<plan-name>/acceptance-criteria.md — Given/When/Then形式の受入基準・テストチェックリスト・横断的基準FULLSPEC_SUCCESS → 赤信号リストのみメインコンテキストに取り込むFULLSPEC_FAILED → エラー内容を確認し、リトライまたはユーザーに報告するFull-spec モードの場合: Plan サブエージェントに Phase 1.5 で生成した3ドキュメントの ファイルパス を渡し、サブエージェントが直接 Read で読み込んで設計に反映する。これにより設計がEARS要件に基づいたものになり、かつメインコンテキストで3ドキュメント(~1500行)を保持し続ける必要がなくなる。
docs/dev/plans/<plan-name>/requirements.mddocs/dev/plans/<plan-name>/user-stories.mddocs/dev/plans/<plan-name>/acceptance-criteria.mdPlan サブエージェント（subagent_type: Plan）で関連コードベースを分析する:
テスト可能な単位にタスクを分割する:
以下のディレクトリとファイルを生成する:
PROJECT_ROOT="$(git rev-parse --show-toplevel)"
mkdir -p "$PROJECT_ROOT/docs/dev/plans/<plan-name>/tasks"
mkdir -p "$PROJECT_ROOT/docs/dev/plans/<plan-name>/reports"
Lightweight モード:
docs/dev/plans/<plan-name>/
├── plan.md
├── tasks/
│ └── NNN-task-name.md
└── reports/
Full-spec モード:
docs/dev/plans/<plan-name>/
├── plan.md # 要件概要・設計メモ・タスク依存グラフ
├── requirements.md # EARS要件定義（Phase 1.5で生成済み）
├── user-stories.md # ユーザーストーリー（Phase 1.5で生成済み）
├── acceptance-criteria.md # 受入基準（Phase 1.5で生成済み）
├── tasks/
│ └── NNN-task-name.md
└── reports/
docs/dev/plans/<plan-name>/plan.md に要件概要と設計メモを記録:
# Plan: <plan-name>
## Requirements Summary
[要件の要約]
<!-- Full-spec モードの場合、以下のリンクを追加 -->
<!-- 詳細: [requirements.md](requirements.md) | [user-stories.md](user-stories.md) | [acceptance-criteria.md](acceptance-criteria.md) -->
## Design Overview
[インターフェース設計の概要]
## Task Dependency Graph
[タスク間の依存関係]
## Cross-Plan Dependencies
[他のPlanとの共有インターフェースがある場合に記載]
Full-spec モードの場合、Requirements Summary に要件ドキュメントへの相対リンクを記載する。
各タスクを docs/dev/plans/<plan-name>/tasks/NNN-task-name.md に出力する。references/task-template.md のテンプレートに従う。
設計の各要素に確信度を付与する:
インターフェース定義の各メソッド/プロパティに確信度を付与し、タスクファイルに記録する。🔴 がある場合はユーザーに AskUserQuestion で確認する。
/dev-context の実行を案内して終了するdocs/dev/plans/<plan-name>/ が存在する場合、上書きするか確認するany や unknown を避ける）$(git rev-parse --show-toplevel) でルートを取得）references/task-template.md — タスクファイルのテンプレートとフロントマター仕様references/fullspec-templates.md — Full-spec モード用の要件ドキュメントテンプレート（requirements.md, user-stories.md, acceptance-criteria.md）と EARS 記述ガイドreferences/fullspec-prompt-template.md — Full-spec モード Phase 1.5 のサブエージェント用プロンプトテンプレート（{{HEARING_SUMMARY}}, {{PLAN_NAME}}, {{CONTEXT_EXCERPT}} を置換して使用）