/dev-init

name: dev-init
description: This skill should be used when the user asks to "dev-init", "技術スタックを選定", "新規プロジェクト初期化", "initialize tech stack", "プロジェクトをセットアップ", "setup project", "scaffold project", "プロジェクト作成", "tech stackを決める". インタラクティブなヒアリングでプロジェクトの技術スタックを決定し、dev-context互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。

Dev Init

インタラクティブなヒアリングを通じてプロジェクトの技術スタックを決定し、`docs/dev/context.md` を生成する。新規プロジェクトやまだ構成が固まっていないプロジェクト向け。承認後にプロジェクトの骨格ファイル（package.json、設定ファイル、ディレクトリ構造等）も生成可能。

既存プロジェクトの自動分析には `dev-context` を使用する。

前提知識

dev-context との関係

dev-init（新規向け・対話型）  →  docs/dev/context.md
                             →  プロジェクトファイル群（承認制）
                             →  CLAUDE.md（Phase 6）
dev-context（既存向け・自動型）→  docs/dev/context.md
         ↓
dev-plan → dev-impl → dev-verify
                  ↘ dev-debug（必要時）

• 出力フォーマットは `dev-context` と完全互換
• 後続の dev-plan / dev-impl / dev-verify / dev-debug がそのまま参照可能

信号機システム

生成するコンテキストファイル・スキャフォールディング結果の各項目に確信度を付与する:

• 🔵 **前工程指示**: ユーザーが明示的に選択した情報
• 🟡 **妥当な推測**: 選択結果から推論した補足情報（パッケージマネージャ、Linter等）
• 🔴 **AI推論補完**: 情報不足でAIが仮置きした情報、テンプレート未対応言語の生成ファイル

ワークフロー

Phase 1: 既存プロジェクト検出

以下のファイルの存在を確認する:

