Pairings: which two skills combine, and why

The prompt catalog is indexed by what you're trying to do -- pick a task, get an ordered sequence of beats. This page is the other axis: pick two skills, find out whether combining them is grounded in anything real, and if so, what the combination actually buys.

Every card below pairs one werkstoff skill with one skill or agent from superpowers or one of the official Anthropic plugins (pr-review-toolkit, code-modernization, feature-dev, frontend-design, plugin-dev). Read orchestration/README.md first if you haven't -- it explains the three roles (werkstoff as specialised inspector, superpowers as process discipline, the official set as named reviewer agents) and the four beats these cards are grouped by.

20 of 20 pairings

superpowers:brainstormingcli-scaffold:cli-architecture

Inspect and researchsuperpowers

A CLI scaffolded from an unexamined idea encodes the idea's flaws structurally, and a scaffold that violates the doctrine is cheaper to regenerate than to retrofit -- so both gates have to close before any generator runs.

How

brainstorming runs first, before any code exists, to work out what the CLI should actually do. cli-architecture then loads next on its own instruction -- "BEFORE any paradigm skill (cli-scaffold-compiled, cli-scaffold-interpreted, cli-scaffold-shell) generates a scaffold" -- so the language-specific paradigm skill never runs until both gates have closed.

Example prompt

I want to build a small CLI for this. Let's brainstorm what it should do before any code exists.

Load cli-architecture before the paradigm skill runs, every time -- it states this about itself.
Treat paradigm choice (compiled/interpreted/shell) as fixed by language once picked.

Don't swap paradigm after generation -- it "cannot be swapped later without regenerating."
Don't let the paradigm skill run first and retrofit the doctrine onto an existing scaffold.

code-modernization:business-rules-extractorbefund:befund-extract-rules

Inspect and researchclaude-plugins-official

Two independently-authored extractors emitting the same Given/When/Then shape make disagreement between them signal, not noise -- a single extractor's output is not something you can cross-check against itself.

How

befund-extract-rules mines rules from the executable code first, loops to convergence, and requires one scored contract judge (rubric befund-p0-rule@1) to pass for any P0 rule. code-modernization:business-rules-extractor runs second, as an independent second read with the same output shape -- run after the first extractor so it's a cross-check, not an anchor.

Example prompt

extract this codebase's real business rules as Given/When/Then specs, from the executable code, not from comments or docs

Run the second extractor after the first, specifically so it can disagree with it, not repeat it.
Feed business-rules-extractor's output to BUSINESS_RULES.md only when /modernize-brief is the pipeline actually being signed.

Don't run both over the same modules expecting them to reconcile -- routing.md is explicit: running both produces two rule sets that will not be reconciled by anything. Choose by which brief, if any, is going to be signed.
Don't treat the second pass as a rerun of the first -- it feeds a different consumer (a repo's own understanding of itself, not BUSINESS_RULES.md).

code-modernization:version-delta-analystbefund:befund-code-idiom

Inspect and researchclaude-plugins-official

A same-stack uplift preserves code and tweaks it; version-delta-analyst finds which breaking changes actually bite this codebase, and befund-code-idiom then judges the result against the version the repo actually targets -- not the newest one.

How

version-delta-analyst is dispatched directly, standalone, sanctioned by modernize-brief.md itself rather than through the eight-stage pipeline: when the delta catalog is missing, spawn the version-delta-analyst agent directly, then return -- do not guess at the deltas. befund-code-idiom then runs against the manifest-declared version, and befund-idiom-fix applies only the mechanical fixes afterward.

Example prompt

we're moving this codebase up a major version of the same stack. Which breaking changes actually affect our code?

Dispatch version-delta-analyst as a standalone leaf when you only need the deltas, not the whole /modernize-uplift pipeline.
Judge idioms against the version the manifest already declares -- not the newest available version.

Don't reach for befund-code-idiom to plan the uplift itself -- routing.md: it judges idioms against the language version the repo's manifest already declares, so it cannot plan a move to a version the manifest has not reached.
Don't run the idiom audit before the uplift -- running the auditor before the uplift measures the old world, not the new one.

