The Production Playbook

The Complete Command Reference

Claude Code ships with 50+ slash commands. You will use ten daily, fifteen more monthly, and the rest only when something breaks. This is the full table organized by purpose. Print it, pin it, memorize the daily drivers.

Daily drivers · the ten you use every session

Session management

Agents, skills, plugins, MCP

Review & quality

Git Workflows — Agent-Safe From Day One

Most Claude Code disasters are git disasters. The agent force-pushes to main, commits .env to the public remote, or drops an in-progress branch when you ask for a clean slate. Every one of these is preventable at the hook level. Here is the workflow that makes agent-driven git safe for solo work, safer for teams, and bulletproof with the right rails.

Branch naming, enforced

CLAUDE.md should specify your branch format. Mine is feature/<ticket>-<slug> or fix/<ticket>-<slug>. Claude honors it. A PreToolUse hook on Bash rejects git checkout -b calls with names that don’t match. You never end up with a mybranch or test-thing in your repo again.

#!/usr/bin/env bash
input=$(cat)
command=$(echo "$input" | jq -r '.tool_input.command // ""')

# Only intercept branch-creating commands
if echo "$command" | grep -qE 'git (checkout -b|switch -c)'; then
  branch=$(echo "$command" | grep -oE '(-b|-c)\s+\S+' | awk '{print $2}')
  if ! echo "$branch" | grep -qE '^(feature|fix|chore|docs|refactor)/[A-Z0-9]+-.+'; then
    echo "BLOCKED: branch name must match (feature|fix|chore|docs|refactor)/TICKET-slug" >&2
    exit 2
  fi
fi
exit 0

Worktree isolation for parallel agents

When you run more than one subagent at once, and they both want to write files, they step on each other. Git worktrees solve this. Each subagent with isolation: worktree gets its own checkout of the repo in a sibling directory. Same git history, different working trees, zero file conflicts.

# Create a worktree for a new feature branch
git worktree add ../repo-checkout feature/T-123-checkout

# Your main repo stays on its branch; the worktree is on feature/T-123-checkout
# Agent writes files in ../repo-checkout with no risk to your main working tree

# List worktrees
git worktree list

# Clean up after the agent finishes
git worktree remove ../repo-checkout

Conventional commits, auto-drafted

Conventional commits (feat:, fix:, docs:, refactor:, test:, chore:) give you readable history, automated changelogs, and semantic version bumps from tools like standard-version or release-please. Your CLAUDE.md requires the format; your /ship-it command drafts the message from staged changes. You approve, commit, push.

Solo vs team adjustments

Solo work: you can skip the PR step for small fixes and commit directly to a branch, then fast-forward main. Keep the branch discipline so your history stays clean even if review is self-review.

Team work: PRs are non-negotiable. Require at least one human reviewer even when Claude drafted the review. The reviewer subagent finds issues; the human weighs them and owns the merge. Do not let the agent be the last approver on its own work.

The DDS Vibe Coding Methodology — Five Pillars

Vibe Coding is how I built the DDS Sovereign AGI Suite solo: 15 synthetic employees, $11.1M+/year in automated labor, $0/month hosting. The core idea is simple — you are no longer writing most of the code. You are defining the constraints under which AI writes it for you. Your job is specification, architecture, and review. The AI’s job is implementation. Done right, your productivity stops scaling linearly with your typing speed.

Five pillars hold the methodology up. Remove any one and the system degrades into a chatbot conversation that produces inconsistent code. All five in place, and you have an engineering system.

Pillar 1 · Constraint-First Design

Write the rules before the code. Every DDS project begins with a CLAUDE.md that enumerates non-negotiables: language version, style rules, architecture pattern, test requirements, forbidden operations, communication conventions. The rules exist before the first file does. When Claude writes the first module, it inherits a coherent system. When it writes the hundredth, the system is still coherent.

Maps to Claude Code: CLAUDE.md + path-scoped rule files in .claude/rules/ + Skills for domain-specific constraints. The stricter the constraints up front, the less you arbitrate style later.

Pillar 2 · Progressive Disclosure

Load capability only when needed. Every Skill Claude knows about costs tokens on every turn. A 40-skill setup with bad discipline loads 40x the necessary context every prompt. The fix is tight skill descriptions that act as narrow triggers — each skill declares precisely when it applies and when it does not. Claude reads only the descriptions (100 tokens each) on every turn, and loads the full skill body only when your intent matches.

Maps to Claude Code: Skills with precise description strings, path-scoped rule files with paths: matchers, subagents that research in isolation and return summaries. The pattern is always: keep the always-on layer minimal; let the on-demand layer carry the depth.

Pillar 3 · Deterministic Rails

