/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 で確認する（絶対パスを使用）:

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: 信号機レポート + 完了処理

確信度レポートの出力

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

## 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が推論で補完した設計判断

コメント形式

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

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

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

// 🔴 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`** — 複雑度別の実装戦略、インターフェースファースト読み込みの詳細、バッチモードの適用基準