zirkel:zirkel-investigate-dynamicallysuperpowers:systematic-debugging

Inspect and researchsuperpowers

The reported behavior's location is unknown, and a pre-planned file list cannot adapt to what each observation reveals -- so the search has to run before the debugging discipline that assumes a location already.

How

zirkel-investigate-dynamically finds where the behavior actually lives first. superpowers:systematic-debugging then works the located behavior to root cause, mandatory before any fix is proposed.

Example prompt

I don't know where this behavior is implemented -- go find it before we talk about fixing it

Let the search adapt to each observation rather than following a plan written before any file was opened.
Work to root cause before proposing any fix -- no fix, no patch, no workaround until the cause is proven.

Don't propose a fix before the cause is nailed down -- a fix without a cause is a guess with a diff.
Don't reuse a pre-planned file list once the first observation contradicts it.

zirkel:zirkel-negotiate-tradeoffssuperpowers:writing-plans

Split into workstreamssuperpowers

A scope that never becomes a written plan is re-litigated at every subsequent step, and a hybrid approach negotiated between branches is only checkable while both source branches are still scored and live.

How

zirkel-explore-branches scores genuinely distinct readings of the request, zirkel-negotiate-tradeoffs settles any fork those branches can't resolve on their own, and superpowers:writing-plans turns the settled scope into a written plan with steps before anyone touches code.

Example prompt

we've agreed the scope -- turn it into a written plan with steps before touching code

Settle the tradeoff while both branches are still live and scored, not after one has already been picked.
Turn the settled scope into a written plan immediately -- before implementation starts.

Don't let an ambiguous scope go straight to a plan without scoring alternatives first -- scoring alternatives after one has been built anchors on the built one.
Don't leave a settled scope unwritten -- it gets re-litigated at every later step.

zirkel:zirkel-decompose-chainsuperpowers:systematic-debugging

Split into workstreamssuperpowers

Several jobs red at once can mean one cause with many symptoms, or several independent causes -- chasing symptoms before telling those two cases apart wastes the whole first pass.

How

befund-ci-topology audits the CI config itself first, since a config-level defect explains all the symptoms at once. zirkel-decompose-chain then derives which of the red jobs are genuinely independent tracks from the dependency graph, not by guess, before superpowers:systematic-debugging works any single failure to root cause.

Example prompt

work the lint failure to root cause first -- no fixes proposed until the cause is nailed down

Derive independent tracks from the actual dependency graph before splitting the work, not from how the jobs happen to be laid out.
Work each track to root cause before proposing any fix.

Don't debug the first red job you see without first checking whether a single config-level cause explains all of them.
Don't propose a fix ahead of a root cause -- a fix proposed ahead of a root cause is a second failure mode.

superpowers:dispatching-parallel-agentsandon:andon-verify

Execute in parallelsuperpowers

What can run in parallel has to come from the dependency graph, not from how the plan happens to be laid out, and a partial parallel result reads exactly like a complete one until something checks each wire on its own.

How

zirkel-decompose-chain derives which workstreams are genuinely independent. superpowers:dispatching-parallel-agents and subagent-driven-development then execute them -- multiple dispatch calls in one response is parallel execution, one per response is sequential -- and andon:andon-verify proves each workstream on its own rather than the aggregate result inheriting one shared verdict.

Example prompt

break this plan into independent workstreams -- tell me what actually depends on what and what can truly run in parallel

Send every parallel dispatch in the SAME response -- one call per response runs sequentially regardless of intent.
Choose the model tier per dispatch where the cost matters -- an omitted model inherits the session's, possibly most expensive, tier by design.
Give each workstream its own andon-verify proof.

Don't split work that shares state -- two agents editing the same file interfere regardless of how cleanly the split looked on paper.
Don't let a workstream that waits on another's output masquerade as parallel -- it's a sequential step wearing a parallel label.

cupertino:cupertino-councilfrontend-design:frontend-design

Execute in parallelclaude-plugins-official

Design work has a hard ordering constraint most tasks don't: the principled pass must precede the code.

