SKILL.md

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 ?"

"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:

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` 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	`-test` (TDD) then `-build` (fix) then `-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)

Restate the workflow in one sentence.

Pick the best 1-2 families; say WHY in one line each.

Run-order block — exact command sequence for the matched family.

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.

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.

ecc-recipes