ECCレシピ は何をしますか？
「どのECCスラッシュコマンドグループが自分のワークフローを実行するのか、どの順序で、いつ停止するのか」のための単一エントリポイント。また、すべてのコマンドグループレシピファミリーをブラウズします。
既存の2つのスキル間のギャップを埋めます：
ecc-guide— コマンドとドキュメントの場所を一覧表示しますが、フラットなカタログとして表示します。prompt-optimizer— タスクをコンポーネントにマッチングしますが、単一のプロンプトを出力するだけで、実行順序と停止条件を持つマルチコマンドグループは出力しません。
このスキルが追加するもの：ファミリーグループ化 + 実行順序 + 停止条件。
アクティブにするタイミング
- 「<ワークフロー>にはどのコマンドグループを実行すればいいですか？」
- 「MVPを構築する/欠陥を修正する/リファクタリングするためのコマンドシーケンスは？」
- 「すべてのECCコマンドグループレシピを表示して」（カタログモード）
- 「ECCにはいくつのワークフローパイプラインがありますか？」
- ユーザーが説明の有無にかかわらず
/ecc-recipesを呼び出す。
使用すべきでない場合
- ユーザーがタスクを今すぐ実行したい場合 — 説明せずに実際のコマンドにルーティングしてください。
- ユーザーが1つのコマンドの詳細なドキュメントを必要としている場合 —
ecc-guideを使用してください。 - ユーザーが下書きプロンプトの書き換えを希望する場合 —
prompt-optimizerを使用してください。
基本原則
現在のファイルから回答し、記憶から回答しないこと。 コマンドセットは変化します。カウントやメンバーリストを決してハードコードしないでください。毎回ライブのcommands/ディレクトリを読み取り、ファミリーに分類してください。
ライブ読み取り
コマンドディレクトリを解決し（最初に存在するもの）、名前を一覧表示します：
for D in \
"$HOME"/.claude/plugins/marketplaces/ecc/commands \
"$HOME"/.claude/plugins/cache/ecc/ecc/*/commands \
./commands \
./.claude/commands \
"$HOME"/.claude/commands; do
[ -d "$D" ] && CMD_DIR="$D" && break
done
[ -z "${CMD_DIR:-}" ] && { echo "ECCコマンドディレクトリが見つかりません。"; return 1; }
find "$CMD_DIR" -maxdepth 1 -name '*.md' -exec basename {} .md \; | sort
必要に応じて、manifests/install-*.jsonが存在する場合は読み取り、よりリッチなグループ化に使用します。最小限の読み取りセットを使用してください。
ファミリー分類（プレフィックスによる）
コマンド名を先頭プレフィックスでグループ化します。既知のシングルトンは手動でマッピングします。ファミリーはライブで導出されます — 以下のテーブルは分類ルールであり、固定リストではありません。
| ファミリープレフィックス | レシピの意味 | 典型的な実行順序 |
|---|---|---|
orch-* | タスクタイプごとのゲート付きResearch、Plan、TDD、Review、Commit | タスクの種類に応じて1つのorch-*を選択。内部フェーズを実行。 |
multi-* | マルチモデルワークフロー | multi-plan 次に multi-execute 次にレビュー（またはエンドツーエンドでmulti-workflow） |
prp-* | PRDから計画、実装、PRへのパイプライン | prp-prd 次に prp-plan 次に prp-implement 次に prp-commit 次に prp-pr |
epic-* | 大規模マルチユニットエピック、並列 | epic-decompose 次に epic-claim 次に epic-validate 次に epic-review 次に epic-unblock 次に epic-sync 次に epic-publish |
loop-* | 管理された自律ループとモニター | loop-start <pattern> 次に loop-statusで監視 |
gan-* | ジェネレーターと評価者のループ | gan-build（コード）または gan-design（UI）。自己ループ。 |
*-build / *-review / *-test | 言語別CIトライアド | <lang>-test（TDD）次に <lang>-build（修正）次に <lang>-review |
hookify-* | 動作フック管理 | hookify 次に hookify-list 次に hookify-configure |
learn / instinct-* / evolve / promote / prune | 継続的学習 | learn 次に instinct-status 次に evolve 次に promote |
| シングルトン | santa-loop, plan, plan-prd, pr, code-review, checkpoint など | スタンドアロン、またはグループ間の接着剤 |
プレフィックスルールに一致しないコマンドは、1行説明とともにシングルトンの下にリストします。
仕組み
1. CMD_DIRからコマンド名をライブ読み取り。
2. プレフィックスとシングルトンマップによりファミリーに分類。
3. ワークフローの説明が与えられた場合 -> マッチモード。
説明がない場合 -> カタログモード。
4. アドバイスのみ：計画を出力。マッチしたコマンドを実行しない。
カタログモード（説明なし）
ファミリーテーブルを出力：各ファミリー、メンバー数、メンバー、1行の意味、典型的な実行順序。最後に総コマンド数と、マッチしたレシピのためにワークフローを説明するように促します。
マッチモード（説明あり）
- ワークフローを1文で言い換えます。
- 最適な1〜2のファミリーを選択し、それぞれの理由を1行で説明します。
- 実行順序ブロック — マッチしたファミリーの正確なコマンドシーケンス。
- 停止条件 — 常に明示します（最大実行回数、完了シグナル、レビュー合格、または単一ショット）。自律ループの場合は、サブスクリプション消費について警告し、バックストップ制限を推奨します。
- ドキュメントの場所 —
commands/<name>.mdパスと/ecc-guide <name>。
出力テンプレート（マッチモード）
ワークフロー: <1文での言い換え>
最適なファミリー: <ファミリー> — <理由>
（代替: <ファミリー> — <理由>）
実行順序:
/<cmd1> # ジョブ
/<cmd2> # ジョブ
/<cmd3> # ジョブ
停止条件: <条件>
警告（自律ループのみ）: 無制限ループはサブスクリプション/クレジットを消費します —
完了シグナルとともに、最大反復回数または最大コストのバックストップを追加してください。
詳細ドキュメント:
commands/<cmd1>.md （または: /ecc-guide <cmd1>）
例
カタログ: /ecc-recipes → ファミリーテーブルと総数を出力。
マッチ: /ecc-recipes アプリ全体を事前に計画し、敵対的レビューによる自動ビルドを実行する → 最適なファミリー: loop-*（自律）でgan-*またはsanta-loop（敵対的）をラップ。実行順序: plan-prd 次に loop-start rfc-dag --mode safe 次に loop-statusで監視。停止条件: すべてのユニットがN回連続でレビューに合格したとき（消費制限のために最大反復回数のバックストップを追加）。
マッチ: /ecc-recipes Goサービスのバグを修正する → 最適なファミリー: orch-fix-defect（再現、修正、レビュー、コミット）。代替: go-test 次に go-build 次に go-review。停止条件: 回帰テストがグリーンでレビュー合格。
非目標
- 実行エンジンではない — アドバイスのみ。
- コマンドごとの詳細ドキュメントではない — それは
ecc-guide。 - プロンプトの書き換えではない — それは
prompt-optimizer。 - コマンド数やメンバーリストを決してハードコードしない — 常にライブ読み取り。