cupertino-council's own frontmatter states it directly -- "Always run before code, never after -- retrofitting the council onto finished code defeats the purpose."

How

cupertino-council convenes its five-voice design review before a single line of markup exists. frontend-design then implements the design that was settled -- after the principles are settled, not in place of settling them.

Example prompt

design this screen from first principles before we write any markup -- I don't want something that just looks like every other AI-built page

Run cupertino-council before any markup exists, every time -- it's a pre-code gate by its own declaration.
Hand frontend-design the settled design, not an open brief -- implementation follows the principles, it doesn't set them.

Don't retrofit the council onto a finished screen -- "retrofitting the council onto finished code defeats the purpose" is the plugin's own stated rule.
Don't skip straight to frontend-design on an interface that hasn't had a principled pass yet.

frontend-design:frontend-designbefund:befund-ui-audit

Verifyclaude-plugins-official

Accessibility, semantic markup, and hardcoded design values are only checkable once the markup actually exists -- running the audit before the build produces nothing to audit.

How

frontend-design implements the settled design first. befund-ui-audit then statically audits the built surface -- JSX/TSX, Vue/Svelte, HTML, CSS/SCSS -- for accessibility and hardcoded values, without ever running the app.

Example prompt

audit the UI we just built for accessibility, semantic markup, and hardcoded design values -- statically, don't run the app

Run the audit only after real markup exists -- it's genuinely post-hoc.
Keep the audit static -- read source, never execute or render the app.

Don't run befund-ui-audit against a design that's still principles-only -- there's no markup yet to check.
Don't substitute a live-app check for the static read; the skill's own scope is explicitly static-only.

pr-review-toolkit:code-simplifierpassung:pattern-extractor

Verifyclaude-plugins-official

Documented rules and undocumented-but-real patterns are audited by different plugins on purpose, and simplifying before the convention is settled means simplifying twice.

How

befund audits the documented half first (befund-lint-audit, then convention-auditor). passung:pattern-extractor then handles the undocumented half, refusing to force a pick when competing variants are genuinely tied, and consistency-critic re-derives the verdict as a second judge. pr-review-toolkit:code-simplifier runs last, deliberately, on the now-aligned code only.

Example prompt

extract the discrete, checkable rules this repo's own documentation states, and audit the code against them

Run code-simplifier last, after both the documented and undocumented halves have settled -- not before.
Let consistency-critic re-derive pattern-extractor's verdict rather than rubber-stamping it.

Don't simplify before the convention is canonized -- the code you'd simplify may get rewritten to the canonical form immediately after.
Don't blur the documented/undocumented boundary -- passung's own README routes documented conventions out to befund by name; running both for the same finding double-reports it.

plugin-dev:hook-developmentcupertino:cupertino-handbook-check

Verifyclaude-plugins-official

A rule that lives only in prose is a suggestion.

This repo measured the difference: prose in a SKILL.md is baseline, a fenced python3 guard fires one run in three, a Workflow-script guard fires one run in fourteen, and a PreToolUse hook of type "command" blocks on the first attempt.

How

cupertino-handbook-draft turns the convention into one concrete, file:line-grounded rule. cupertino-handbook-check then runs that rule against real files to find every divergence before any enforcement is written -- enforcement written before the divergence is known will either block everything or nothing. plugin-dev:hook-development then writes the PreToolUse hook, since prose alone won't hold.

Example prompt

prose isn't holding this. Write a PreToolUse hook that blocks it on the first attempt.

Measure divergence with cupertino-handbook-check before writing the hook -- enforcing an unmeasured rule blocks everything or nothing.
Use type: "command" for the hook -- a "prompt" hook asks a model to decide, which is exactly the unreliable rung this pairing exists to skip past.
Make the deny emit both exit 2 with the reason on stderr AND stdout JSON carrying hookEventName and permissionDecisionReason.
Fail closed, with a named escape hatch.

Don't write the hook before the check step has run -- you'd be enforcing a rule against divergence you haven't measured.
Don't settle for a "prompt"-type hook and call it enforcement; only type: "command" measured as reliably blocking on this repo's own runs.

