---
name: ecc-recipes
description: Maps a described workflow to the right ECC command-group with run-order and stop condition, and browses all command-group recipe families.
---

# ECC Recipes

One entry point for "which group of ECC slash-commands runs my workflow, in what
order, and when do I stop." Also browses every command-group recipe family.

Fills the gap between two existing skills:

- `ecc-guide` — lists commands and where to read docs, but as a flat catalog.
- `prompt-optimizer` — matches a task to components, but outputs a single prompt,
  not a multi-command group with run-order and stop condition.

This skill adds: **family grouping + run-order + stop condition.**

## When to Activate

- "Which command group do I run for <workflow>?"
- "What's the command sequence to build an MVP / fix a defect / refactor?"
- "Show me all ECC command-group recipes" (catalog mode)
- "How many workflow pipelines does ECC have?"
- User invokes `/ecc-recipes` with or without a description.

### Do Not Use When

- User wants the task done now — route to the actual command, don't describe it.
- User wants deep docs for ONE command — use `ecc-guide`.
- User wants a draft prompt rewritten — use `prompt-optimizer`.

## Core Principle

**Answer from current files, not memory.** The command set changes; never
hardcode counts or member lists. Read the live `commands/` directory each run,
then classify into families.

### Live reads

Resolve the commands directory (first that exists), then list names:

```bash
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 "No ECC commands directory found."; return 1; }
find "$CMD_DIR" -maxdepth 1 -name '*.md' -exec basename {} .md \; | sort
```

Optionally read `manifests/install-*.json` if present for richer grouping. Use
the smallest set of reads needed.

## Family Classification (by prefix)

Group command names by leading prefix; map known singletons by hand. Families are
derived live — the table below is the *classification rule*, not a frozen list.

| Family prefix | Recipe meaning | Typical run-order |
|---|---|---|
| `orch-*` | gated Research, Plan, TDD, Review, Commit per task type | pick one orch-* by task kind; it runs its own internal phases |
| `multi-*` | multi-model workflow | `multi-plan` then `multi-execute` then review (or `multi-workflow` end-to-end) |
| `prp-*` | PRD to plan to implement to PR pipeline | `prp-prd` then `prp-plan` then `prp-implement` then `prp-commit` then `prp-pr` |
| `epic-*` | large multi-unit epic, parallel | `epic-decompose` then `epic-claim` then `epic-validate` then `epic-review` then `epic-unblock` then `epic-sync` then `epic-publish` |
| `loop-*` | managed autonomous loop and monitor | `loop-start <pattern>` then watch with `loop-status` |
| `gan-*` | generator and evaluator loop | `gan-build` (code) or `gan-design` (UI); self-looping |
| `*-build` / `*-review` / `*-test` | per-language CI triad | `<lang>-test` (TDD) then `<lang>-build` (fix) then `<lang>-review` |
| `hookify-*` | behavior-hook management | `hookify` then `hookify-list` then `hookify-configure` |
| `learn` / `instinct-*` / `evolve` / `promote` / `prune` | continuous-learning | `learn` then `instinct-status` then `evolve` then `promote` |
| singletons | `santa-loop`, `plan`, `plan-prd`, `pr`, `code-review`, `checkpoint`, etc. | standalone or glue between groups |

Any command not matching a prefix rule → list it under **singletons** with its
one-line description.

## How It Works

```
1. Live-read command names from CMD_DIR.
2. Classify into families by prefix and a singleton map.
3. If a workflow description was given -> MATCH MODE.
   If none -> CATALOG MODE.
4. Advisory only: print the plan. Never run the matched commands.
```

### Catalog mode (no description)

Output the family table: each family, member count, members, one-line meaning,
typical run-order. End with the total command count and a prompt to describe a
workflow for a matched recipe.

### Match mode (description given)

1. Restate the workflow in one sentence.
2. Pick the best 1-2 families; say WHY in one line each.
3. **Run-order block** — exact command sequence for the matched family.
4. **Stop condition** — always explicit (max-runs, completion-signal,
   review-passes, or single-shot). For autonomous loops, warn about subscription
   burn and recommend a backstop bound.
5. **Where to read** — the `commands/<name>.md` path plus `/ecc-guide <name>`.

## Output Template (match mode)

```
Workflow: <one-sentence restatement>

Best fit: <family> — <why>
(Alt: <family> — <why>)

Run-order:
  /<cmd1>   # job
  /<cmd2>   # job
  /<cmd3>   # job
  STOP when: <condition>
  WARNING (autonomous loops only): an unbounded loop burns subscription/credits —
  add a max-iteration or max-cost backstop alongside the completion signal.

Read full docs:
  commands/<cmd1>.md   (or: /ecc-guide <cmd1>)
```

## Examples

**Catalog:** `/ecc-recipes` → prints the family table and total count.

**Match:** `/ecc-recipes plan a whole app upfront then auto-build with adversarial
review until done` → Best fit: `loop-*` (autonomous) wrapping `gan-*` or
`santa-loop` (adversarial). Run-order: `plan-prd` then
`loop-start rfc-dag --mode safe` then monitor `loop-status`; STOP when all units
pass review N consecutive times (add a max-iteration backstop to bound burn).

**Match:** `/ecc-recipes fix a bug in my Go service` → Best fit: `orch-fix-defect`
(reproduce, fix, review, commit). Alt: `go-test` then `go-build` then
`go-review`. STOP: regression test green and review pass.

## Non-Goals

- Not an executor — advisory only.
- Not per-command deep docs — that's `ecc-guide`.
- Not prompt rewriting — that's `prompt-optimizer`.
- Never hardcode command counts or member lists — always live-read.