---
name: implementation-developing
description: TDD（RED→GREEN→REFACTOR）でフェーズ単位の新機能実装やバグ修正を行う。docs/TODO.md があるとフェーズ管理し、なければ単独タスクとしてサイクルを回す。テストファーストを厳格に遵守。「実装したい」「TDDで実装」「機能を追加」「バグを修正」などで起動。
argument-hint: "[タスク説明]"
---

# /implementation-developing - TDD実装コマンド

Kent Beck の TDD 方法論と高凝集度・低結合度・コロケーションの原則に従って実装する。
RED→GREEN→REFACTOR サイクルをテストファーストアプローチで厳格に遵守する。

## 参照ルール

- TDDルール: @rules/core/tdd.md
- 設計原則: @rules/core/design.md
- テストルール: @rules/core/testing.md
- コミットルール: @rules/core/commit.md
- アーキテクチャパターン: `references/architecture-patterns.md` (高凝集度・低結合度・コロケーションの詳細)

## 使い方

### 引数付き起動

```
/implementation-developing ログインフォームにバリデーションを追加
```

### 引数なし起動（対話的）

```
/implementation-developing
```

### コンテキストからの推論

事前の会話でタスクが明確な場合、コンテキストから理解する。

---

## [1/4] タスク準備

### タスク説明の取得

引数からタスク説明を取得する：
- `$ARGUMENTS` が存在する場合: そのまま使用
- `$ARGUMENTS` が空の場合: ユーザーに質問

```
タスク説明: $ARGUMENTS
```

$ARGUMENTS が空の場合、以下の質問をする:

「どのようなタスクを実装しますか？具体的なタスク説明を入力してください。

例：
- ユーザー認証にバリデーション機能を追加
- APIレスポンスのエラーハンドリングを修正
- 商品一覧のページネーションを実装
」

### Design Thinking（設計思考）

実装前に以下の観点で設計を検討する:

**1. 責務の明確化**
- この機能の単一責務は何か？
- この変更は既存の責務を侵害しないか？
- テストしやすい単位に分割できるか？

**2. 依存関係の分析**
- このモジュールが依存するものは何か？
- 依存を注入可能にできるか？（テストダブルで置換可能か）
- 循環依存が発生しないか？

**3. 配置の決定**
- この機能はどこに配置すべきか？（コロケーション原則に従う）
- 関連するテスト・型・ヘルパーは同じ場所に配置できるか？
- 変更時に影響範囲が最小化されるか？

### 既存ドキュメントの確認

Read ツールで `docs/DESIGN.md` と `docs/TODO.md` の存在を確認する。

**docs/TODO.md が存在する場合**：
- 内容を読み取り、フェーズ構成を把握
- 各フェーズ内の RED/GREEN/REFACTOR タスクを確認

TODO.md の構造例：
```markdown
### フェーズ1: バージョン計算関数の実装 (semver.rs)

- [ ] [RED] calculate_latest_patch のテスト作成
- [ ] [GREEN] calculate_latest_patch の実装
- [ ] [REFACTOR] calculate_latest_patch のリファクタリング

### フェーズ2: API統合 (api.rs)

- [ ] [RED] fetch_versions のテスト作成
- [ ] [GREEN] fetch_versions の実装
- [ ] [REFACTOR] fetch_versions のリファクタリング
```

**docs/DESIGN.md が存在する場合**：
- 内容を読み取り、設計方針を把握
- 実装時の参考として使用

**TODO.md / DESIGN.md がない場合**：
- 引数のタスク説明から RED→GREEN→REFACTOR を 1 サイクルとして単独実行する

---

## [2/4] フェーズ実行

### TodoWrite でタスク管理

現在のフェーズのタスクを TodoWrite で管理する:

```javascript
TodoWrite({
  todos: [
    { content: "[RED] calculate_latest_patch のテスト作成", activeForm: "テストを作成している", status: "pending" },
    { content: "[GREEN] calculate_latest_patch の実装", activeForm: "実装している", status: "pending" },
    { content: "[REFACTOR] calculate_latest_patch のリファクタリング", activeForm: "リファクタリングしている", status: "pending" },
    // ...
  ]
})
```