pr-review-toolkit:type-design-analyzerzeugnis:zeugnis-contract-drift

Verifyclaude-plugins-official

Changing what a function hands back is a contract change wearing a refactor's clothes -- every call site is a participant, and type hints, signatures, docstring params, and schemas drift apart precisely during a migration like this.

How

type-design-analyzer reviews the new type's design -- encapsulation, invariants, enforceability -- before N call sites adopt the shape, since that's cheapest to fix early. zeugnis-contract-drift then checks, after the migration, whether the declared signatures still agree with how the code is actually called.

Example prompt

before we roll this new return type out everywhere, review its design -- encapsulation, invariants, whether it's actually enforceable

Review the type's design before rollout, not after -- it's cheapest before N call sites depend on the shape.
Dispatch both together when a diff touches types or signatures -- gates.md's own routing table pairs them for exactly that touch-category.

Don't treat a passing test suite as evidence of equivalence on its own -- a passing suite is evidence only if the suite would notice.
Don't skip the contract-drift check just because the type review passed -- one rates design quality, the other checks whether call sites actually agree with it.

pr-review-toolkit:silent-failure-hunterandon:andon-verify

Verifyclaude-plugins-official

The most expensive CI defect is the green one -- a job exits zero and the work it was supposed to do never happened.

A green exit code is not evidence; the wire it claims to close has to be proven independently.

How

silent-failure-hunter hunts the job for swallowed errors, skipped branches, and fallbacks that hide the real outcome. andon-verify then proves the specific wire the job claims -- "job ran -> artifact changed" -- rather than accepting the exit code as evidence.

Example prompt

this job exits zero but nothing downstream changed -- go hunt for swallowed errors, skipped branches, and fallbacks that hide the real outcome

Hunt the suppression first -- silent-failure-hunter is purpose-built for exactly this shape.
State the wire's contract explicitly when dispatching andon-verify -- it routes among seven strategies by reading the wire's contract, and a dispatch with no stated contract has nothing to route against.

Don't accept a green exit code as proof the job did what it claims.
Don't dispatch andon-verify with only a diff and no stated contract -- unlike the other reviewers in this catalog, it won't infer one.

zeugnis:zeugnis-mutation-hardenpr-review-toolkit:pr-test-analyzer

Verifyclaude-plugins-official

A real mutation tool says which changes the suite lets through, but only for the code it mutated and the tests it selected; a diff review sees behaviour the shard never reached.

Each catches what the other is structurally blind to.

How

zeugnis-mutation-harden runs mutmut on a fresh archive copy of one module, writes the tests that kill the survivors, and proves each kill by applying its mutant. pr-test-analyzer then reviews the resulting test diff for behavioural gaps outside that module -- run it second, so it reviews tests that already assert real values.

Example prompt

run mutmut on src/shop/pricing.py and write the tests that kill what survives

Read the untested-mutant count beside the score -- a shard of mostly untested code can show a high score.
Read every equivalent mutant's one-line reason yourself; it is the one model judgement in the run and never counts as a kill.

Don't count a kill that has no proof, or one the re-measure contradicts -- the report lists those as rejected claims.
Don't put integration tests in a mutation shard -- every mutant reruns every selected test that covers it.

zeugnis:zeugnis-assertion-auditpr-review-toolkit:pr-test-analyzer

Verifyclaude-plugins-official

A green suite proves the tests ran, not that they would notice -- coverage percentages are compatible with assertions that assert nothing.

How

zeugnis-assertion-audit proposes plausible mutations (off-by-one, boundary flip, condition negation) to the target source and checks whether any existing test would catch them. pr-test-analyzer reviews the same tests for behavioral coverage gaps, not line-coverage percentage -- the two angles catch different shapes of the same failure.

Example prompt

mutate this module -- flip a boundary, negate a condition, shift an index -- and tell me which mutations the tests would not catch

Run both -- mutation testing and behavioral-coverage review catch different shapes of a test suite that passes for the wrong reason.
Watch for an assertion whose expected value brackets a hardcoded default, so the test passes whether or not the real logic ever executes.

