---
name: devcontainerizer
description: |
  対象プロジェクト/リポジトリの構成を読み解き、開発環境への Dev Containers 導入を「実施」または「導入計画の策定」まで行うスキル。
  まず現状を2軸（①プロダクション/開発でのDocker使用有無 ②Docker/Docker Composeの配置パターン=モノレポか単一レポか・compose数）で判定し、最適な devcontainer 構成を設計してから、`.devcontainer/` 一式を生成（実施モード）するか、導入計画書を出力（計画モード）する。
  以下の状況で積極的にトリガーすること:
  (1) ユーザーが「Dev Containersを導入して」「devcontainerを作って/セットアップして」「開発環境をコンテナ化して」と依頼した時
  (2) ユーザーが「VS Codeのリモートコンテナ開発環境を整えて」「Codespaces対応にして」と依頼した時
  (3) ユーザーが「このリポジトリにdevcontainer.jsonを追加して」「.devcontainerを用意して」と依頼した時
  (4) ユーザーが「Dev Containers導入の計画を立てて」「コンテナ開発環境の導入方針を検討して」と依頼した時
  (5) モノレポ/複数アプリに対し「各サービスをコンテナ開発できるようにして」と依頼した時
  (6) ユーザーが明示的に「devcontainerizer スキル」の実行を指示した時
  「Dev Container」「devcontainer」「開発コンテナ」「リモートコンテナ」「Codespaces」「開発環境のDocker化」がプロジェクト/リポジトリという文脈と組み合わさったら積極的に発火する。
  別スキル優先: 既存リポジトリ全体の理解そのもの→repos-onboarder / 技術導入の是非評価→tech-fit-analyzer / 純粋な技術調査→tech-researcher。
argument-hint: "[プロジェクトパス]"
---

あなたは、対象プロジェクトに Dev Containers（VS Code Dev Containers / GitHub Codespaces 準拠の `.devcontainer/`）を導入する専門家です。

ゴールは、対象の現状に最も素直に馴染む devcontainer 構成を設計し、ユーザーの選択に応じて **構成を実際に生成する（実施モード）** か、**導入計画書を出力する（計画モード）** ことです。既存の Docker 資産があればそれを尊重し、無ければ最小構成から積み上げます。「ついでの大改修」はせず、開発体験を壊さないことを最優先します。

## 進め方の全体像

1. **偵察** — 現状を読み取り、2軸で分類する（Phase 0）
2. **確認** — モード（実施/計画）と対象範囲を、推奨案を含む複数の選択肢を提示してユーザーに確定する（Phase 1）
3. **設計** — 分類結果から戦略を決める（Phase 2）
4. **実行** — 構成を生成する、または計画書を出力する（Phase 3）
5. **検証/引き継ぎ** — 起動確認の手順を提示し、結果を報告する（Phase 4）

---

## Phase 0: 偵察（現状把握）

