フェーズ 4: 実装

目的

計画に基づいて実際のコードを記述する。TDD（テスト駆動開発）で品質を保証し、サブエージェントや並列実行で効率を最大化する。

開始条件

• docs/workflow/implementation-plan.md に変更対象と検証方法がある
• 作業開始時のブランチ状態と既存テスト結果を確認できる

入力成果物

• docs/workflow/requirements.md
• docs/workflow/research.md
• docs/workflow/implementation-plan.md

実行手順

1. 計画の対象タスクと編集境界を確認する
2. 受入条件を表す失敗テストを追加し、期待した理由で失敗することを確認する
3. テストを通す最小の変更を実装し、対象テストを再実行する
4. 計画との差分と既知の制約を引き継ぎへ記録する

期待成果物

• コード差分と先行テスト
• docs/workflow/implementation-handoff.md

終了条件

• 計画対象のコードとテストが実装され、対象テストが成功している
• 計画との差分・既知の制約・検証結果を検証フェーズへ渡せる

失敗時の戻り先

• 設計前提が崩れた場合は計画へ戻る
• 既存挙動や外部仕様が不明なら調査へ戻る
• 受入条件の変更が必要なら要件理解へ戻り、承認を得る

Before / After

Before: 従来のやり方

• 一気に全コードを書き上げてからテスト
• 手動でファイルを開いてコピペしながら実装
• 並列可能な作業も直列で実行
• エラーが出たらアドホックに修正

After: ツール活用後

• RED-GREEN-REFACTOR サイクルで品質を保証
• サブエージェントが独立したコンテキストで並列実装
• MultiEdit で複数箇所を同時編集
• LSP のリアルタイム診断で即座にエラーを検知

レベル別アプローチ

Beginner

Level 1 プレイブック

入力例

計画: docs/workflow/implementation-plan.md
対象: order を表示順の正規データにするタスク。

コマンド / プロンプト

claude

計画の対象タスクだけを実装してください。現在の不一致を先に確認し、
order から一覧、前後ナビ、マップ、フェーズ番号を生成してください。
計画外を編集せず、結果を docs/workflow/implementation-handoff.md に記録してください。

生成物例

# 実装引き継ぎ
## 変更
- 公開 workflow を order で並べ、全表示へ利用した。
## 計画との差分
なし。

検証

git diff --check
npx tsc --noEmit
pnpm lint

出口判定

• コマンドが成功し、変更が計画の編集境界内にある
• 差分と実装引き継ぎを検証へ渡せる

Claude Code の基本ツールで実装する。

# 基本的な実装プロンプト
Claude Code > src/auth/login.ts にログイン機能を実装して

# MultiEdit で複数箇所を同時編集
Claude Code > このリファクタリングを全ファイルに適用して

# Edit で部分編集
Claude Code > src/utils/helpers.ts の formatDate 関数を修正して

# Bash でビルド確認
Claude Code > npm run build を実行してエラーがないか確認

手順:

1. Read で既存コードを確認
2. Edit / MultiEdit / Write でコードを変更
3. Bash でビルド・型チェックを実行
4. LSP 診断でリアルタイムにエラーを確認
5. 変更内容を確認

Intermediate

Superpowers の TDD とサブエージェント駆動開発を活用。

# Superpowers: test-driven-development（TDD強制）
# Iron Law: テストなしにプロダクションコードは書かない
# RED → 失敗を確認 → GREEN → 最小実装 → REFACTOR → リファクタ

# Superpowers: subagent-driven-development
# タスクごとに新鲜なサブエージェントをディスパッチ
# 2段階レビュー: 仕様準拠 → コード品質
# 実装ステータス: DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT

# OMC: executor エージェント（主要なコード記述）
> このタスクを実装して
# executor エージェント（sonnet）が実装を担当

# OMC: ralph（完了まで継続実行）
ralph この機能を実装して
# 完了確認まで継続。暗黙の部分完了を許さない

手順:

1. Superpowers TDD の RED フェーズでテストを先に書く
2. テストが失敗することを確認（Verify RED mandatory）
3. GREEN フェーズで最小実装
4. 全テストが通ることを確認（Verify GREEN mandatory）
5. REFACTOR フェーズでリファクタリング
6. OMC executor エージェントで独立タスクを並列実装

Advanced

OMC のチームパイプラインと ECC のマルチエージェントオーケストレーションを活用。

# OMC: team（チームパイプライン）
/team 5:executor "認証機能を実装"
# team-plan → team-prd → team-exec → team-verify → team-fix
# 複数の executor エージェントがタスクリストを共有して並列作業

# OMC: ultrawork（最大並列バースト実行）
ulw 全ての TypeScript エラーを修正
# 独立したタスクを並列エージェントに分散

# OMC: autopilot（アイデアから動くコードまで自律実行）
autopilot REST API を実装
# 単一リードエージェントが計画→実装→検証まで全自動

# ECC: multi-execute（オーケストレーション実行）
/multi-execute
# 複数エージェントの協調実行

# ECC: autonomous-loops（自律ループパターン）
/loop-start
# 逐次パイプライン、PR ループ、DAG オーケストレーション

手順:

1. OMC team でチームを編成し、タスクリストを共有
2. 各エージェントが独立したコンテキストで並列実装
3. 2段階レビュー（仕様準拠 + コード品質）を各タスク後に実行
4. OMC ultraqa で品質保証サイクルを実行
5. 全タスク完了後に統合テストを実行

ベストプラクティス

1. TDD を厳守 -- Superpowers の Iron Law: テストなしにプロダクションコードを書かない。テストを先に書き、失敗を確認してから実装する
2. サブエージェントで並列化 -- 独立したタスクは Superpowers subagent-driven-development か OMC ultrawork で並列実行。直列実行は時間の無駄
3. MultiEdit を活用 -- 1ファイルの複数箇所を変更する場合は MultiEdit を使用。個別の Edit を何度も呼ぶよりも効率的
4. worktree で分離 -- Superpowers using-git-worktrees や Claude Code の --worktree で、メインブランチに影響なく実装
5. LSP のリアルタイム診断 -- ファイル編集後に即座にエラーを検知。npm run build を待つより早い
6. AI生成コードのクリーンアップ -- OMC ai-slop-cleaner で、AIが生成しがちなボイラープレートや冗長なコメントを除去

よくある罠

テストを後回しにする

「実装が終わってからテストを書く」は TDD の逆。Superpowers の Rationalization table を使い、テストの後回しを防止する。

サブエージェントに大きすぎるタスクを割り当てる

「バックエンドを実装して」は1エージェントには大きすぎる。独立して検証できる粒度に分解してからディスパッチする。

並列実行のファイル競合

複数のエージェントが同じファイルを同時に編集すると競合が発生。ファイル境界を明確にし、同じファイルを複数エージェントが編集しないようにする。OMC team はこれを管理する。

AI生成コードの冗長性

AIは過剰なコメント、不要なエラーハンドリング、冗長な変数名を生成しがち。OMC ai-slop-cleaner で回帰安全性を保ちながら除去する。

コードレビューをスキップ

実装が完了したら即座にコミットせず、必ずコードレビューを通す。実装とレビューは別のコンテキストで行うべき。