Don't trust a green run, or a high coverage percentage, as evidence the suite would notice a real regression.
Don't stop at line coverage -- pr-test-analyzer is explicitly scoped to behavioral coverage instead.

befund:befund-docs-driftclaude-md-management:claude-md-improver

Inspect and researchclaude-plugins-official

claude-md-improver's own "Currency" criterion grades a CLAUDE.md's freshness on a letter scale, not claim by claim -- extending a file whose existing claims are already wrong compounds the drift instead of fixing it.

How

befund-docs-drift reads CLAUDE.md by name among its four source files and verifies every falsifiable claim against the cited code by static comparison first. claude-md-improver then grades coverage, architecture clarity, and conciseness and proposes targeted diffs -- against a file whose claims are now known-accurate, not merely plausible.

Example prompt

check whether CLAUDE.md's claims still match the code before you touch anything in it -- then grade its quality and propose targeted additions

Run the drift check first, every time -- it's the only citation-by-citation verification either skill does.
Treat every claim the drift check confirms as stale as something to fix, not just extend around.

Don't let claude-md-improver's Phase 2 currency score stand in for a real per-claim check -- it's a graded eyeball pass, not static verification.
Don't skip straight to drafting additions on a CLAUDE.md nobody has fact-checked recently.

befund:befund-lint-audithookify:hookify

Verifyclaude-plugins-official

befund-lint-audit is explicitly read-only and never auto-fixes a violation it confirms, which leaves nothing standing guard against the next repeat -- and a plugin-wide, code-reviewed hook is the wrong weight class for one contributor's own habit.

How

befund-lint-audit extracts discrete rules from CLAUDE.md (this repo has no house-rules.md, so every rule is labeled "CLAUDE.md (best-effort)") and dispatches convention-auditor to confirm real violations against the actual code. hookify then turns one confirmed, repeatedly-broken rule into a live `.claude/hookify.<name>.local.md` guard, active on the next tool use with no restart.

Example prompt

I keep forgetting the rrt-over-raw-git rule -- warn me immediately, right now, the next time I run a bare git commit or push in this repo

