計画→設計→実装→テスト→報告の全フェーズを統合実行するメタオーケストレーター。エスカレーション駆動でユーザー介入を最小化。
要件記述から、設計→実装→テスト→報告までを自律的に実行する。 ユーザーの介入は「計画承認」と「エスカレーション応答」の2箇所のみ。
Phase 0: 計画(対話) ← ユーザー承認必須
Phase 1: 設計(自律) ← エスカレーション時のみユーザー介入
Phase 2: 実装(自律) ← 同上
Phase 3: テスト(自律)
Phase 4: 報告
引数の <task-description> を元に、以下を整理してユーザーに提示:
╔══════════════════════════════════════╗
║ パイプライン計画 ║
╚══════════════════════════════════════╝
■ タスク概要
{task-description の要約}
■ スコープ
- 新規作成: {ファイル/コンポーネント}
- 変更: {既存ファイル/コンポーネント}
- 影響範囲: {テスト、設定等}
■ コンポーネント分割案
1. {component_a} — {責務}
2. {component_b} — {責務}
■ 技術的アプローチ
{主要な設計判断・技術選定}
■ リスク・懸念
{事前に判明しているリスク}
■ 推定規模
- 設計書: {n} ファイル
- 実装: {概算ファイル数}
→ この計画で進めてよいですか? [y / 修正指示]
これがパイプライン全体で唯一の必須ゲート。
y → Phase 1 へ承認後:
/pipeline-state init {task-name} 相当の処理を実行/design-phase 相当のロジックを実行:
Tier 1 の Finding がある場合:
═══ Phase 1 エスカレーション ═══
設計フェーズで以下の判断が必要です:
[E-1] <設計判断項目A>
内容: <選択肢A> / <選択肢B> / <選択肢C> のいずれを採用するか
影響: <影響を受けるコンポーネント> の設計に直結
→ どの方式を採用しますか?
[E-2] <設計判断項目B>
内容: <判断が必要な理由・背景>
→ <新規要素>の採用を承認しますか?
design → implementation に遷移設計フェーズ完了時にコンテキスト量を自己評価:
/compact を推奨依存順にコンポーネントを処理。各コンポーネントで impl-orchestrator 相当の6ステージを実行:
for component in dependency_order:
Stage 1: 準備(DESIGN/*.md + CLAUDE.md 読み取り)
Stage 2: 実装(sonnet サブエージェント)
Stage 3: 検証ゲート(build / type / test)
Stage 4: 並列レビュー(opus × 3: security / robustness / spec)
Stage 5: 指摘解決(エスカレーション分類 → 修正 or 報告)
Stage 6: 完了判定(PIPELINE-STATE.md 更新)
全コンポーネントの実装完了後:
/boundary-test detect — 境界を検出/boundary-test generate — テストを生成/boundary-test run — テストを実行Phase 2 中に蓄積された Tier 1 をまとめて提示。
implementation → testing に遷移コンテキスト管理: Phase 2 は最もコンテキストが肥大化するフェーズ。
/compact を推奨プロジェクト全体のテストを実行:
CLAUDE.md の ## Commands を優先。なければ自動検出:
| マーカー | コマンド |
|---|---|
| Cargo.toml | cargo test --workspace |
| package.json | npm test |
| build.gradle | ./gradlew test |
| go.mod | go test ./... |
| pyproject.toml | pytest |
spec-check 相当のチェックを全コンポーネントに対して実行:
robust-review 相当のチェックを変更ファイルに対して実行:
テスト/チェックで問題が見つかった場合:
iteration = 0
while issues_remain and iteration < 3:
修正を実行
テストスイート再実行
整合性再チェック
iteration++
if issues_remain:
エスカレーション報告に残存問題を含める
testing → reporting に遷移git diff --stat HEAD~{commits}
変更ファイル数、追加/削除行数のサマリー。
╔══════════════════════════════════════════════════╗
║ 自律開発パイプライン 完了レポート ║
║ タスク: {task-name} ║
║ フェーズ: Phase 0 → Phase 4 ║
╚══════════════════════════════════════════════════╝
■ 変更概要
ファイル: {n} changed, {n} insertions(+), {n} deletions(-)
設計書: {n} ファイル(DESIGN/)
実装: {n} ファイル
テスト: {n} ファイル
■ 検証ゲート結果
ビルド: pass ✓
型チェック: pass ✓
テスト: pass ✓ ({n} passed, {n} failed)
境界テスト: pass ✓ ({n} boundaries verified)
仕様整合性: pass ✓ (0 差分)
堅牢性: pass ✓ (0 S-Critical, 0 S-High)
■ レビュー結果サマリー
Security: S-Critical: {n} / S-High: {n} / S-Medium: {n} / S-Low: {n}
Robustness: S-Critical: {n} / S-High: {n} / S-Medium: {n} / S-Low: {n}
Spec: Missing: {n} / Diverged: {n} / Extra: {n} / Constraint: {n}
■ 対応結果
自律修正済み: {n} 件(Tier 2 + Tier 3)
エスカレーション: {n} 件(Tier 1 — Phase 0-2 で解決済み)
═══ 自律修正ログ(Tier 2: 事後報告) ═══
[1] SEC-1 | S-Critical | <path/to/handler>:<N>
修正: format!() → .bind()(SQLインジェクション対策)
[2] ROB-3 | S-Critical | <path/to/file>:<N>
修正: unwrap() → ? 変換
[3] SPEC-2 | Diverged | DESIGN/<component>.md:<N>
修正: 仕様を更新(Result ラップ追加を反映)
═══ エスカレーション履歴 ═══
[E-1] Phase 1 | <設計判断項目A> → resolved: <採用された選択肢>
[E-2] Phase 1 | <設計判断項目B> → resolved: 承認済み
═══ 残存リスク ═══
[R-1] ROB-8 | S-Medium | <path/to/file>:<N> — 空リスト未処理
[R-2] SEC-4 | S-Low | .env.example にサンプル値が残存
═══ 推奨アクション ═══
- ブラウザでの動作確認: {確認すべきページ/機能}
- 手動テスト: {自動化できなかったシナリオ}
- 残存リスクの対応判断
Phase を reporting に更新。パイプライン完了状態を記録。
パイプライン全体を通じたエスカレーションの扱い:
| タイミング | 動作 |
|---|---|
| Phase 0(計画) | 即時対話(ユーザーと合意形成中) |
| Phase 1(設計) | 蓄積 → フェーズ末に一括提示 → 回答待ち |
| Phase 2(実装) | 蓄積 → コンポーネント完了ごとに提示 → 回答待ち |
| Phase 3(テスト) | 蓄積 → 最終レポートに含める |
重要: エスカレーション待ちでもパイプラインは停止しない。
| フェーズ境界 | アクション |
|---|---|
| Phase 0 → 1 | — (コンテキスト小) |
| Phase 1 → 2 | checkpoint save + 設計書を閉じる(以降 Read で必要時取得) |
| Phase 2 内(コンポーネント間) | checkpoint save + /compact 推奨 |
| Phase 2 → 3 | checkpoint save + /compact 推奨 |
| Phase 3 → 4 | — (レポート生成のみ) |
コンテキストが圧迫された場合の緊急対応:
/clear を推奨パイプラインは任意のタイミングで中断・再開できる:
/dev-pipeline で再開可能」とユーザーに通知/dev-pipeline を引数なしで実行:
Pipeline "todo-crud-api" を検出しました。
現在: Phase 2 (implementation) — backend コンポーネント完了、frontend 未着手
→ 続行しますか? [y / 最初からやり直し / 中止]