### RED-GREEN-REFACTOR サイクルの実行

フェーズ内の各タスクを順番に実行する。

#### RED タスク（テスト作成）

1. TodoWrite で該当タスクを `in_progress` に更新
2. **implementation-writing-tests** スキルを使用してテストを作成
3. **サブエージェントでテスト実行** (後述) して**失敗を確認**
4. `docs/TODO.md` の該当行を `[x]` に更新
5. TodoWrite で該当タスクを `completed` に更新

#### GREEN タスク（実装）

1. TodoWrite で該当タスクを `in_progress` に更新
2. テストを通過する**最小限の実装**を行う
3. **サブエージェントでテスト実行**して**成功を確認**
4. `docs/TODO.md` の該当行を `[x]` に更新
5. TodoWrite で該当タスクを `completed` に更新

#### REFACTOR タスク（リファクタリング）

1. TodoWrite で該当タスクを `in_progress` に更新
2. **設計原則チェックリスト**に従ってコード品質を改善
3. **サブエージェントでテスト実行**して**成功を確認**
4. `docs/TODO.md` の該当行を `[x]` に更新
5. TodoWrite で該当タスクを `completed` に更新

**設計原則チェックリスト**:

| カテゴリ           | チェック項目                   | 確認内容                                                      |
| ------------------ | ------------------------------ | ------------------------------------------------------------- |
| **SOLID**          | 単一責任原則 (SRP)             | 1つの関数/モジュールが1つの責務のみを持っているか             |
|                    | 依存性逆転原則 (DIP)           | 具象ではなく抽象（インターフェース/トレイト）に依存しているか |
|                    | インターフェース分離原則 (ISP) | 使わないメソッドへの依存を強制していないか                    |
| **テスタビリティ** | 依存性注入                     | 依存関係が外部から注入可能か（モックしやすいか）              |
|                    | 純粋関数                       | 副作用を分離し、可能な限り純粋関数にしているか                |
|                    | グローバル状態                 | グローバル変数や静的状態に依存していないか                    |
| **構造**           | 高凝集度                       | 関連する機能が同じモジュールにまとまっているか                |
|                    | 低結合度                       | モジュール間の依存が最小限か                                  |
|                    | 重複排除 (DRY)                 | 同じロジックが複数箇所に存在していないか                      |
| **シンプルさ**     | YAGNI                          | 現時点で不要な抽象化や機能を追加していないか                  |
|                    | KISS                           | 必要以上に複雑な実装になっていないか                          |
| **境界**           | 公開API最小化                  | 公開する関数/型は必要最小限か                                 |
|                    | モジュール境界                 | 責務ごとに適切にモジュール分割されているか                    |

**リファクタリングの優先順位**:
1. テスタビリティの確保（DI、純粋関数化）
2. 単一責任の徹底
3. 重複の排除
4. 命名の改善

### テスト実行（サブエージェント）

トークン消費を抑えるため、テスト実行は Agent ツールでサブエージェントに委譲する。

```javascript
Agent({
  description: "テスト実行",
  prompt: `プロジェクトのテストを実行し、結果を報告してください。

テストコマンド: [プロジェクトに応じたコマンド]

報告形式:
- 全テスト成功の場合: "SUCCESS: X tests passed"
- 失敗がある場合: "FAILED: 以下のテストが失敗" + 失敗したテスト名とエラーメッセージのみ

注意: 成功したテストの詳細は報告不要。失敗したテストの情報のみ返すこと。`,
  subagent_type: "general-purpose",
  model: "haiku"
})
```

**サブエージェントの報告例**:
```
# 成功時
SUCCESS: 15 tests passed

# 失敗時
FAILED: 以下のテストが失敗
- test_calculate_latest_patch: expected "1.2.5" but got "1.2.3"
- test_calculate_latest_minor: assertion failed at line 42
```

