ECC 工作流配方 是做什么的？
“哪个 ECC 斜杠命令组能运行我的工作流，按什么顺序，以及何时停止”的统一入口。同时浏览所有命令组的配方系列。
填补了现有两个技能之间的空白：
ecc-guide—— 列出命令及其文档位置，但只是一个扁平目录。prompt-optimizer—— 将任务匹配到组件，但输出的是单条 prompt，而非包含运行顺序和停止条件的多命令组。
本技能增加：家族分组 + 运行顺序 + 停止条件。
何时激活
- “我应该运行哪个命令组来执行 <工作流>？”
- “构建 MVP / 修复缺陷 / 重构的命令序列是什么？”
- “展示所有 ECC 命令组配方”（目录模式）
- “ECC 有多少个工作流流水线？”
- 用户调用
/ecc-recipes（带或不带描述）。
不应使用的情况
- 用户希望立即执行任务 —— 应路由到实际命令，而非描述。
- 用户希望获取单个命令的详细文档 —— 使用
ecc-guide。 - 用户希望重写草稿 prompt —— 使用
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-* | 按任务类型进行门控式研究、计划、TDD、评审、提交 | 选取一个与任务类型对应的 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 三元组 | <语言>-test（TDD）然后 <语言>-build（修复）然后 <语言>-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. 从 CMD_DIR 实时读取命令名称。
2. 按前缀和单例映射归类为家族。
3. 如果提供了工作流描述 → 匹配模式。
如果未提供 → 目录模式。
4. 仅建议：打印计划。绝不运行匹配的命令。
目录模式（无描述）
输出家族表格：每个家族、成员数量、成员、一行含义、典型运行顺序。最后以命令总数和提示用户描述工作流以获取匹配配方结束。
匹配模式（有描述）
- 用一句话重述工作流。
- 选择最佳的 1-2 个家族；用一行说明原因。
- 运行顺序块 —— 匹配家族的精确命令序列。
- 停止条件 —— 始终明确（最大运行次数、完成信号、评审通过或单次执行）。对于自主循环，警告订阅消耗并建议设置一个兜底上限。
- 文档位置 ——
commands/<名称>.md路径加上/ecc-guide <名称>。
输出模板（匹配模式）
工作流：<一句话重述>
最佳匹配：<家族> —— <原因>
（备选：<家族> —— <原因>）
运行顺序：
/<命令1> # 任务
/<命令2> # 任务
/<命令3> # 任务
停止条件：<条件>
警告（仅限自主循环）：无界循环会消耗订阅/额度——
请添加一个最大迭代次数或最大成本兜底，配合完成信号。
阅读完整文档：
commands/<命令1>.md （或：/ecc-guide <命令1>）
示例
目录模式： /ecc-recipes → 打印家族表格和总数。
匹配模式： /ecc-recipes 预先计划整个应用，然后自动构建并带有对抗性评审，直到完成 → 最佳匹配：loop-*（自主）包裹 gan-* 或 santa-loop（对抗性）。运行顺序：plan-prd 然后 loop-start rfc-dag --mode safe 然后监控 loop-status；当所有单元连续 N 次通过评审时停止（添加最大迭代兜底以限制消耗）。
匹配模式： /ecc-recipes 修复我的 Go 服务中的一个 bug → 最佳匹配：orch-fix-defect（重现、修复、评审、提交）。备选：go-test 然后 go-build 然后 go-review。停止条件：回归测试通过且评审通过。
非目标
- 不是执行器 —— 仅建议。
- 不提供单命令深度文档 —— 那是
ecc-guide的职责。 - 不重写 prompt —— 那是
prompt-optimizer的职责。 - 永不硬编码命令数量或成员列表 —— 始终实时读取。