Claude Code Slash Commands: Orchestration Patterns That Actually Work (2026)

Across 101 ClaudeKit slash commands spanning five kits, the same five orchestration patterns recur in nearly every workflow: namespaced verbs, bootstrap-context-first, parallel fan-out, evidence contracts, and the diagnostic/deliverable split. Those five patterns are what turn a Claude Code slash command from a glorified prompt macro into something that behaves like an actual workflow. This post is the pattern catalog, illustrated with real orchestration steps from five different kits, so you can lift the structure into your own commands.

What are Claude Code slash commands, exactly?

A slash command in Claude Code is a named workflow — a file that sequences agents, loads skills, fans out parallel tasks, and declares the artifacts it emits. It is not a prompt. The distinction matters: a prompt tells Claude what to do once; a slash command orchestrates a repeatable series of steps, each with a clear input, output, and handoff.

ClaudeKit ships five domain kits as of June 2026:

All 13 agents are read-only specialists: reviewers, auditors, researchers. None orchestrate other agents. Commands end with an evidence artifact, not a reviewer gate. That architectural choice is explained in detail under pattern 4.

You can browse all five kits at /engineer, /marketing, /video, /seo, and /ecom.

Pattern 1: Why do namespaced verbs matter for slash command design?

The first decision a command makes is its name, and the name should encode both a domain and an action. Every ClaudeKit command follows /<kit-namespace> <verb>: /eng debug, /seo audit, /ecom flows, /mkt repurpose, /video clone. The namespace scopes the command to a kit's agents and context files; the verb names a single coherent outcome.

A flat namespace of bare verbs (/audit, /write, /plan) collides the moment you install more than one kit, and it gives Claude Code no signal about which context files and agents to bind. Namespacing also makes commands discoverable: once you know /seo, you can guess /seo write and /seo check exist.

The five v2 namespaces are /eng, /mkt, /seo, /video, and /ecom. The old v1 namespaces /marketing, /founder, and /sales are gone. FounderKit and SalesKit are shelved; we cover why in the six-months build retrospective.

The verb rule is strict: one verb, one job. If you feel tempted to write /eng review-and-fix, that is two commands. Keep them separate so each has a clean artifact contract.

Pattern 2: What is bootstrap-context-first and why does it eliminate generic output?

The single biggest quality lever in the system is that shared context is written once and read by everything. Every kit has at least one bootstrap skill that interviews you once and writes durable markdown artifacts. Those artifacts sit in your project or ~/.claude/ and every subsequent command reads them rather than re-interviewing you.

EngineerKit's bootstrap skill writes a CODEBASE.md with stack, patterns, and conventions. MarketingKit's mkt-voice skill reads 10 to 20 of your real posts, extracts 12 voice fingerprints, and writes VOICE.md. SEOKit's seo-context writes SITE.md with domain, audience, and current ranking footprint. EcomKit writes STORE.md, CATALOG.md, and CUSTOMER.md.

Every deliverable command starts by ensuring that context exists, and refuses or auto-bootstraps if it does not. Three examples:

/eng debug    → loads CODEBASE.md if present; requests stack info if missing.
/ecom flows   → confirms CUSTOMER.md segments exist before writing any copy.
/mkt humanize → reads VOICE.md before stripping AI tells from your draft.

This is what stops output from being generic. The welcome email, the ad copy, and the cart-recovery sequence all read the same STORE.md, so brand voice and SKU structure stay consistent instead of being re-explained on every prompt. Bootstrap-context-first is the difference between a kit and a pile of unrelated prompts.

Pattern 3: How does parallel fan-out speed up multi-step workflows?

The expensive, slow approach to a multi-agent workflow is sequential execution. The correct approach, when steps are independent, is to fan them out concurrently. ClaudeKit commands fan out aggressively wherever there is no data dependency.

The clearest example is /seo audit:

Parallel fan-out — up to 12 passes concurrent:
  technical-auditor, indexation-analyst, cwv-engineer,
  keyword-strategist, cluster-architect, cannibalization-analyst,
  aeo-optimizer, schema-engineer, link-strategist,
  local-intl-specialist, content-strategist, programmatic-architect.
  → audit-scorer merges and dedupes findings.

