Orchestrator Pipeline（共有エンジン）
orch-* スキルは軽量なラッパーです。作業を再実装することはなく、リクエストを分類し、このパイプラインのどのフェーズを実行するかを選択し、各フェーズを既存のECCエージェントまたはコマンドに委譲します。このファイルがそのパイプラインです。
このエンジンを直接呼び出すのではなく、操作スキル（
orch-add-feature、orch-fix-defectなど）を呼び出してください。このファイルは、操作スキルが参照する定義書です。
使用タイミング
orch-*操作スキルが実行されるときに間接的に読み込まれます。- ファミリーに新しい操作を追加する場合や、共有フェーズ、ゲート、エージェントマップを調整する場合にのみ直接参照してください。
操作ファミリー
| スキル | 操作 | トリガー | 最初のアクション |
|---|---|---|---|
orch-add-feature | 機能追加 | 機能がまだ存在しない | 新しいスライスを調査＋計画 |
orch-change-feature | 変更 | 動作はするが、望ましい動作と異なる | 既存の動作とそのテストを修正 |
orch-fix-defect | 修正 | 壊れている；動作が間違っている | 失敗するテストで再現し、修正 |
orch-refine-code | リファクタリング | 動作はそのまま、構造を改善 | テストをグリーンに保ちながら再構築 |
orch-build-mvp | MVP | 設計/仕様書からブートストラップ | ドキュメントを取り込む → 垂直スライス |
これらのラッパーは、既存のECCコマンドを置き換えるのではなく、組み合わせます：
/feature-dev、/plan、/code-review、/build-fix、/refactor-clean、/gan-build、およびtdd-workflowスキル。orch-*ファミリーは、共有サイズ分類器と2つのゲートをそれらの上に追加し、1つの傘が5つの操作すべてを一貫してカバーします。
ステップ0 — サイズ分類（適正規模化）
儀式の規模は影響範囲に応じて拡大します。3つのシグナルでリクエストをスコアリングし、いずれかのシグナルが到達した最高の階層を採用し、結果を1行で表示してユーザーがオーバーライドできるようにします：
| 階層 | 影響ファイル数 | 新しい依存関係/契約 | 設計の曖昧さ | 実行されるフェーズ |
|---|---|---|---|---|
| trivial | 1ファイル、数行 | なし | なし — 変更は明白 | 4 → 5 → 6 |
| small | 1ファイル/1関数 | なし | コードを読めば明確 | (1 軽量) → 4 → 5 → 6 |
| standard | 2–5ファイル | 新しい内部モジュールの可能性あり | 1つの実際の選択肢がある | 1 → 2 → 4 → 5 → 6 |
| large | 多数/横断的 | 新しい外部依存、公開API、または仕様書 | 複数の未解決の質問 | 1 → 2 → (3) → 4 → 5 → 6 |
フェーズ0（インテーク）は常に実行され、上記のマスク列からは省略されています。タイブレーカー：セキュリティトリガー（下記）または公開API/契約に触れるものは、ファイル数に関係なく少なくとも standard となります。
フェーズ
各フェーズは委譲します — インラインで作業を行うことはありません。
- 0. インテーク — リクエストを再述します。
orch-build-mvpの場合は、仕様/設計書を読み、スコープ、確定した決定事項、機能リストを抽出します。 - 1. 調査と再利用 —
rules/common/development-workflow.mdに従い：gh search repos/gh search code、次に Context7 / ベンダードキュメント、次にパッケージレジストリ、最後に Exa。新しいコードよりも実績のある実装を採用することを優先します。 - 2. 計画 —
plannerエージェント（構造的な決定にはarchitect/code-architect）に委譲します。薄い垂直スライスとして順序付けられたtask_listを出力します。 → ゲート1 - 3. スキャフォールド —
orch-build-mvpのみ：最初のエンドツーエンドスライスを立ち上げます。 - 4. 実装（TDD） — 各タスクを
tdd-guideエージェント（またはtdd-workflowスキル）で駆動します：レッド → グリーン → リファクタリング。操作の最初のアクションルールを尊重します。 - 5. レビュー —
code-reviewerエージェント //code-review。差分がセキュリティトリガー（下記）に触れる場合は常にsecurity-reviewerを追加します。 - 6. コミット — 従来のコミットメッセージ（
feat:/fix:/refactor:/ ...）、論理チャンクごとに1つ。 → ゲート2
2つのゲート
このファミリーはゲート付きであり、自律的ではありません：
- ゲート1 — 計画後。
task_listを提示します；ユーザーが承認するまで実装コードを書きません。 - ゲート2 — コミット前。 差分サマリーと提案メッセージを提示します；ユーザーが確認するまでコミットしません。
ゲート間の処理は停止せずに続行します。
エージェント/コマンドマップ
| フェーズ | プライマリ | フォールバック/エスカレーション |
|---|---|---|
| インテーク/理解 | code-explorer | 変更、修正、リファクタリング前に既存パスをトレース |
| 計画 | planner | 構造的な呼び出しには architect、code-architect |
| 実装 | tdd-guide（または tdd-workflow スキル） | ビルドエラー時は build-error-resolver / /build-fix |
| レビュー | code-reviewer / /code-review | 言語レビューアー（python-reviewer、typescript-reviewer など） |
| セキュリティ | security-reviewer | — |
| MVP 内部ループ | /gan-build "<簡単な説明>" --skip-planner | gan-generator → gan-evaluator を駆動；--max-iterations / --pass-threshold を調整 |
言語レビューアーはリポジトリに合わせてください（リポジトリ自身の CLAUDE.md を参照）。
セキュリティレビュートリガー
差分が次のいずれかに触れる場合は security-reviewer を呼び出します：認証または認可、ユーザー入力処理、データベースクエリ、ファイルシステムパス、外部API呼び出し、暗号化、またはシークレット/クレデンシャル。（rules/common/security.md による。）
引き継ぎ成果物
パイプラインは隠れた状態を持ちません — 計画ドキュメントが引き継ぎそのものです：
task_list（Planから）が実装ループを駆動します。- 大規模な作業では、
rules/common/development-workflow.mdに従い、PRD / アーキテクチャ / システム設計をリポジトリのdocs/に出力する場合もあります。 - レビュー結果（CRITICAL / HIGH）はゲート2前に解決されなければなりません。
検証
- サイズ階層が明示され、作業と一致していること
- ゲート1（計画）とゲート2（コミット）の両方が尊重されていること
security-reviewerがセキュリティトリガーに触れた場合にのみ実行されたこと- コミットが従来の形式で、1つの論理変更にスコープされていること
- 新しい/変更された動作にテストがあり、
rules/common/testing.mdに従いカバレッジが80%以上であること