// This skill should be used when the user asks to "dev-init", "技術スタックを選定", "新規プロジェクト初期化", "initialize tech stack", "プロジェクトをセットアップ", "setup project", "scaffold project", "プロジェクト作成", "tech stackを決める". インタラクティブなヒアリングでプロジェクトの技術スタックを決定し、dev-context互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。
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-navigate", "どこから始めれば", "何を使えばいい", "スキルを選んで", "ナビ", "navigate", "which skill", "how to start", "開発の進め方", "何から始める". 開発者がやりたいことをヒアリングし、最適なtsumikiスキルとその実行順序をナビゲーションする。
| 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互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。 |
インタラクティブなヒアリングを通じてプロジェクトの技術スタックを決定し、docs/dev/context.md を生成する。新規プロジェクトやまだ構成が固まっていないプロジェクト向け。承認後にプロジェクトの骨格ファイル（package.json、設定ファイル、ディレクトリ構造等）も生成可能。
既存プロジェクトの自動分析には 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 と完全互換生成するコンテキストファイル・スキャフォールディング結果の各項目に確信度を付与する:
以下のファイルの存在を確認する:
docs/dev/context.md — 既存コンテキスト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-DDdev-context（自動分析）を推奨しますが、対話型で進めますか？」と確認同時存在時の優先順位:
context.mdとパッケージ定義が両方存在する場合は、context.mdの確認（上書き更新 / 別名保存 / 中止）を先に行う。「中止」が選択された場合はスキル終了。「上書き更新」または「別名保存」が選択された場合は、パッケージ定義の検出に関する確認（dev-context 推奨）を続けて行う。
AskUserQuestion ツールで以下を順次ヒアリングする。各質問は1問ずつ提示し、前の回答を次の質問の選択肢構成に反映する。
| 選択肢 | 説明 |
|---|---|
| Webアプリケーション | ブラウザ向け/モバイル向けWebアプリ（フロントエンド含む） |
| サーバーサイド | API・バッチ処理・分散処理サービス |
| ツール/スクリプト | CLI・GAS等の単機能ツール |
| ライブラリ/パッケージ | 他プロジェクトから利用されるライブラリ |
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アーキテクチャのため、以下が自動設定されます: プロジェクト構成: モノレポ」
BFFアーキテクチャ選択時のみ質問する。他のタイプではスキップ。
| 選択肢 | 説明 |
|---|---|
| Webのみ | ブラウザ向けWebアプリ |
| モバイルのみ | iOS/Android モバイルアプリ |
| Web + モバイル | 両方に対応（BFFで共通API提供） |
モバイル選択時のフレームワークは、Q5a の言語選択に応じた推奨を提示する（Dart → Flutter(Recommended)/Other、TypeScript(RN) → React Native(Recommended)/Expo/Other）
BFFアーキテクチャ選択時、Q3の後に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 エンドポイント |
プロジェクトタイプに応じて質問構成が変わる。
共通の言語選択肢:
| 選択肢 | 説明 |
|---|---|
| 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 の条件分岐:
BFF の Q5 分割:
各レイヤーの言語選択（Q5a/Q5b/Q5c）後、対応するフレームワーク（Q6a/Q6b/Q6c）を連続して質問する。UI層（Q5a→Q6a）→ BFF層（Q5b→Q6b）→ サービス層（Q5c→Q6c）の順で進む。
Phase 2 の回答に基づいて動的に質問を構成する。references/tech-recommendations.md の推奨マトリクスを参照し、言語×プロジェクトタイプに応じた選択肢を提示する。
BFFアーキテクチャでは、各レイヤーの言語（Q5）とフレームワーク（Q6）をペアで連続して質問する。UI層（Q5a→Q6a）→ BFF層（Q5b→Q6b）→ サービス層（Q5c→Q6c）の順で進む。
3層アーキテクチャでは、Q5（バックエンド言語）→ Q6（バックエンドFW）を直結させた後、Q6a（フロントエンドFW）を質問する。この順序は「言語選択とFW選択の認知的連続性」を優先するため: バックエンドは言語+FWの2つの決断が必要な一方、フロントエンドはFWのみ（言語はTypeScript固定）のため、決断負荷が重い方を先に片付ける設計。
言語とプロジェクトタイプの組み合わせに応じて、推奨マトリクスから選択肢を動的構成する。推奨表の「推奨1」を先頭に配置し、ラベルに「（Recommended）」を付与する。
Q6 の条件分岐:
BFF の Q6 分割:
各Q6はQ5と対になるレイヤーの言語選択直後に質問する（Q5a→Q6a→Q5b→Q6b→Q5c→Q6cの順）。
| 選択肢 | 説明 |
|---|---|
| 個人・プロトタイプ | 迅速な立ち上げ優先 |
| 小規模チーム（2-5人） | バランス重視 |
| 中〜大規模チーム（6人以上） | 堅牢性・標準化重視 |
CLIツール・GAS・ライブラリ/パッケージ以外の場合に質問する。
| 選択肢 | 説明 |
|---|---|
| PostgreSQL（Recommended） | 汎用RDBMS |
| SQLite | 軽量・組み込み |
| MongoDB | ドキュメントDB |
| なし | DB不要 |
言語に応じて推奨表から選択肢を構成する。推奨デフォルトを先頭に配置する。
Q9 の条件分岐:
Q9「変更する」選択時のサブフロー:
CLIツール・GAS・ライブラリ/パッケージ以外の場合に質問する。
| 選択肢 | 説明 |
|---|---|
| Docker開発環境（Recommended） | 全サービスをdocker-composeで管理。DB・テストツール含む |
| Dockerなし | ローカルにランタイムをインストールして開発 |
| 選択肢 | 説明 |
|---|---|
| CI/CD（GitHub Actions） | 自動テスト・デプロイ |
| モノレポ構成 | 複数パッケージの統合管理 |
Q11 の条件分岐:
Note: Linter/Formatter および PM（パッケージマネージャ）は Q5（言語）の選択に基づき常に自動選定される（
references/tech-recommendations.mdの Linter/Formatter 推奨表・PM 推奨表参照）。Q5 回答後、次の質問に進む前に「言語選択に基づく自動設定: Linter: [値] / Formatter: [値] / PM: [値]」を通知する。GAS の場合は Q2 直後のまとめ通知に含まれるため個別通知は不要。
Note: 混合言語 BFF では pnpm ワークスペースではなく Makefile + Docker Compose ベースのモノレポ構成になる場合がある。Q5a・Q5b・Q5c が全て同一言語（TypeScript）の場合のみ pnpm ワークスペースを使用する。
フルスタック: Q1→Q2→Q5→Q6→Q7→Q8→Q9→Q10→Q11
3層Web: Q1→Q2→Q5→Q6→Q6a→Q7→Q8→Q9→Q10→Q11
BFF: Q1→Q2→Q3→Q4→Q5a→Q6a→Q5b→Q6b→Q5c→Q6c→Q7→Q8→Q9→Q10→Q11
APIサーバー: Q1→Q2→Q5→Q6→Q7→Q8→Q9→Q10→Q11
バッチ処理: Q1→Q2→Q5→Q4→Q6→Q7→Q8→Q9→Q10→Q11
マイクロサービス: Q1→Q2→Q5→Q4→Q4b→Q6→Q7→Q8→Q9→Q10→Q11
イベント駆動: Q1→Q2→Q5→Q4→Q6→Q7→Q8→Q9→Q10→Q11
CLIツール: Q1→Q2→Q5→Q6→Q7→Q9→Q11
GAS: Q1→Q2→Q4→Q7→Q9→Q11
ライブラリ: Q1→Q5→Q6→Q7→Q9→Q11
マイクロサービスでメッセージキュー選択時、Q4の後にQ4cでブローカーを指定 BFF複数サービス選択時、Q4の後にQ4bでサービス構成を指定 BFF Web+モバイル時、Q6a は Q6a-mobile + Q6a-web の2問に分割
非BFFタイプの Q5 は「主要言語」として1問のみ質問。3層アーキテクチャでは「バックエンドの主要言語」として質問する。BFFでは Q5a/Q5b/Q5c の3段階に分割される。
非BFF・非3層タイプの Q6 は「フレームワーク」として1問のみ質問。推奨マトリクスの該当タイプ×Q5言語の行から選択肢を構成する。3層アーキテクチャでは Q6（バックエンドFW）+ Q6a（フロントエンドFW）に分割される。BFFでは Q6a/Q6b/Q6c の3段階に分割される。ライブラリ/パッケージではビルド/バンドラツールとして質問する。
全ヒアリング結果を統合し、docs/dev/context.md を生成する。
mkdir -p "$(git rev-parse --show-toplevel)/docs/dev"
dev-context の references/context-template.md（.claude/skills/dev-context/references/context-template.md）と同じフォーマットで生成する。テンプレートの各セクションを以下のように埋める:
references/tech-recommendations.md から取得（3層/BFF/バッチ/マイクロサービス/イベント駆動/GAS の新テンプレートを含む）references/docker-dev-templates.md を参照して Docker Environment セクションを生成。Docker 選択時は Build & Run セクションのコマンドを docker compose exec app <command> 形式に変更ヘッダーは以下のように記載する:
> Generated by dev-init. Last updated: YYYY-MM-DD
> Confidence: 🔵 = user selected, 🟡 = inferred from selection, 🔴 = AI assumption
生成完了後、以下を表示する:
references/tech-recommendations.md から該当テンプレート）Phase 4 完了後、AskUserQuestion で確認する:
dev-plan での要件定義・タスク分解を案内して終了（従来動作）選択した言語の scaffolding ファイル（references/<lang>-scaffolding.md）を参照:
scaffolding ファイルを参照し、生成予定ファイルのツリーを構築する。
常に生成するファイル:
.gitignore, README.mdreferences/tech-recommendations.md の推奨表に従う）CLAUDE.md — プロジェクトルールと開発コマンドの指示書（references/claudemd-template.md に基づく）モノレポ構成時（3層Web / BFF / マイクロサービス）に追加生成:
CLAUDE.md — 各パッケージルートに配置（references/claudemd-template.md の「サブパッケージ CLAUDE.md テンプレート構造」に基づく）。生成対象は後述の 5d のパッケージ判定ロジックに従うQ10 Docker開発環境選択時のみ生成:
docker-compose.yml — 開発環境全体定義（references/docker-dev-templates.md を参照して構成）Dockerfile.dev — 開発用Dockerfile（hot-reload対応、volume mount前提）Dockerfile — デプロイ用（従来通り）.dockerignoreQ11 選択時のみ生成:
.github/workflows/ci.ymlAskUserQuestion でファイルツリーを提示 → 「生成する / ファイルを修正する / 中止する」
references/claudemd-template.md と Q1-Q11 の回答に基づき、スキャフォールディングの最後に CLAUDE.md を生成する。既存の CLAUDE.md がある場合は Phase 1 で検出済みのため、上書き/バックアップ/スキップの判断に従う。生成ルールは Phase 6 の 6b に準拠する| アーキテクチャ | Q3の回答 | 生成対象パッケージ | 生成しない |
|---|---|---|---|
| 3層Web | — | packages/frontend/, packages/backend/ | packages/shared/ |
| BFF（単一） | Webのみ | packages/web-ui/, packages/bff/, packages/service/ | packages/shared/ |
| BFF（単一） | モバイルのみ | packages/mobile-ui/, packages/bff/, packages/service/ | packages/shared/ |
| BFF（単一） | Web+モバイル | packages/web-ui/, packages/mobile-ui/, packages/bff/, packages/service/ | packages/shared/ |
| BFF（複数） | Webのみ | packages/web-ui/, packages/bff/, 各 services/<name>/ | packages/shared/ |
| BFF（複数） | モバイルのみ | packages/mobile-ui/, packages/bff/, 各 services/<name>/ | packages/shared/ |
| BFF（複数） | Web+モバイル | packages/web-ui/, packages/mobile-ui/, packages/bff/, 各 services/<name>/ | packages/shared/ |
| マイクロサービス | — | 各 services/<name>/ | packages/shared/ |
Note: マイクロサービスで Q11 モノレポ未選択の場合、サブパッケージ生成は発動しない
scaffolding ファイルの「検証コマンド」セクションに従い:
Q10 で Docker 開発環境を選択した場合:
docker compose up -d でコンテナを起動（未起動の場合）docker compose exec app <command> 形式で実行検証手順:
生成完了後、以下を表示する:
packages/shared/ は「手動追加可能」と案内dev-plan での要件定義・タスク分解の案内Phase 5 でスキャフォールディングを実行した場合、CLAUDE.md は Phase 5d で自動生成されるため、このフェーズはスキップする。Phase 5 をスキップした場合（context.md のみ生成した場合）にのみ、このフェーズを実行する。
プロジェクトルートの CLAUDE.md の有無を確認する。
CLAUDE.md が存在しない場合 → 6b へ進むCLAUDE.md が存在する場合 → AskUserQuestion で以下を確認:
CLAUDE.md.backup.YYYY-MM-DD にリネーム後、新規作成モノレポ構成（3層Web / BFF / マイクロサービス）の場合、5d のパッケージ判定ロジックに基づき各サブパッケージの CLAUDE.md の有無を確認する。
CLAUDE.md が1つも存在しない場合 → 6b-2 へ進むreferences/claudemd-template.md と Q1-Q11 の回答から CLAUDE.md を生成する。各セクションの構成:
references/claudemd-template.md のコマンド導出テーブル + scaffolding ファイルからコマンドを導出。Q10 で Docker 選択時は docker compose exec app プレフィクスを付与し、Docker 操作コマンド（up/down/logs）も追加references/claudemd-template.md の言語別デフォルト + Q7（チーム規模）で記載量・厳格度を調整生成時の制約:
references/claudemd-template.md の圧縮優先順位に従う）モノレポ構成時、ルート CLAUDE.md 生成後に各サブパッケージの CLAUDE.md を生成する。references/claudemd-template.md の「サブパッケージ CLAUDE.md テンプレート構造」「サブパッケージ Development Commands 導出テーブル」「サブパッケージ Package Rules テンプレート」に基づく。
生成対象パッケージの判定:
packages/shared/ は生成しない（レポートに「手動追加可能」と案内）各サブパッケージ CLAUDE.md の構成:
references/claudemd-template.md の「サブパッケージ Development Commands 導出テーブル」からパッケージローカルコマンドを導出。Q10 Docker 選択時は docker compose exec app プレフィクスを付与references/claudemd-template.md の「サブパッケージ Package Rules テンプレート」からパッケージ役割に応じたルールを記載生成時の制約:
references/claudemd-template.md の「30行制限の圧縮ガイド」に従う）生成完了後、以下を表示する:
packages/frontend/CLAUDE.md — 12行）packages/shared/ は「必要に応じて手動で CLAUDE.md を追加してください」と案内全 Phase の統合サマリーを表示する:
dev-plan での要件定義・タスク分解の案内dev-context の context-template.md と 完全互換context.md は 500行以内 に収めるcontext.md と docs/dev/ のみ生成するdocs/dev/plans/ 配下のファイルには影響を与えない$(git rev-parse --show-toplevel) でルートを取得）references/claudemd-template.md の圧縮優先順位に従う）references/claudemd-template.md の「30行制限の圧縮ガイド」に従う）packages/shared/ には CLAUDE.md を 生成しない（レポートに「手動追加可能」と案内）references/claudemd-template.md — CLAUDE.md のテンプレート構造、コマンド導出テーブル、コードスタイルデフォルト、80行制限ガイドreferences/tech-recommendations.md — 言語×タイプの推奨マトリクス、PM・テスト・Linter推奨表、ディレクトリ構造テンプレート、Docker開発環境推奨表references/docker-dev-templates.md — 言語別docker-compose開発環境テンプレート、DBサービス、Playwright連携.claude/skills/dev-context/references/context-template.md — context.md のテンプレートと記述ガイド（dev-context と共有）references/ts-scaffolding.md — TypeScript スキャフォールディングガイドreferences/python-scaffolding.md — Python スキャフォールディングガイドreferences/rust-scaffolding.md — Rust スキャフォールディングガイドreferences/go-scaffolding.md — Go スキャフォールディングガイドreferences/java-scaffolding.md — Java スキャフォールディングガイドreferences/kotlin-scaffolding.md — Kotlin スキャフォールディングガイドreferences/dart-scaffolding.md — Dart (Flutter) スキャフォールディングガイド