None of those specialist passes needs another's output to do its own work, so they run together. An aggregator merges the findings afterward. The same pattern appears in /ecom flows, where email copy for welcome, abandoned-cart, browse-abandon, post-purchase, and win-back flows all write in parallel.

The rule that makes fan-out safe: fan out only across independent work, then converge through a single aggregator. If step B reads step A's output, B is sequential. Get the dependency graph right and parallelism is free speed. Skip the aggregator and you get incoherent, contradictory artifacts.

Fan-out vs. sequential: when to use each

1. Use fan-out when each agent works from the same shared context and produces an independent artifact.
2. Use sequential when a later step consumes the output of an earlier step.
3. Always converge through a single aggregator before scoring or emitting final output.
4. Cap parallel agents at what your model's context window can coherently handle. Beyond roughly 12 concurrent specialists, you start losing coherence on the merge.
5. Name your aggregator explicitly in the command definition so it is obvious which agent owns reconciliation.

Pattern 4: Why did we kill the blocking reviewer gate?

Early versions of ClaudeKit used a blocking quality gate: a reviewer agent would score a deliverable 0 to 100, and the workflow would loop back with fixes up to three iterations before escalating. It showed up in nearly every deliverable command.

We removed it in v2. The gate was solving a real problem, low-floor output, but creating a worse one: non-deterministic loops, escalating token costs, and outputs that passed the numeric rubric while missing the actual goal. A score of 90 on a rubric does not mean the artifact is useful.

The v2 architecture replaces the gate with an evidence contract: every command ends by emitting a specific, inspectable artifact (a diff, a ranked report, a verified file) that the human reviews. The agents that remain are read-only specialists: a reviewer reads and annotates, an auditor flags issues, a researcher surfaces data. None of them block the workflow.

From /eng verify, for example, the final step is not "reviewer gates on score" but rather: verification-report.md written with test results, coverage delta, and open risk items. You read it. You decide.

This is also why the blocking reviewer gate post exists: it documents the v1 architecture and the reasoning for moving away from it. If you are building your own commands, that post is worth reading before you add a quality gate.

Evidence contract format

Every ClaudeKit command declares its artifact contract explicitly:

/eng debug    → debug-report.md: root cause, affected paths, fix applied,
                regression tests added.
 
/seo quick-wins → quick-wins.md: positions 8-20 ranked by gap score,
                  low-CTR pages ranked by impression volume, next actions.
 
/ecom no-sales  → triage-report.md: store diagnosis vs. AOV-band benchmarks,
                  top 3 friction points, ranked fix list.
 
/mkt repurpose  → repurposed/: 5 format variants (thread, newsletter section,
                  short-form video script, LinkedIn post, email).

Artifact contracts do three things. They make output inspectable: you get files you can read, version, and edit, not an ephemeral chat reply. They make commands composable: /eng handoff reads the debug-report.md that /eng debug wrote. And they make workflows resumable: if a session dies, the artifacts on disk are the checkpoint.

Pattern 5: What is the diagnostic vs. deliverable split?

Not every command should produce a polished artifact. Some commands are diagnostic: they rank problems by impact and recommend the next action. Others are deliverables: they produce copy, code, or structured output for direct use.

The distinction matters because the two types warrant different architectures:

Bolting a quality gate onto a diagnostic command is a mistake: there is nothing to "pass." A report that says "these 8 pages have the biggest ranking gap" is either accurate or not. You verify it by looking at the data, not by running it through a reviewer.

Deliverable commands also should not try to be diagnostic. /mkt humanize does not rank your content problems; it strips 14 AI tells from your draft and returns the cleaned text. One job, one artifact.

How do the five patterns combine? A worked example from EngineerKit

Walk /eng debug and you see all five patterns in one command:

1. CODEBASE.md loaded (bootstrap-context-first).
   If missing, dev-context skill runs to create it.
 
2. error-analyzer reads stack trace / failing test output (sequential —
   dependency gate; without error context nothing else runs).
 
3. Parallel fan-out:
   - root-cause-investigator traces the call path.
   - regression-scanner checks for related failures.
   - test-coverage-auditor identifies uncovered paths.
 
4. fix-writer applies the minimal diff. No reviewer gate.
   fix-writer is instructed to emit the diff with line-level comments.
 
5. Evidence contract written:
   debug-report.md → root cause, affected files, fix diff,
   regression tests added, open risk items.
   Namespace: /eng debug.