1. `docs/dev/context.md` — 既存コンテキスト 2. `package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `build.gradle`, `pom.xml`, `pubspec.yaml`, `build.gradle.kts` — パッケージ定義

> **Note:** `CLAUDE.md` の存在確認は Phase 5d（スキャフォールディング時）または Phase 6a-1（CLAUDE.md のみ生成時）で実施する。

**分岐ロジック:**

• `context.md` が存在する場合 → AskUserQuestion で「上書き更新 / 別名保存 / 中止」を確認。別名保存時のファイル名: `context.md.backup.YYYY-MM-DD`
• 「中止」選択時 → 「dev-init を終了しました。既存の context.md を維持します。」と表示してスキルを終了する
• パッケージ定義が存在する場合 → 「既存プロジェクトを検出。`dev-context`（自動分析）を推奨しますが、対話型で進めますか？」と確認
• いずれもない場合 → Phase 2 へ進む

> **同時存在時の優先順位:** `context.md` とパッケージ定義が両方存在する場合は、`context.md` の確認（上書き更新 / 別名保存 / 中止）を先に行う。「中止」が選択された場合はスキル終了。「上書き更新」または「別名保存」が選択された場合は、パッケージ定義の検出に関する確認（dev-context 推奨）を続けて行う。

Phase 2: プロジェクト基本情報ヒアリング

AskUserQuestion ツールで以下を順次ヒアリングする。各質問は1問ずつ提示し、前の回答を次の質問の選択肢構成に反映する。

Q1: プロジェクトカテゴリ（大分類）

| 選択肢 | 説明 | |--------|------| | Webアプリケーション | ブラウザ向け/モバイル向けWebアプリ（フロントエンド含む） | | サーバーサイド | API・バッチ処理・分散処理サービス | | ツール/スクリプト | CLI・GAS等の単機能ツール | | ライブラリ/パッケージ | 他プロジェクトから利用されるライブラリ |

Q2: プロジェクトタイプ（詳細分類）

Q1 の回答に応じて条件分岐する。ライブラリ/パッケージの場合は Q2 をスキップし自動確定する。

| Q1 の回答 | Q2 の選択肢 | |-----------|------------| | Webアプリケーション | フルスタック（一体型） / 3層アーキテクチャ（TypeScriptフロント+API+DB） / BFFアーキテクチャ（UI+BFF+サービス+DB） | | サーバーサイド | APIサーバー / バッチ処理 / マイクロサービス / イベント駆動 | | ツール/スクリプト | CLIツール / GAS（Google Apps Script） | | ライブラリ/パッケージ | Q2 スキップ（自動確定） |

> **3層アーキテクチャ選択時の自動通知**: Q2回答直後、Q5に進む前に以下を表示する: > 「3層アーキテクチャのため、以下が自動設定されます: フロントエンド言語: TypeScript（固定） / プロジェクト構成: モノレポ（packages/frontend + packages/backend + packages/shared）」

> **BFFアーキテクチャ選択時の自動通知**: Q2回答直後、Q3に進む前に以下を表示する: > 「BFFアーキテクチャのため、以下が自動設定されます: プロジェクト構成: モノレポ」

Q3: UIターゲット（BFF のみ）

BFFアーキテクチャ選択時のみ質問する。他のタイプではスキップ。

| 選択肢 | 説明 | |--------|------| | Webのみ | ブラウザ向けWebアプリ | | モバイルのみ | iOS/Android モバイルアプリ | | Web + モバイル | 両方に対応（BFFで共通API提供） |

> モバイル選択時のフレームワークは、Q5a の言語選択に応じた推奨を提示する（Dart → Flutter(Recommended)/Other、TypeScript(RN) → React Native(Recommended)/Expo/Other）

> BFFアーキテクチャ選択時、Q3の後にQ4（サービス層構成: 単一サービス/複数サービス）を質問する。詳細はQ4セクション参照。

Q4: タイプ固有質問

プロジェクトタイプに応じた追加質問を行う。バッチ処理・マイクロサービス・イベント駆動ではQ6の前（Q5の後）に実施し、BFFではQ3の直後に実施し、GASではQ2の直後（Q5/Q6スキップのため）に実施する。該当タイプ以外ではスキップする。

**Q4: サービス層構成（BFF のみ）**

> BFFでは本質問をQ3の直後（技術選定の前）に実施する。

| 選択肢 | 説明 | |--------|------| | 単一サービス | BFF + 1サービスで開始。後から分割可能 | | 複数サービス | 初期から services/service-a, services/service-b 等の構成 |

**Q4b: 初期サービス構成（BFF 複数サービス選択時のみ）**

| 選択肢 | 説明 | |--------|------| | 2サービス（デフォルト） | service-a, service-b の2サービスで開始 | | カスタム | サービス名をカンマ区切りで入力（例: user-service, order-service）。kebab-case |

**Q4: スケジューリング方式（バッチ処理のみ）**

| 選択肢 | 説明 | |--------|------| | cron / OS スケジューラ | システムの cron や systemd timer で定期実行 | | クラウドスケジューラ | Cloud Scheduler / EventBridge 等で実行 | | フレームワーク内蔵 | BullMQ / Celery Beat 等ジョブキュー型 |

**Q4: サービス間通信（マイクロサービスのみ）**

| 選択肢 | 説明 | |--------|------| | REST API | HTTP ベースの同期通信 | | gRPC | Protocol Buffers ベースの高効率通信 | | メッセージキュー | 非同期メッセージング（Kafka / RabbitMQ 等） |

**Q4c: メッセージブローカー（マイクロサービスでメッセージキュー選択時のみ）**

> マイクロサービスの Q4 で「メッセージキュー」を選択した場合のみ質問する。

| 選択肢 | 説明 | |--------|------| | Apache Kafka | 高スループット・ストリーム処理 | | RabbitMQ | 汎用メッセージブローカー | | AWS SQS + SNS | AWSマネージドキュー | | Redis Pub/Sub | 軽量・リアルタイム |

**Q4b: 初期サービス構成（マイクロサービスのみ）**

> マイクロサービスではQ4（サービス間通信）→ Q4b（初期サービス構成）→ Q6 の順で実施する。アーキテクチャ設計（通信方式+サービス構成）を一括で聞いた後、技術選定（FW）に進む。

| 選択肢 | 説明 | |--------|------| | 2サービス（デフォルト） | service-a, service-b の2サービスで開始 | | 単一サービス | 1サービスで開始し、後から追加 | | カスタム | サービス数・名前を自由入力 |

**Q4: メッセージブローカー（イベント駆動のみ）**

| 選択肢 | 説明 | |--------|------| | Apache Kafka | 高スループット・ストリーム処理 | | RabbitMQ | 汎用メッセージブローカー | | AWS SQS + SNS | AWSマネージドキュー | | Redis Pub/Sub | 軽量・リアルタイム |

**Q4: GAS デプロイ形態（GAS のみ）**

| 選択肢 | 説明 | |--------|------| | スタンドアロン | 独立したスクリプトプロジェクト | | スプレッドシート連携 | Google Sheets のカスタム関数・メニュー | | Webアプリ | doGet/doPost による HTTP エンドポイント |

Q5: 言語選択

プロジェクトタイプに応じて質問構成が変わる。

**共通の言語選択肢:**

| 選択肢 | 説明 | |--------|------| | TypeScript | Node.js/Deno/Bun 向け | | Python | FastAPI/Django/Flask 等 | | Rust | 高パフォーマンス・システム | | Go | マイクロサービス・CLI | | Java | Spring Boot/Quarkus 等 | | Kotlin | Ktor/Spring Boot(Kotlin) 等 | | Dart | Flutter/dart_frog 等 |

**Q5 の条件分岐:**

• **GAS 選択時**: Q5 をスキップし TypeScript を自動選定
• **3層アーキテクチャ選択時**: Q5 のみ質問。質問文は「バックエンドの主要言語を選択してください」。UI層は TypeScript 自動選定
• **BFFアーキテクチャ選択時**: Q5a/Q5b/Q5c の3段階に分割（下記参照）
• **その他のタイプ**: Q5 のみ質問（「主要言語を選択してください」）

**BFF の Q5 分割:**

各レイヤーの言語選択（Q5a/Q5b/Q5c）後、対応するフレームワーク（Q6a/Q6b/Q6c）を連続して質問する。UI層（Q5a→Q6a）→ BFF層（Q5b→Q6b）→ サービス層（Q5c→Q6c）の順で進む。

• **Q5a（UI層言語）**: Q3（UIターゲット）に応じて分岐
• Webのみ → TypeScript 自動選定（スキップ）
• モバイルのみ → 質問（Dart / TypeScript(React Native)）
• Web+モバイル → Web は TypeScript 自動選定、モバイル側を質問（Dart / TypeScript(React Native)）
• **Q5b（BFF層言語）**: 全言語から選択。TypeScript に「（Recommended）」ラベル
• **Q5c（サービス層言語）**: 全言語から選択（従来と同等）

Phase 3: 技術詳細ヒアリング

Phase 2 の回答に基づいて動的に質問を構成する。`refer