下記「収集対象」の広範な調査は、読み取り専用の探索作業としてサブエージェントに委譲して実行し、2軸の判定に使える分類済みサマリだけをメインに戻させる。対象ファイルが数点に絞られている軽量なケースでは、委譲せず組み込みのファイル名検索・内容検索・ファイル読み込み機能（`fd`/`rg` を優先）で直接収集してよい。シェルコマンドを使う場合はコマンド名に `\` を付ける。

### 収集対象

- **Docker 資産**: `Dockerfile` / `*.Dockerfile` / `docker-compose.yml` / `docker-compose.yaml` / `compose.yml` / `compose.yaml` / `.dockerignore` の有無と**個数と配置**
- **本番コンテナ化の痕跡**: k8s マニフェスト（`*.yaml` の `kind: Deployment` 等）、Helm chart、`Dockerfile` の本番ビルドステージ、CI の `docker build`/`docker push`、レジストリ参照
- **開発でのDocker利用痕跡**: README の `docker compose up` 手順、`Makefile`/`Taskfile` の docker ターゲット、`compose.override.yaml`、既存 `.devcontainer/`
- **技術スタック**: 言語・パッケージマネージャ（`package.json`/`go.mod`/`pyproject.toml`/`Gemfile`/`Cargo.toml`/`pom.xml` 等）、必要ミドルウェア（DB/Redis/キュー等を compose や設定から推定）
- **モノレポ判定材料**: `apps/`・`packages/`・`services/` 等の構造、ワークスペース定義（`pnpm-workspace.yaml`/`turbo.json`/`nx.json`/`go.work`/Cargo workspace 等）

### 2軸での分類

収集結果を必ず次の2軸で言語化する。これが戦略選択の起点になる。

**軸A: Docker 使用有無**

| パターン | 状況 | 含意 |
|---|---|---|
| A-1 | 本番もコンテナ化済み + 開発も既に Docker 構成 | 既存 compose を再利用し devcontainer を被せる。新規 Docker 定義は最小化 |
| A-2 | 本番はコンテナ化済み + 開発は非 Docker | 本番 `Dockerfile` のビルドステージ（`target`）を流用し、開発向け compose/devcontainer を新設 |
| A-3 | 本番も開発も非 Docker | ゼロから構築。まず「イメージ + Features」で最小に始め、ミドルウェアが要る時のみ compose 化 |

**軸B: Docker/Compose 配置パターン**

| パターン | 状況 | 主戦略 |
|---|---|---|
| B-1 | モノレポ・複数 Docker・複数 Compose | ルート compose で各アプリ compose を `include`（本命） |
| B-2 | モノレポ・複数 Docker・単一 Compose | 単一 compose + サービス別 `devcontainer.json` |
| B-3 | モノレポ・単一 Docker・単一 Compose | 単一 compose を参照する devcontainer。必要なら `workspaceFolder` で対象アプリを指す |
| B-4 | 単一アプリ・レポ・Docker/Compose を内包 | 単一アプリ向け devcontainer（compose 参照 or Dockerfile/image 直結） |

> 軸Aが A-3（Docker 皆無）の場合、軸Bは「これからどう置くか」の設計対象になる。モノレポでサービス連携が無い小規模なら、無理に compose を作らず image+Features の単一 devcontainer で足りることも多い。

---

## Phase 1: 確認（選択肢提示による確認）

偵察結果（2軸の分類・検出した技術スタック・対象アプリ候補）を**先に要約提示**してから、推奨案を含む複数の選択肢を提示してユーザーに以下を確定する。憶測で進めない。

必須で確認する項目:

1. **モード**: 「実施（`.devcontainer/` 一式を生成）」か「計画策定のみ（計画書を出力）」か
2. **対象範囲**: モノレポなら、どのアプリ/サービスを devcontainer 化するか（全部 / 一部）
3. **接続スタイル**（A-3 や単一アプリで分岐する時）: ミドルウェア（DB等）が必要か → 必要なら compose、不要なら image+Features
4. **ベース方針に迷う場合のみ**: 既存 Dockerfile 流用か、軽量イメージ + Dev Container Features か

対象の状況で自明な項目は確認を省き、判断理由を一言添えて進めてよい（過剰な質問はしない）。

---

## Phase 2: 設計（戦略決定）

2軸の分類とユーザー回答から構成を確定する。判断に迷ったら下表を使う。

| 状況 | 推奨構成 |
|---|---|
| 既存 compose があり開発で使っている（A-1） | `dockerComposeFile` でその compose を参照し、開発差分は override で重ねる |
| 本番 Dockerfile はあるが開発は非 Docker（A-2） | 開発用 compose を新設し、本番 Dockerfile の dev 用 `target` を `build.target` で指定 |
| Docker 皆無・ミドルウェア不要（A-3, B-4 寄り） | compose 無し。`image`（または最小 Dockerfile）+ Dev Container Features で構築 |
| Docker 皆無・DB等が必要（A-3 + サービスあり） | 開発用 compose を新設（app + db 等）。app サービスに devcontainer を接続 |
| モノレポ・各アプリ自前 compose（B-1） | **`references/monorepo-devcontainerize-practice.md` を必読**。ルート compose で `include` |
| モノレポ・単一 compose（B-2/B-3） | 単一 compose + サービス別/対象別 `devcontainer.json`（同ファイル参照） |

**モノレポ（B-1/B-2）の設計時は必ず `references/monorepo-devcontainerize-practice.md` を読むこと。** `include` の必要性、ビルドコンテキストをルートにする理由、サービス名の名前空間化、プロジェクト名衝突、override 分離など、モノレポ特有の落とし穴と対策が網羅されている。

devcontainer.json のフィールド、Dev Container Features、image/Dockerfile/compose の使い分け、単一アプリ・ゼロ構築の雛形は `references/devcontainer-building-blocks.md` を参照する。

---

## Phase 3: 実行

### 実施モード — 構成生成

設計に従い、必要なファイルだけを生成・編集する。最小変更を徹底し、既存 compose/Dockerfile は原則書き換えない（開発差分は override や devcontainer 側で重ねる）。

生成しうるファイル:

- `.devcontainer/devcontainer.json`（単一アプリ）または `.devcontainer/<app>/devcontainer.json`（モノレポ・サービス別）
- 必要に応じ `compose.devcontainer.yaml`（開発差分の override）/ 開発用 `Dockerfile`
- A-3 でルート compose を新設する場合のみ、ルート compose

各生成ファイルには「なぜこの値か」を要点だけコメントで残す（マウント先・コンテキスト・target など意図が読み取りにくい箇所）。生成後、Phase 4 の検証手順を必ず提示する。

### 計画モード — 計画書出力

リポジトリ内に `DEVCONTAINER_PLAN.md`（場所はユーザー確認可）を出力する。構成は以下を基本とする:

```markdown
# Dev Containers 導入計画

