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 light) → 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. コミット — conventional commits（
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（計画から）が実装ループを駆動します。- 大規模な作業では、リポジトリの
docs/以下にPRD / アーキテクチャ / システム設計を出力する場合もあります（rules/common/development-workflow.mdに従います）。 - レビュー結果（CRITICAL / HIGH）はゲート2の前に解決する必要があります。
検証
- サイズティアが明示され、作業と一致していること
- ゲート1（計画）とゲート2（コミット）の両方が尊重されたこと
security-reviewerがセキュリティトリガーに触れた場合にのみ実行されたこと- コミットがconventionalであり、1つの論理変更にスコープされていること
- 新規/変更された動作にテストがあり、
rules/common/testing.mdに従いカバレッジ ≥ 80% であること