Hooks enforce what prompts cannot. CLAUDE.md says “never commit .env.” Claude respects that 99% of the time. A hook that rejects git add .env respects it 100%. The difference matters under load. Every DDS project has at minimum three hooks: block-sensitive-commits (PreToolUse on Bash), auto-lint (PostToolUse on Write/Edit), and session-end notification (Stop).

Maps to Claude Code: Hooks on PreToolUse, PostToolUse, SessionStart, Stop. Scoped to specific matchers. Non-zero exit codes that block. Written in whatever shell language your team can read and audit.

Pillar 4 · Context Hygiene

Every session starts clean. A 4-hour session with 40 files loaded is slower, dumber, and more expensive than a fresh session reading only what the next task needs. The methodology is: offload research to subagents, compact at task boundaries, resume sessions only when you need continuity, start fresh otherwise. Check /context when anything feels off.

Maps to Claude Code: Subagents for research, /compact at task boundaries, /autocompact for hands-off runs, /recap to re-orient on return, short sessions whenever possible. The cheapest productivity gain in Claude Code is the discipline to start fresh.

Pillar 5 · Sovereign Fallback

Always have a local path. API quota will hit. Internet will go down. A client will hand you regulated data. In every case, you need the option of running the same agent with a local model and no network. Ollama is the DDS answer: local for private or high-volume, Ollama Cloud free tier for routine, Anthropic API for frontier. The workflow is the same; only the provider changes.

Maps to Claude Code: Third-party providers configured in ~/.claude/settings.json, /model to switch, recommended Ollama env vars (Part 1 Module 05). Sovereign is a discipline, not a one-time setup — you test it monthly so it works when you need it.

Walkthrough — A Full React App in One Session

Theory is cheap. Here is a complete walkthrough of building a real React app from empty directory to working UI in a single focused Claude Code session. The app: a task tracker with typed forms, local persistence, keyboard shortcuts, and tests. The method: the 5 Pillars, applied in sequence.

Step 1 · Pillar 1 applied: write constraints first

mkdir task-tracker && cd task-tracker
git init
claude

First prompt: “I’m building a React 19 + TypeScript task tracker with Vite, Zustand for state, Vitest for tests, Tailwind for styling. Before you do anything, draft a CLAUDE.md with rules for this stack. Keep it under 150 lines. I’ll review before you touch any other file.”

Claude drafts CLAUDE.md. You open it and tighten: no default exports, component files under 200 lines, co-located tests, Zod-validated env vars, conventional commits, never run npm audit fix --force. Save. Commit.

Step 2 · Pillar 2 applied: load only the skills you need

Second prompt: “Create .claude/skills/react-component-author/SKILL.md with our component conventions. It should trigger only when I ask for a new component. Include frontmatter with a precise description.”

Claude creates the skill. The description includes the exact trigger (“create a component,” “add a UI element”) and the explicit exclusions (“does NOT trigger for pages or hooks”). You check /context — still lean. Commit.

Step 3 · Pillar 3 applied: install the rails

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./.claude/hooks/block-sensitive.sh" }]
    }],
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": "npx eslint --fix \"$CLAUDE_TOOL_FILE_PATH\" 2>/dev/null || true" }]
    }]
  }
}

Step 4 · Build the app

Now you can be loose because the rails are tight. Third prompt: “Scaffold the Vite + React + TS project. Run the tests. Set up Tailwind. Commit at each checkpoint. Conventional-commits format.”

Claude does. Watch the terminal — auto-lint fires after every file write, block-sensitive-commits is standing by, CLAUDE.md is enforcing style. You are not micromanaging. You are reviewing commits as they happen.

Fourth prompt: “Implement the task store with Zustand. Tasks have id, title, status (todo|doing|done), createdAt, updatedAt. Persist to localStorage. Include tests for add, update, toggle, delete. Do not wire the UI yet.”

Claude writes src/stores/tasks.ts and src/stores/tasks.test.ts. The component-author skill does not load — this is a store, not a component. Tests pass. Commit.

Step 5 · Pillar 4 applied: offload research to a subagent

Fifth prompt: “Before building the UI, use the Explore subagent to scan the Zustand docs at node_modules/zustand and summarize the persist middleware options in three bullets. Don’t load anything into my main context.”

Explore (Haiku, read-only) runs in its own context, scans, returns three clean bullets. Your main context is untouched. You now know exactly which middleware config you want without having read the docs yourself.

Step 6 · Components, tests, shortcuts

Sixth prompt: “Build the TaskList, TaskItem, TaskInput components. Use the component-author skill. Wire keyboard shortcuts: N for new, D for delete on focused item, Enter to toggle. Add tests for each component.”

The component-author skill loads now — the trigger matches. Claude builds three components following its rules. Co-located tests for each. /ship-it runs: lint clean, 23 tests pass, build succeeds. Draft commit message. Approve. Commit.

Step 7 · Reviewer subagent before final commit

