Development Pipeline
タスクの規模に応じて2種類のパイプラインを使い分け、品質と効率を両立する開発プロセス。全てのフェーズはOrchestratorが実行し、Compliance Officerがゲートチェックで品質を保証する。
パイプライン概要
フルパイプライン
新機能追加、アーキテクチャ変更、複雑な設計判断を伴うタスク。要件定義からリサーチ、設計、実装、レビューまで全フェーズを通過する。
小規模タスク
バグ修正、UI微調整、設定変更など影響範囲が限定的で設計判断不要なタスク。1回のOrchestrator起動で完結する。
タスク規模の判定基準
POがタスクを受け取った時点で、以下の基準に従い規模を判定する。判定結果に応じて適用するパイプラインが決まる。
フルパイプライン
いずれか1つに該当- 新機能の追加 — 既存にない機能を新規で実装
- アーキテクチャの変更 — 構造的な設計変更
- 新しい依存パッケージの導入 — 外部ライブラリ追加
- 複数ファイルにまたがる大きな変更 — 影響範囲が広い
- データベーススキーマの変更 — テーブル/カラム追加・変更
小規模タスク
全てに該当する必要あり- バグ修正・UI微調整・設定変更・小規模リファクタリング
- 影響範囲が限定的 — 少数ファイルの変更で完結
- 設計判断が不要 — Architectの介入なしで実装可能
Plan Mode
全てのタスクは着手前に必ずPlan Modeに入る。いきなり実装に入ることは許されない。Plan Modeでコードベースを探索し、影響範囲を特定し、アプローチを設計する。
Plan Modeで作成したプランをユーザーが承認するまで、Orchestratorへの委譲は一切行えない。これはプロセスの最も基本的なルールである。
Plan Mode フロー
Plan File の記載事項
Context
なぜこの変更が必要か。背景と動機を記述する。
Approach
どう実現するか。技術的なアプローチの概要。
Impact
どのファイル・機能に影響するか。影響範囲の特定。
Phases
フェーズ構成。スキップするフェーズとその理由。
Risks
リスク・懸念事項。対策が必要な項目。
Plan Mode中はファイルの読み取り・探索のみ可能。ファイル編集は禁止。書き込みが許可されるのは .claude/plans/ 配下のplanファイルのみ。
フルパイプライン フェーズ詳細
10フェーズを5つのグループに分割し、Orchestratorをグループ単位で起動する。コンテキストウィンドウの制約を回避しつつ、phase-state.yaml で状態を引き継ぐ。
Phase 0-1: 準備 + 要件定義
mainブランチ最新から専用ブランチを作成し、要件定義ドキュメントを作成する。ブランチ命名規則: feature/, fix/, refactor/, docs/ + {project}/{description}
Phase 1.5: 技術リサーチ
MANDATORY技術リサーチフェーズは必須である。スキップ指定は null として扱われ、常に実行される。正確な技術情報なしに設計判断を行うことは禁止。
Phase 2a: RFC
Architectがスコープ・方向性・代替案を含むRFCを作成。CO Gateを通過後、POがユーザーにRFCの要約を提示し承認を得る。修正要求があればGroup 2aを再起動。
RFC Checkpoint で確認する項目
Scope
やること / やらないこと / 将来検討
Technical Direction
技術方向性と主要な技術選定
Alternatives
代替案と選定理由
Extensibility
拡張性方針
Phase 2b-3.5: 詳細設計 + テスト計画
RFC承認後、Architectが詳細設計を作成。Designerがui設計、Reviewerがテスト計画を策定する。テスト計画は次のGroup 3でテストコード作成の基盤となる。
Phase 4a-4d: テスト + 実装
Phase 4aのTesterモードでは実装コードを一切見せない。テスト仕様と設計書のみを入力として、テストコードを作成する。これにより93%のcheat rateを回避し、テストが仕様を正しく検証することを保証する。
テスト実行で失敗した場合、Developerが修正 → 再テストのサイクルを繰り返す。繰り返し失敗する場合はユーザーにエスカレーションされる。
Phase 5-8: レビュー + PR
gh pr merge コマンドの実行はGuardが物理的にブロックする。PRは作成まで。マージはユーザーが手動で確認・実行する。
Phase 9: 振り返り
タスク完了後、Secretaryが振り返りを実施。パターン分析、成功/失敗要因の抽出、ナレッジ更新を行い、phase-state.yaml を completed に更新する。
小規模タスクフロー
小規模タスクは1回のOrchestrator起動で全フェーズを一括実行する。フェーズ数は少ないが、品質基準は同じ。
小規模タスクでもTesterモードのテスト分離は維持される。テストコード作成時には実装コードを見せず、仕様ベースでテストを作成する。POがスキップ宣言した場合のみ省略可能。
委譲プロセス
POがユーザー承認済みプランをOrchestratorに委譲する手順。全てのOrchestrator起動時に、以下のプロセスが適用される。
委譲ステップ
委譲チェックリスト（省略不可）
全てのOrchestrator委譲プロンプトの末尾に以下を含める。1つでも欠けた場合、プロセス違反となる。
audit-log.mdにフェーズ遷移を記録（BRANCH_CREATE, PHASE_START/END, CO判定, PR_CREATED）- COゲートチェック実施（
small_task_start,small_task_to_review） - テスト工程実施（Spec作成 → Testerモード → 実装 → テスト実行）※POスキップ宣言がある場合を除く
phase-state.yamlを最終状態に更新04_implementation.mdを作成/更新- サブエージェントの「ナレッジ候補」を
.knowledge/{role}.mdに書き込み（候補なしの場合もphase-state.yamlにknowledge_updated: []を記録）
Codex並列実行
独立した小規模タスクが複数ある場合、Codexエージェントを活用して並列処理を行う。
並列実行可否の判定
独立タスク
- 異なるファイルを変更する
- タスク間に依存関係がない
- 共有リソースの競合がない
依存タスク
- 同じファイルを変更する
- タスク間に依存関係あり
- 順序が結果に影響する
並列処理フロー
テストコード作成（Testerモード）はテスト分離の品質を保つため、直列で実行する。Codexに投入するのは実装フェーズのみ。全テストコードが揃った後に並列実装を開始する。
エラーリカバリ
Orchestratorが失敗またはタイムアウトした場合、phase-state.yaml の last_error と current_phase を確認し、以下の戦略に従って対応する。
| エラー種別 | 具体例 | 対応戦略 | リトライ上限 |
|---|---|---|---|
| 一時的エラー | API タイムアウト、ネットワーク障害、レートリミット | 同じグループを再起動（retry_count + 1） |
3回 |
| 構造的エラー | 権限不足、ファイル不在、スキーマ不整合 | 原因を修正してから再起動 | 3回 |
| 不明なエラー | 再現性のない障害、予期しない状態 | ユーザーにエスカレーション | 即座 |
retry_count >= 3 に達した場合、自動リトライを停止し、ユーザーにエスカレーションする。状況・選択肢・推奨案の3点を提示する。
セッション再開時のリカバリ
新しいセッションで途中の作業を再開する場合、phase-state.yaml の status が in_progress または failed のものを検出し、ユーザーに再開を確認する。完了済みフェーズはスキップして続行する。