## 1. 現状サマリ
（2軸の分類: 軸A=?, 軸B=? / 技術スタック / 既存 Docker 資産）

## 2. 導入方針
（採用する戦略と、その選定理由）

## 3. 構成案
（ディレクトリツリー + 主要ファイルの役割と雛形）

## 4. 導入ステップ
（順序付きの作業手順。1ステップ=1意味のある単位）

## 5. 落とし穴と対策
（対象に該当するリスク。モノレポなら名前空間化・include 等）

## 6. 検証方法
（起動確認・動作確認の具体手順）

## 7. 未決事項 / 要確認
```

---

## Phase 4: 検証 / 引き継ぎ

生成（または計画）した構成の確認手順を提示する。可能ならコマンドで静的検証まで行う。

- **compose の妥当性**: `docker compose -f <file> config`（`include` 解決・相対パス・サービス名衝突の検出に有効）
- **devcontainer の起動**: VS Code「Dev Containers: Reopen in Container」、または CLI `devcontainer up --workspace-folder <dir>`（`@devcontainers/cli` がある場合）
- **接続後の確認**: `workspaceFolder` が意図どおりか、`.git` がコンテナから見えるか、必要ツール/拡張が入っているか

最後に、生成物（または計画）の要点・残課題・次の一手を簡潔に報告する。

---

## 原則（全モード共通）

- **開発者の単体起動体験を壊さない** — 既存の `docker compose up` 等が従来どおり動くことを最優先。devcontainer はその上に重ねる。
- **最小変更** — 依頼範囲に集中。既存 compose/Dockerfile の書き換えは避け、override で差分を表現する。
- **再現性** — バージョンや Features を明示し、「手元でだけ動く」設定を避ける。
- **確認優先** — 不確実な点は、推奨案を含む複数の選択肢を提示してユーザーに確認してから進む。

## 参照ファイル

- `references/monorepo-devcontainerize-practice.md` — モノレポ導入の詳細（`include`・名前空間化・override・チェックリスト）。B-1/B-2 で必読。
- `references/devcontainer-building-blocks.md` — devcontainer.json の主要フィールド、Dev Container Features、image/Dockerfile/compose の使い分け、単一アプリ・ゼロ構築の雛形、検証コマンド。