Seventh prompt: “Run the code-reviewer subagent on the full diff from this branch. Focus on accessibility and keyboard navigation edge cases.”

The reviewer (Opus, read-only) finds two issues: one aria-label missing on the delete button, one focus-trap missing on the new-task input. You fix both. Commit. Push. PR open.

Step 8 · Pillar 5 applied: test the sovereign path

Before closing the session: /model ollama-cloud/qwen3-coder:480b-cloud. Ask one small follow-up to verify the sovereign provider works. Switch back. Now you know your fallback is live.

Walkthrough — A Shopify Section That Passes Theme Check

Shopify sections have their own discipline. Scoped CSS or you pollute the whole theme. Schema ranges that fail the (max-min)/step >= 3 rule refuse to save. IIFE JS or you leak globals into other sections. This walkthrough shows how a well-designed skill makes Claude Code produce sections that pass shopify theme check on first try — every time.

The skill that does the work

The shopify-section-author skill lives at .claude/skills/shopify-section-author/SKILL.md plus a references/atelier-standards.md file. Frontmatter triggers only on section-authoring requests. Skill body enforces: unique wrapper class for CSS scope, Liquid with defensive filters (| default:, | escape), JSON schema with valid ranges, IIFE JS block with zero globals, no !important on body/html/header/footer.

Step 1 · Trigger the skill

Prompt: “Build me a new Shopify section called testimonial-carousel. Three blocks with customer name, quote, star rating (1-5). Auto-advance every 5 seconds, pause on hover, respect reduced-motion. Style settings for background, text color, and padding.”

The skill description matches (“build a section”). Claude loads the full body and the Atelier standards reference. Your main context doesn’t load them — only Claude does, for this task.

Step 2 · What Claude produces

<style>
.tc-section { /* all CSS scoped under .tc- */ }
.tc-slide { /* ... */ }
</style>

<div class="tc-section" style="--tc-bg: {{ section.settings.bg_color | default: '#ffffff' }}">
  {% for block in section.blocks %}
    <div class="tc-slide" {{ block.shopify_attributes }}>
      {%- liquid
        assign rating = block.settings.rating | default: 5
        assign name = block.settings.customer_name | default: '' | escape
      -%}
      ...
    </div>
  {% endfor %}
</div>

<script>
(function(){ /* IIFE, zero globals */ })();
</script>

{% schema %}
{
  "name": "Testimonial Carousel",
  "settings": [
    { "type": "range", "id": "autoplay_seconds",
      "min": 3, "max": 12, "step": 1, "default": 5 }
    // (12-3)/1 = 9 ≥ 3 ✓, (5-3)%1 = 0 ✓, 5 ≤ 12 ✓
  ],
  "blocks": [ /* ... */ ]
}
{% endschema %}

Step 3 · Validation

# A PostToolUse hook fires automatically after the file is written
shopify theme check sections/testimonial-carousel.liquid

# Theme check passes: scoped CSS confirmed, valid Liquid, valid schema

Multi-Agent Orchestration

Part 1 introduced subagents and agent teams. This module is how you actually orchestrate them in production — the patterns, the anti-patterns, and the tradeoffs you hit at scale.

The four canonical patterns

The five anti-patterns

Plugins & the Ecosystem

A plugin is how you package everything — skills, subagents, slash commands, hooks, MCP server configs — for one-command install. Teams that share plugins share a consistent development experience. Open-source plugins let you adopt community expertise with a single command.

Plugin anatomy

my-plugin/
├── manifest.json           # name, version, author, description
├── skills/
│   └── review/
│       └── SKILL.md
├── agents/
│   └── security-reviewer.md
├── commands/
│   └── ship-it.md
├── hooks/
│   └── block-sensitive.sh
└── mcp/
    └── config.json            # MCP server definitions (optional)

Installing and managing plugins

# Open the plugin marketplace
/plugins

# Install a plugin from a published marketplace
/plugins install <plugin-name>

# Install from a local path (team plugin during development)
/plugins install ./my-team-plugin

# Install from a git URL
/plugins marketplace add https://github.com/org/repo-with-plugin

# List installed plugins and their components
/plugins list

# Reload after editing a local plugin
/reload-plugins

The security boundary for plugin subagents

A subagent bundled inside a plugin cannot define its own hooks, mcpServers, or permissionMode. This is deliberate. An installed plugin should not be able to silently add new hooks that run with your full permissions, connect to servers you didn’t approve, or escalate permission mode past what the host session granted. Plugin subagents inherit the host’s security context. Your plugins, your rails.

Three plugin patterns worth knowing

IDE Deep Dive — Where to Actually Work

Claude Code’s surfaces (terminal, VS Code, Cursor, Windsurf, JetBrains, desktop, web, mobile, Slack) sound like a long list of equivalent options. They are not. Each has a best use and a worst use. Here is how professionals actually divide their day.