Confirm the violation with befund-lint-audit's Find+Verify before authoring a guard -- hookify's own rule format has no way to check whether a pattern match is a real violation, only to react once one's typed.
Scope the guard personally and locally (.claude/*.local.md, gitignored) -- it's for one contributor's habit, not a policy the whole plugin ships with.

Don't treat a hookify rule as equivalent-strength to a shipped PreToolUse hook -- hookify's own pretooluse.py fails OPEN on any exception ("allow operation and log error"), the opposite of this repo's fail-closed doctrine.
Don't reach for hookify to enforce a rule across the whole plugin -- that's `make-strategy-enforced-not-documented`'s job (cupertino-handbook-draft/check + plugin-dev:hook-development), which produces a shipped, fail-closed hook, not a personal local one.

befund:befund-portfolioproject-artifact:project-artifact

Verifyclaude-plugins-official

befund-portfolio's own output is deliberately narrow -- one grade per repo, worst-signal-wins, written once to a local file with no sharing and no memory of the previous sweep.

How

befund-portfolio grades every repo in an explicit portfolio directory Red/Amber/Green/Gray and writes befund-portfolio.html into that directory. project-artifact then turns those verdicts into a living claude.ai page -- status pills, an Attention tab for what's blocked, and a delta-only refresh that reads the previous render's embedded state block.

Example prompt

sweep every repo under ~/LocalDocuments/GitHub_Forks and grade each one's befund health, then publish that as a shareable status page I can send the team

Name the portfolio directory explicitly when invoking befund-portfolio -- its own gate refuses to infer cwd's parent as the portfolio.
Let project-artifact read the previous render's state block on every refresh so re-running the sweep reports a delta, not a repeated wall of rows.

Don't republish the raw befund-portfolio.html as-is -- it has no sharing, no tabs, and no delta tracking across sweeps.
Don't let a Gray verdict get smoothed into an invented grade on the status page -- Gray means "not yet assessed," nothing more.

befund:befund-docs-driftpr-review-toolkit:comment-analyzer

Verifyclaude-plugins-official

Docs drift is asymmetric -- the code moves and the prose doesn't -- and comments drift from the same edit as docs, but no docs sweep reads them.

How

befund-docs-drift verifies every extracted, in-scope claim against the current codebase, run immediately after a change while the diff is still legible. pr-review-toolkit:comment-analyzer separately checks the comments in the same touched files, since a docs sweep doesn't read those.

Example prompt

we renamed several things this week -- check whether the docs still describe what the code actually does

Run the sweep immediately after the change, while the diff that caused the drift is still legible.
Check comments and docs as two separate passes -- the same edit drifts both, but nothing reads them together.

Don't wait -- run months later, this sweep produces a backlog instead of a fix.
Don't run a convention survey (passung:pattern-analyst) until the docs are already accurate -- a survey run before the content is correct clusters variants of the wrong text.

nacharbeit:nacharbeit-fixplugin-dev:plugin-validator

Verifyclaude-plugins-official

nacharbeit's blind verifier checks that each entry was applied and runs the file's post-checks, but it reads one file at a time; the runtime's own validator is the only thing that judges the reworked plugin as a whole -- manifest, structure, every component present -- and it has to run on the tree after the pass, not on the plan before it.

How

nacharbeit-fix runs first: it opens the fix lock, applies the haiku and sonnet tiers file by file, and releases the lock only after post_fix_check.py has re-run every post-check and diffed contracts against the pre-fix snapshot. plugin-dev:plugin-validator then runs once on the released tree; a failure there is a regression the single-file verifier could not see, and goes back into a new fix pass, never into a hand edit under the lock.

Example prompt

apply the haiku and sonnet findings from the review, one file at a time, and tell me what's left for me

Validate after the lock is released, on the reworked tree -- nacharbeit's post-checks already call the same validator per file, so a whole-plugin failure here means a cross-file regression.
Read the opus- and human-tier entries the fix pass listed before validating -- a validator cannot tell a deliberate hold from an omission.

Don't validate before the pass and call it done -- the files the validator would judge have not changed yet.
Don't fix a validator failure by editing under the lock with NACHARBEIT_DISABLE_GUARD=1 -- open a new pass so the edit is verified like every other.

How to read a pairing card

Each card names two skills, the beat they occupy (Inspect and research, Split into workstreams, Execute in parallel, or Verify -- see orchestration/README.md), and five things:

Why -- the failure mode that combining them, rather than running either alone, actually closes.
How -- the sequencing: which one runs first, and what it hands the other.
Example prompt -- a real, copy-pasteable prompt, quoted unedited from the catalog recipe the pairing is drawn from.
Do / Don't -- concrete constraints pulled from the skills' own stated scope, from gates.md, routing.md, or from this repo's own CLAUDE.md -- never generic advice.
A grounding line naming the real file, defect, or repo state the pairing was checked against, and a link back to the full catalog recipe it's excerpted from.

Where this data comes from, and what didn't make it

Nothing here is invented. Every pairing is two adjacent (or closely linked) beats from an existing catalog recipe, or one of the three pairings orchestration/README.md's "Worked examples" section already quotes in full. A plausible-sounding combination with no recipe behind it -- no real why, no real prompt, no real grounding -- is not on this page. Extending this list means writing a new catalog recipe with real beats and a real prompt first; a card here without one behind it would be exactly the kind of plausible-but-false content zeugnis exists to catch.

Three recipes in the catalog are marked "No werkstoff fit" -- pure Superpowers tasks with no werkstoff skill to pair against. They don't appear here for the same reason: there is no pairing to show, and a forced one would be worse than none.

Measured examples

arbeitsplan

lehre

nacharbeit

spur

Pairings: which two skills combine, and why

How to read a pairing card

Where this data comes from, and what didn't make it

Pairings: which two skills combine, and why ​

How to read a pairing card ​

Where this data comes from, and what didn't make it ​

Pairings: which two skills combine, and why

How to read a pairing card

Where this data comes from, and what didn't make it