aibot88 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 に基づきテストコードを生成する:
- 既存テストファイルのパターン（context.mdの規約）に合わせる
- タスクのインターフェース定義に基づくテストケースを記述する
- テスト実行コマンド（context.md から取得）でテストを実行する
- 失敗を確認する（Red状態）
テストが先に通ってしまう場合は、要件やテストの妥当性を再確認する。
Step 3: 実装（Green）
テストを通す最小限の実装を生成する:
- インターフェース定義に準拠したコードを書く
- Intent コメントを付与する（後述の「Intent コメントルール」に従う）
- テスト実行 → 成功を確認する（Green状態）
- 失敗した場合はエラーを分析し修正する（最大3サイクル）
- 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. カバレッジチェック
docs/dev/context.mdの Test Framework セクションから Coverage Threshold を取得する- タスクファイルの Files セクションから対象パッケージを特定する
- パッケージごとにカバレッジを計測する（Coverage Command をパッケージ単位で実行）
[no test files]は 0% として扱う- 閾値未達時: テストを追加し再計測する（最大3サイクル）
- 3サイクル後も未達: 🟡 として報告し続行する（ブロッキングにしない）
テスト再実行 → 成功維持を確認する。
Step 5: 信号機レポート + 完了処理
確信度レポートの出力
実装した各ファイルに確信度を付与し、ユーザーに報告する:
## dev-impl 確信度レポート
### カバレッジ結果
| パッケージ | カバレッジ | 閾値 | 結果 |
|-----------|----------|------|------|
| internal/handler | 85.2% | 80% | OK |
### 🔵 前工程指示（レビュー低優先）
- [ファイル名](パス) — 既存パターン準拠
### 🟡 妥当な推測（要確認）
- [ファイル名](パス) — [確認すべき点]
### 🔴 AI推論補完（人間の確認必須）
- [ファイル名](パス) — [判断が必要な理由]
完了処理
- タスクファイルの
statusをdoneに更新する - TodoWrite を更新する
Step 6: Docker クリーンアップ
プロジェクトルートに docker-compose.yml または docker-compose.yaml が存在するか確認する。存在する場合:
docker compose downを実行してコンテナを停止する- 停止に失敗した場合はユーザーに報告する（ブロッキングにしない）
ワークフロー: クイックモード
/dev-impl "修正指示" で実行（Plan名なし）。
用途
- テストケースの微修正 + 実装の調整
- 小さなバグ修正
- 既存テストへのケース追加
- 軽量なリファクタリング
フロー
docs/dev/context.mdを読み込む（あれば）- Explore サブエージェント（haiku）で関連ファイルを探索する
- テスト修正 → 実装修正（またはその逆）
- テスト実行で検証する
- 500行ルールのチェック
- 信号機レポートを簡潔に出力する
- 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— 複雑度別の実装戦略、インターフェースファースト読み込みの詳細、バッチモードの適用基準