The werkstoff plugin READMEs index their example prompts by plugin — useful once you already know which plugin you need. This catalog is the other door: the same capability surface, indexed by development task.
Each card below is one recipe: a task, the beats that fire in order, why each beat earns its position rather than sliding earlier or later, and the literal prompt that triggers it. Filter by category — before any code, CI & release, defect work, changes to existing code, plugin authoring, quality & verification, or surface work — or by whether a recipe pairs werkstoff with Superpowers, with an official Anthropic plugin, or uses werkstoff alone.
A recipe with an empty external filter is werkstoff-only. One tagged superpowers combines a werkstoff beat with a Superpowers skill in the same task. One tagged claude-plugins-official reaches into one or more of the official plugins — pr-review-toolkit, code-modernization, frontend-design, plugin-dev, feature-dev, hookify, claude-md-management, and project-artifact all appear across the catalog.
Three recipes are marked "no werkstoff fit" in their body text — honest gaps where Superpowers alone is the better answer, not a forced pairing.
Indexed by task, not by pairing. For the pairing-indexed view — pick two skills, see whether combining them is grounded in anything real — see orchestration/references/pairings.md.
37 of 37 recipes
A fixed chain of declared-position beats -- cut the portfolio, check longevity, name the integration seam, then stress-test the decision -- each one only valid once its predecessor has already run.
Before any code· 5 beats
Produce a citation-bearing study of how something works, marking every claim [V]erified or [P]rovisional, before anyone touches it.
Before any code· 4 beats
Load the production-grade doctrine before generating a scaffold, since a scaffold that violates it is cheaper to regenerate than retrofit.
Before any code· 4 beats
Pin down a fuzzy request into a written plan before any work starts, so later decisions don't inherit the ambiguity.
Before any code· 4 beats
Two independently-authored extractors emitting the same Given/When/Then shape, so disagreement between them is signal rather than noise.
Before any code· 5 beats
Test a brief's load-bearing claims — where something lives, what a job does — before opening a single file to edit.
Before any code· 3 beats
Separate 'does this package exist' from 'is this reference pinned tightly enough to be reproducible' before trusting either.
CI & release· 3 beats
Compare two execution surfaces claiming to run 'the same checks' before trusting that both being green means they agree.
CI & release· 3 beats
Tell apart one cause with many symptoms from several unrelated causes before debugging any single red job.
CI & release· 3 beats
How to integrate -- merge, rebase, or PR -- is a decision with a real wrong answer in this repo, not a formality to skip once the tests are green.
CI & release· 4 beats
Hunt the silent success — a green exit code whose supposed effect never actually happened.
CI & release· 3 beats
Rehearse an unexercised release path in a disposable worktree, since no wire-proving skill has evidence to route yet.
CI & release· 4 beats
Treat error messages as a first-class surface and check they aren't the visible half of a suppressed failure.
Defect work· 3 beats
Re-prove a supposedly-fixed bug from scratch, blind to the prior verdict, rather than trusting it was ever really fixed.
Defect work· 3 beats
Mutate the source and check whether the suite would actually notice, instead of trusting a green run.
Defect work· 3 beats
Find where a reported behavior lives, reach root cause, write a failing test, then prove the fix adversarially.
Defect work· 4 beats
Work root cause fast but not skipped, fan out hypotheses in parallel, and refuse to close on a proxy signal.
Defect work· 3 beats
Explore before designing, design before building, and stay skeptical of the design once it exists — the ordering that keeps the most common development task from becoming ad hoc.
Change existing code· 5 beats
Enumerate every copy exhaustively before deleting any of them — N-1 of N collapsed copies is worse than none.
Change existing code· 4 beats
Genuine independence, derived from the dependency graph rather than assumed, decides what can run in parallel -- and every dispatch, mechanical or architectural, carries an explicit model tier.
Change existing code· 5 beats
Judge the new type's design and find every call site before rolling out a changed return shape.
Change existing code· 4 beats
Identify the breaking changes that actually bite this codebase, then apply mechanical modernization fixes one cluster at a time.
Change existing code· 4 beats
Enumerate every copy, fan updates out in parallel, then prove the tree and lock agree afterwards.
Change existing code· 3 beats
Measure where the debt actually is and map real dependencies before pinning behavior and refactoring.
Change existing code· 5 beats
The after-the-fact half of authoring: a fixed-category reliability sweep, a read-only confirmation pass, and a check against the canonical tools/description spec — never widening a grant to fix a finding about that same grant.
Plugin authoring· 4 beats
The frontmatter spec, the loop shape, and a triggering-effectiveness review — in that order, because a skill that never fires reports no error and only a dedicated review catches it.
Plugin authoring· 5 beats
Documented rules and undocumented-but-real patterns are audited by different plugins on purpose -- blurring that line double-reports the same finding.
Quality & verification· 5 beats
Confirm a documented rule is actually being violated before authoring a fast, local, personal guard against it -- not the plugin-wide, code-reviewed hook a shipped enforcement policy needs.
Quality & verification· 2 beats
Ground expected numeric values in an external source, since the code and the test can agree from the same misunderstanding.
Quality & verification· 3 beats
Take review feedback on its own terms without defending, then confirm the loop actually closed, not just that something changed nearby.
Quality & verification· 3 beats
Move a rule from prose that only suggests to a PreToolUse hook that actually blocks, once divergence from it is measured.
Quality & verification· 3 beats
Anchoring an ambiguous output shape to concrete examples, then scoring competing phrasings against real test cases -- prompt tuning with evidence, not just a rewrite by feel.
Quality & verification· 4 beats
Dispatch reviewers that never saw the build session, since a session that built something is the worst judge of it.
Quality & verification· 6 beats
Convene the design council before any code, build against the settled design, then audit the built surface statically.
Surface· 3 beats
Verify CLAUDE.md's existing claims against the code before grading its coverage and drafting additions — extending a file that's already lying about the codebase compounds the drift.
Surface· 2 beats
Grade a portfolio of repos worst-signal-wins first, then hand the verdicts to a page that stays current on re-runs instead of republishing a wall of unshareable local HTML each time.
Surface· 2 beats
Sweep every documentation claim for drift immediately after a change, while the diff that caused it is still legible.
Surface· 3 beats
Each recipe's frontmatter names a task, a category, and a one-line summary, then lists its beats in order — each an ordered moment where a skill or agent earns its place, given as skill, why (what is lost if the beat slides to a different position), and an optional literal prompt that fires it. A closing grounding field gives a worked example drawn from this repository.
None of that is hand-laid-out prose: <RecipeHeader /> renders the page's h1 and summary from task and summary, and <RecipeBeats /> renders the numbered Beats list (and the Worked example) from beats and grounding, all read straight out of that page's own frontmatter. tools/catalog-validator/validate_catalog.py fails CI if a recipe body is missing either component.
Three conventions hold throughout the catalog.
Leaves only. Beats name leaf skills and dispatchable agents. Orchestrators — andon:andon-loop, self-assess:self-assess-autopilot, compass:compass-solve, cupertino:cupertino-review, confab:confab-cycle, the /consistency-* command chain, code-modernization's eight-stage pipeline — each own a whole task and must never be wedged in as a step inside another workflow. Choosing between them is a routing question; see routing.md.
Declared position is binding. A skill whose own frontmatter says "before any code" does not get retrofitted afterwards. cupertino:cupertino-council states it directly: "Always run before code, never after — retrofitting the council onto finished code defeats the purpose." compass:compass-clarify-scope declares itself for use "before any work begins". codebase-consistency is the mirror case: genuinely post-hoc, and wrong as a preamble.
Honest gaps. Three recipes are marked No werkstoff fit. Those tasks are better served by Superpowers alone, and saying so is more useful than a forced pairing.
takt never appears in a recipe's beats: list — it ships no skills, only a PreToolUse hook (plugins/takt/hooks/hooks.json) that denies an edit or a dispatch running ahead of a beat the repository declared it depends on, and stays inert until .claude/takt.local.md exists. It has nothing to contribute as a step because it isn't one; it's the mechanism that turns "these beats fire in this order" from documentation this catalog states into a constraint the runtime actually enforces.
Where a recipe dispatches several agents at once, the model tiering rule applies — see "How many plugins" below for the full guidance and the verbatim rule it's drawn from.
The count follows the shape of the task, not the ambition of the prompt.
| Task shape | Plugins | Rationale |
|---|---|---|
| One clear feature | 2-3 | One before-code beat, one build beat, one gate. More beats than that spend attention on coordination rather than on the feature |
| A larger task | 4-5 | Enough for a scope beat, a mapping beat, a build beat, and two distinct gates that fail for different reasons |
| Genuinely parallel work | Split into independent workstreams | Each workstream carries its own 2-3 plugins |
For the parallel case, one condition is not optional: the workstreams must not depend on each other. A workstream that waits on another's output is a sequential step wearing a parallel label, and dispatching it in parallel produces a partial result that reads as a complete one. Split on genuine independence — core implementation, tests and validation, docs and rollout notes — or do not split at all.
Two mechanical rules govern the dispatch itself. From superpowers:dispatching-parallel-agents: "Multiple dispatch calls in one response = parallel execution. One per response = sequential." And from superpowers:subagent-driven-development: "Always specify the model explicitly when dispatching a subagent. An omitted model inherits your session's model — often the most capable and most expensive — which silently defeats this section." Mechanical fan-out takes the cheap tier, integration and judgment the standard tier, architecture and the final whole-branch review the most capable tier, and any fix round that has already failed three times moves at least one tier up.
Choosing which orchestrator owns a whole task — rather than which leaves fill a beat inside one — is a separate question; see routing.md.
