Dev Impl

---
name: dev-impl
description: This skill should be used when the user asks to "dev-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". TDDをガードレールとしたテストファースト実装を行う。通常モード（Plan+タスク指定）とクイックモード（直接指示）に対応。
argument-hint: '<plan-name> <task-id> | "<instruction>"'
---

# Dev Impl

TDDをガードレールとして、テストを先に書いてから実装するコアワークフロー。タスクファイルに基づく通常モードと、Plan不要の軽量クイックモードの2つの実行モードを持つ。

## 前提知識

### dev-*スキルフロー内の位置

```
dev-context → dev-plan → [dev-impl] → dev-verify
                                  ↘ dev-debug (失敗時)
```

### 実行モード

| モード | 引数 | 用途 |
|-------|------|------|
| 通常モード | `<plan-name> <task-id>` | Planのタスクを1つ実装 |
| クイックモード | `"修正指示"` | 軽量な修正・調整（Plan不要） |

### 品質優先のプライオリティ

**品質 > 速度 > トークン消費** の順で判断する。

## ワークフロー: 通常モード

`/dev-impl <plan-name> <task-id>` で実行。

### Step 1: コンテキスト構築（最小限）

インターフェースファーストで必要最小限のファイルだけ読み込む:

```
優先順位:
1. docs/dev/context.md（プロジェクト全体像）
2. タスクファイル（インターフェース定義・テスト方針）
3. 関連する型定義ファイル ← 必要時のみ
4. 関連する既存テストファイル（パターン参考）← 必要時のみ
5. 実装ファイル（関連関数のみ）← 必要時のみ
```

TodoWrite でタスク進捗のトラッキングを開始する。

### Step 2: テストケース生成（Red）

タスクファイルの Test Strategy に基づきテストコードを生成する:

1. 既存テストファイルのパターン（context.mdの規約）に合わせる
2. タスクのインターフェース定義に基づくテストケースを記述する
3. テスト実行コマンド（context.md から取得）でテストを実行する
4. **失敗を確認する**（Red状態）

テストが先に通ってしまう場合は、要件やテストの妥当性を再確認する。

### Step 3: 実装（Green）

テストを通す最小限の実装を生成する:

1. インターフェース定義に準拠したコードを書く
2. **Intent コメントを付与する**（後述の「Intent コメントルール」に従う）
3. テスト実行 → **成功を確認する**（Green状態）
4. 失敗した場合はエラーを分析し修正する（最大3サイクル）
5. 3サイクルで解決しない場合は `/dev-debug` の使用を案内する

### Step 4: リファクタリング + 品質チェック

テストがGreenの状態で以下を実行する:

#### 4a. 500行ルール（厳密適用）
関連するすべてのファイルの行数を Bash で確認する（絶対パスを使用）:
```bash
wc -l "$(git rev-parse --show-toplevel)/<ファイルの相対パス>"
```
500行を超えるファイルがある場合:
- 責務の境界で分割する（Single Responsibility Principle）
- テストファイルも対応して分割する
- インポート/エクスポートの整合性を維持する
- 分割後にテストを再実行する

#### 4b. セキュリティチェック
実装コードを確認し、以下の問題がないか検証する:
- インジェクション（SQL, コマンド, XSS）
- 認証・認可チェックの漏れ
- 機密情報のログ出力・エラーメッセージでの露出
- ユーザー入力のバリデーション不足

#### 4c. パフォーマンスチェック
- N+1問題（ループ内のDB/APIクエリ）
- メモリリーク（イベントリスナー未解除、クロージャ参照保持）
- 非効率なアルゴリズム（O(n^2)以上で改善可能な箇所）

#### 4d. コード品質
- 重複コードの排除
- 命名の改善
- 不要なコメントの削除

#### 4e. カバレッジチェック

1. `docs/dev/context.md` の Test Framework セクションから Coverage Threshold を取得する
2. タスクファイルの Files セクションから対象パッケージを特定する
3. パッケージごとにカバレッジを計測する（Coverage Command をパッケージ単位で実行）
4. `[no test files]` は 0% として扱う
5. **閾値未達時**: テストを追加し再計測する（最大3サイクル）
6. **3サイクル後も未達**: 🟡 として報告し続行する（ブロッキングにしない）

テスト再実行 → 成功維持を確認する。

### Step 5: 信号機レポート + 完了処理

#### 確信度レポートの出力

実装した各ファイルに確信度を付与し、ユーザーに報告する:

```markdown
## dev-impl 確信度レポート

### カバレッジ結果
| パッケージ | カバレッジ | 閾値 | 結果 |
|-----------|----------|------|------|
| internal/handler | 85.2% | 80% | OK |

### 🔵 前工程指示（レビュー低優先）
- [ファイル名](パス) — 既存パターン準拠

### 🟡 妥当な推測（要確認）
- [ファイル名](パス) — [確認すべき点]

### 🔴 AI推論補完（人間の確認必須）
- [ファイル名](パス) — [判断が必要な理由]
```

#### 完了処理
1. タスクファイルの `status` を `done` に更新する
2. TodoWrite を更新する

### Step 6: Docker クリーンアップ

プロジェクトルートに `docker-compose.yml` または `docker-compose.yaml` が存在するか確認する。存在する場合:

1. `docker compose down` を実行してコンテナを停止する
2. 停止に失敗した場合はユーザーに報告する（ブロッキングにしない）

## ワークフロー: クイックモード

`/dev-impl "修正指示"` で実行（Plan名なし）。

### 用途
- テストケースの微修正 + 実装の調整
- 小さなバグ修正
- 既存テストへのケース追加
- 軽量なリファクタリング

### フロー
1. `docs/dev/context.md` を読み込む（あれば）
2. Explore サブエージェント（haiku）で関連ファイルを探索する
3. テスト修正 → 実装修正（またはその逆）
4. テスト実行で検証する
5. 500行ルールのチェック
6. 信号機レポートを簡潔に出力する
7. Docker クリーンアップ（Step 6 と同様）

## 複雑度に応じた戦略

タスクファイルの `estimated_complexity` に応じて戦略を切り替える。詳細は `references/impl-strategies.md` を参照。

| 複雑度 | 戦略 | テスト+実装 |
|-------|------|-----------|
| low | バッチ生成 | テスト+実装を一括生成し、テスト実行で検証 |
| medium | 標準サイクル | テスト→Red確認→実装→Green確認 |
| high | 段階的 | 1テストずつ追加→1つずつGreenにする |

## サブエージェント戦略

| 用途 | サブエージェントタイプ | モデル |
|------|---------------------|--------|
| 関連コード探索 | Explore | haiku |
| テスト雛形生成 | general-purpose | haiku |
| 標準実装 | メインで実行 | sonnet |
| 複雑なロジック | メインで実行 | opus |

## Intent コメントルール

生成するソースコードの各関数・メソッドに、設計判断の理由を示す Intent コメントを付与する。

### 信号機システム（🔵🟡🔴）

- 🔵 **前工程指示**: タスクファイル・plan.md・context.md で明示的に指示されている設計判断
- 🟡 **妥当な推測**: 指示された内容から推論した妥当な設計判断（ベストプラクティス準拠等）
- 🔴 **AI推論補完**: 前工程に根拠がなくAIが推論で補完した設計判断

### コメント形式

言語のコメント構文に従い、関数・メソッドの直前に記述する:

```go
// 🔵 Intent: タスクファイルで指定された TodoRepository インターフェースを実装。
//    RETURNING 句で INSERT と ID 取得を1クエリで完結させる。
func (r *PostgresTodoRepository) Create(ctx context.Context, todo *model.Todo) error {
```

```go
// 🟡 Intent: context.md のエラーハンドリング規約に準じて fmt.Errorf でラップ。
//    リポジトリ層のエラーをサービス層で識別可能にするため。
func (s *TodoService) GetByID(ctx context.Context, id string) (*model.Todo, error) {
```

```go
// 🔴 Intent: ページネーションのデフォルト値。前工程に指定なし。
//    一般的な Web API の慣習に基づき limit=20 を採用。
const defaultPageSize = 20
```

### 付与ルール

- **すべての public 関数・メソッド** に Intent コメントを付与する
- private 関数は設計判断がある場合のみ付与する（自明な処理は省略可）
- テストコードには付与しない
- 1コメント = 1-2行で簡潔に。冗長な説明は避ける
- 既存コードに追記する場合、既存の Intent コメントを維持する

## ルール・制約

- テストを先に書く。テストが通る前に次のステップに進まない
- すべてのファイルは **500行以内**。超過時はリファクタリングで分割する
- タスクファイルの dependencies に含まれるタスクがすべて `done` であることを確認してから開始する
- context.md が存在しない場合、先に `/dev-context` を案内する
- 通常モードでタスクファイルが存在しない場合、`/dev-plan` を案内する
- テスト実行コマンドは context.md から取得する
- セキュリティ・パフォーマンス問題の 🔴 は修正してから完了する
- Bash コマンドはプロジェクトルートの **絶対パス** を使用する（`$(git rev-parse --show-toplevel)` でルートを取得）

## 追加リソース

### リファレンスファイル

- **`references/impl-strategies.md`** — 複雑度別の実装戦略、インターフェースファースト読み込みの詳細、バッチモードの適用基準