Namespaced (/eng debug). Bootstrap context loaded first. Dependency gate before any analysis. Independent analysis passes fan out. Fix emitted as an inspectable diff. No loop, no gate, no numeric score.

That is the entire pattern library in one command.

What does a ClaudeKit install actually look like?

Install is two steps:

ck auth <your-key>
ck install engineer   # installs EngineerKit globally to ~/.claude

Or via the Claude Code plugin marketplace:

/plugin marketplace add Madni-Aghadi/claudekit-engineer

The token ledger prints on every install. ck tokens engineer recounts if you modify anything. ck doctor diagnoses install issues. ck list shows your entitlements across kits.

A Pro license ($29.99/month) gives you any 3 kits with one swap per billing cycle. All-Access ($49.99/month, or $399/year) covers all five. Single-kit licenses are $14.99/month or $99 one-time (as-shipped snapshot, no future updates). Refunds are available within 14 days.

See the full breakdown at /pricing.

How do these patterns compare to building your own commands from scratch?

You can absolutely build namespaced commands, a bootstrap-context skill, parallel fan-out, and evidence artifacts in any Claude Code setup without buying anything. The patterns are architecture, not product. The kits package 101 commands and 82,197 measured tokens of context that already implement these patterns with tested defaults, but the architecture is open and documented here.

The practical tradeoff:

The real cost of free prompt packs post covers the token cost angle in detail. Short version: unmeasured context is expensive at scale. We measured 82,197 tokens across all five kits so you know exactly what you are paying per session.

FAQ

What is the difference between a slash command, a skill, and an agent in Claude Code?

A skill is a single capability module with a measured token cost, loaded into context when relevant. An agent is a read-only specialist role (reviewer, auditor, researcher) that owns a narrow task within a workflow. A slash command is the orchestration layer: it sequences agents and skills toward one outcome and emits an evidence artifact. Commands are the top of the stack; they coordinate the other two. See the full breakdown for worked examples.

Can I run these orchestration patterns without a paid kit?

Yes. The patterns described here are architectural decisions, not gated features. You can implement namespaced commands, bootstrap-context skills, parallel fan-out, and evidence contracts in any Claude Code installation. The kits package 101 pre-built commands with measured token costs and tested defaults, which shortens setup from weeks to minutes, but nothing stops you from building your own.

Why does ClaudeKit use read-only agents instead of orchestrator agents?

Orchestrator agents that spin up and direct other agents introduce non-determinism: the orchestrator decides what runs when, which makes the workflow hard to audit or reproduce. Read-only specialists do one thing (review a diff, audit a page, research a keyword) and report back. The command file itself is the orchestration. This keeps the control flow explicit, readable, and version-controllable in plain text.

How does bootstrap-context-first actually work at install time?

Bootstrap context is not written at install time. It is written the first time you run a bootstrap command like /eng catchup or /mkt voice. Those commands interview you (or scan your project) and write structured markdown files to your project or ~/.claude/. Every subsequent command in that kit checks for those files first and reads them before doing any work. If they are missing, the command either prompts you to run the bootstrap first or runs it inline as a blocking prerequisite.

What token cost should I expect per command run?

Token cost per run depends on the command. A diagnostic like /seo quick-wins might use 3,000 to 6,000 tokens. A full parallel fan-out like /seo audit with 12 concurrent passes can reach 20,000 to 40,000 tokens depending on site data volume. The ck tokens <kit> command shows the static context loaded per kit; runtime tokens vary with your actual content. The token cost measurement post covers methodology in detail.

Does ClaudeKit work with Claude models other than Sonnet?

Yes. Commands are model-agnostic markdown workflows; they work with whatever model Claude Code routes to. In practice, Sonnet 4.5 and Sonnet 4.6 handle the majority of command workloads well. For parallel fan-outs involving many specialists, Haiku 3.5 is worth considering for the individual specialist passes to reduce cost. The model tiering post covers the cost/quality tradeoffs across the current model lineup.

If you are building out an engineering workflow in particular, EngineerKit packages the daily-8 commands that cover the full dev loop: catchup, plan, tdd, debug, verify, review, commit, and handoff. Each one follows the five patterns described here, with 25 commands total and 20,413 measured tokens. Install takes two commands and the token ledger prints automatically so you always know what you are loading into context.