Terminal CLI — the power seat

Use for: agent orchestration (subagents, teams), scripted runs in CI, third-party providers like Ollama, heavy multi-file refactors, anything you want to kick off and walk away from with hooks running. The terminal is where every Claude Code feature exists first; other surfaces catch up later.

Don’t use for: rapid exploratory coding where you want to see diffs inline with the surrounding code. Terminal diffs are good, but not as immediate as an editor-native diff view.

VS Code / Cursor / Windsurf extension — the flow seat

Use for: daily feature coding with tight iteration. @-mention files to add context, drag-and-drop images or PDFs as context, inline diff review with per-hunk accept/reject (as of 2026), a sidebar conversation history across sessions, Cmd+Esc / Ctrl+Esc to launch without leaving the editor.

The 2026 killer feature: inline edit review. When Claude proposes a multi-file change, you see each file’s diff inline with your code. Accept, reject, or edit per hunk. This is closer to a code review surface than a chat window.

JetBrains plugin

Use for: IntelliJ, PyCharm, WebStorm, CLion, Rider users. Feature parity with the VS Code extension: interactive diff viewer, shared selection with the editor, diagnostics integration. If you are already a JetBrains loyalist, the plugin is the right choice — don’t context-switch to VS Code just to use Claude.

Desktop app, web, mobile

Desktop for visual multi-session management: run three Claude sessions side by side, schedule recurring tasks, manage cloud sessions. Great when you’re coordinating multiple agents at once.

Web (claude.ai/code) for borrowed machines and remote work. Mobile (iOS/Android) for kicking off tasks in airports, reviewing finished work over coffee, and answering your agent’s one-line question without opening a laptop. None of these replaces terminal or editor for heavy lifting — they extend the surface area.

Slack integration

Use for: team workflows where the task request and the output both live in Slack. Tag @claude with a request; work happens; result posts back in thread. Also useful for the Claude GitHub app doing PR reviews — review output shows up where your team already discusses code.

The daily mix most professionals settle on

Heavy lifting — refactors, new features, multi-agent runs — in terminal. Daily coding in VS Code or JetBrains. Status checks and small tasks on mobile. PR reviews in Slack. All four share session state; switch between them without losing context.

Cost Control & Rate Limits

Claude Code usage is billed against your Claude Pro/Team/Enterprise plan or your Anthropic Console API credits. Rate limits apply in both cases — 5-hour and 7-day windows with usage percentages and reset times. Hit a limit in the middle of a task and you wait. Learn to see the limits coming and you never wait.

The four levers

Visible rate limits in your statusline

As of 2026 Claude Code exposes rate_limits objects in statusline scripts — with used_percentage and resets_at for both the 5-hour and 7-day windows. Wire these into your prompt and you see consumption at a glance. No more surprise throttle mid-refactor.

#!/usr/bin/env bash
ctx=$(cat)
pct_5h=$(echo "$ctx" | jq -r '.rate_limits.session.used_percentage // 0')
pct_7d=$(echo "$ctx" | jq -r '.rate_limits.weekly.used_percentage // 0')
model=$(echo "$ctx" | jq -r '.model.display_name // "?"')

printf "%s | 5h: %s%% | 7d: %s%%" "$model" "$pct_5h" "$pct_7d"

Cost patterns by task type

Three Case Studies from the Sovereign AGI Suite

Three DDS systems, built with Claude Code, shipped to production. What follows are the patterns — how Claude Code was used, which primitives did the heavy lifting, what went wrong and how it got fixed. The proprietary internals (the actual CLAUDE.md files, the skill libraries, the orchestration logic) stay with DDS. The patterns are yours to adapt.

The $250K Cheat Sheet

If you only remember seven things from this entire masterclass, remember these. Print this page. Pin it next to your monitor. Everything here is load-bearing — every line corresponds to a module above, condensed to its smallest useful form.

What’s Next — Three Directions From Here

You finished 25 modules across two parts. You have the primitives, the patterns, the playbook. The question is: where does your own edge come from? Three directions. Pick the one that matches how you think.

The next DDS Vibe Academy masterclass

The sovereign path is the direction the next DDS masterclass will go deep on. End-to-end: hardware sizing for multi-model fleets, Ollama orchestration at scale, building your own model router, running subagent teams against local inference, the full DDS Sovereign AGI Suite architecture in detail. Release horizon: Mythos Era — the codename for the next wave of DDS public releases, covering the AGI systems that ship in 2026 H2.

Subscribe to the DDS Vibe Academy to catch the release. Keep an eye on the portfolio for Sovereign Orchestrator Pro V5.0, AGI-CORE-Pro V.1.0, VibeTube AI Desktop Pro V1.1.1, and NICHE-FORGE-CORE V3.0 updates — those are where the methodology in this masterclass runs in production.