**実装のルール**:
- 現在のテストを通過するために**必要最小限**のコードのみ書く
- 将来の要件を先取りしない
- 過度な抽象化を避ける

---

## [3/4] フェーズレビューと自動修正

フェーズ内のすべてのタスク（RED/GREEN/REFACTOR）が完了したら、以下を実行する。

### ステップ1: 品質チェック（自動）

```bash
# プロジェクトに応じたコマンドを実行
npm run lint     # または cargo clippy, go vet など
npm run format   # または cargo fmt, gofmt など
npm run build    # または cargo build, go build など
npm test         # または cargo test, go test など
```

**品質チェック失敗時**:
1. 問題を自動修正
2. 再度品質チェックを実行
3. 通過するまで繰り返す（最大3回）

### ステップ2: 簡易セルフレビュー（1回のみ）

フェーズの差分を確認し、以下のチェックリストでレビューする:

```bash
git diff HEAD~N  # フェーズ開始からの差分（N はフェーズ内のコミット数）
```

**セルフレビューチェックリスト**:

| 観点       | 確認項目                                                                     |
| ---------- | ---------------------------------------------------------------------------- |
| テスト     | テストが意図した振る舞いを検証しているか。重要なエッジケースが漏れていないか |
| 命名       | 変数・関数・型の名前が意図を正確に表しているか                               |
| 設計       | 単一責任原則に違反していないか。不要な依存関係を作っていないか               |
| 重複       | 同じロジックが複数箇所に存在していないか                                     |
| エラー処理 | エラーが適切に処理され、握りつぶされていないか                               |

**問題を発見した場合**:
1. その場で修正
2. テストを再実行して成功を確認

**問題がない場合**:
- 次のステップに進む

### ステップ3: 次フェーズへ進行

自動的に次のフェーズに進む:
1. 次のフェーズがあれば [2/4] フェーズ実行に戻る
2. すべてのフェーズが完了していれば [4/4] 完了処理へ

---

## [4/4] 完了処理

### 完了サマリー

```
✓ 開発が完了しました

実装内容:
- [実装した機能/修正のリスト]

作成/変更したファイル:
- [ファイルパスのリスト]

テスト結果:
- [テスト数] tests passed

完了したフェーズ:
- [x] フェーズ1: バージョン計算関数の実装
- [x] フェーズ2: API統合
```

### 次のアクション確認

```javascript
AskUserQuestion({
  questions: [
    {
      question: "すべてのフェーズが完了しました。次のアクションを選択してください。",
      header: "次のアクション",
      options: [
        { label: "コミット", description: "変更をコミットする" },
        { label: "完了", description: "開発を終了" }
      ],
      multiSelect: false
    }
  ]
})
```

**「コミット」を選択された場合**:
- `workflow-commit` スキルを使用してコミットを作成 (push はユーザが手動)

---

## バグ修正プロセス

1. テストでバグを再現（テストは失敗するべき）
2. 最小限の変更で修正
3. エッジケーステストを追加
4. 必要に応じてリファクタリング

## フェーズ管理のルール

1. **フェーズ内タスクは順番に実行** — 飛ばさない
2. **各タスク完了時に TODO.md を更新** — 進捗を可視化
3. **フェーズ完了時に簡易セルフレビューを実施** — 問題があればその場で修正後に自動進行
4. **ユーザー確認不要の指摘はその場で修正** — 命名改善、フォーマット、明らかなコード品質改善など
5. **ユーザー確認が必要な指摘は TODO.md に記録** — 設計変更、振る舞いの変更、トレードオフの判断など。AskUserQuestion で確認してから修正

## アンチパターン（避けるべきこと）

- 複数のフェーズを同時に実装
- レビューなしで次のフェーズに進む
- ユーザー確認が必要な指摘を確認せずに修正する
- TODO.md の更新を忘れる
- 失敗するテストなしにプロダクションコードを書く
- テストを通過させるために必要以上のコードを書く
- 同じコミットで構造的変更と動作的変更を混ぜる

---

**覚えておくこと: すべての実装はテスト駆動でなければならない。例外なし。**