मुख्य कंटेंट तक स्किप करें

Pro Workflows & Power Moves

उन्नत
What you'll learn
  • Orchestrate parallel subagents — and know when to graduate to a script-driven dynamic workflow
  • Make hooks the deterministic glue: lint on save, gate the stop, block forbidden writes
  • Turn your repeated prompts into custom slash-commands, skills, and an output style
  • Build an MCP stack and headless pipelines (claude -p) that run unattended in CI
  • Run the explore → plan → execute → review loop with discipline, and keep context lean
  • Treat CLAUDE.md like code: short, pruned, and high-signal

This is the page where the primitives stop being individual features and start being a workflow. If you already know what a subagent or a hook is, the leverage is in how you stack them: a slash-command that kicks off a plan-mode pass, subagents that fan out the work, a hook that won't let the turn end until tests pass, and a headless invocation that runs the whole thing in CI. Let's wire it together.

The mental model: who holds the plan?​

Every power move below is a different answer to one question — who is holding the plan and the intermediate results? Anthropic's own framing for the new dynamic-workflows feature lays it out cleanly:

ToolWho decides what runs nextWhere results liveScale
SubagentsClaude, turn by turnClaude's context windowA few per turn
SkillsClaude, following the promptClaude's context windowSame as subagents
Agent teamsA lead agent, turn by turnA shared task listA handful of long peers
Dynamic workflowsThe scriptScript variablesDozens to hundreds

The progression is the whole game: start with one Claude, delegate to subagents to protect context, and only move the plan into code when a task needs more agents than one conversation can coordinate.

Move 1 — Parallel subagents, then graduate to a workflow​

A subagent is a separate Claude with its own context window and a scoped toolset; it returns a result, not its transcript. The power-user habit is to fan out independent work:

Fan out a review across modules

Review the changes in auth/, billing/, and api/ — use the code-reviewer
subagent on each, in parallel. Report only correctness bugs and missing tests.

Three reviewers run at once, each burning its own context on the diffs, and your main session sees three tidy reports instead of three raw diffs. The catch: parallelism only helps for independent subtasks. If step B needs step A's output, run them in sequence; if they write the same files, isolate them in git worktrees.

When the task outgrows a single conversation — a 500-file migration, a codebase-wide bug sweep, research cross-checked across many sources — graduate to a dynamic workflow. Claude writes a JavaScript orchestration script (fan out → reduce → synthesize), a runtime executes it in the background with up to 16 concurrent agents, and only the final answer lands in your context. Trigger one with the ultracode keyword or just ask in plain words:

Kick off a dynamic workflow

ultracode: audit every API endpoint under src/routes/ for missing auth checks,
then cross-check each finding with a second agent before reporting

The killer feature isn't just more agents — it's that a script can apply a repeatable quality pattern, like having independent agents adversarially review each other's findings before any are reported. Try the bundled /deep-research <question> to see the pattern live: it votes on each claim and filters out the ones that don't survive cross-checking.

Pro tip
  • Save a good workflow run as a command: open /workflows, select the run, press s. It becomes /your-name in every future session.
  • Gauge cost on a slice first — one directory, not the whole repo. A run can spawn far more agents (and tokens) than a single conversation.

Move 2 — Hooks: the deterministic glue​

CLAUDE.md instructions are advisory — Claude usually follows them. Hooks are deterministic — they run a script at a fixed point in the loop, guaranteed, every time. Reach for a hook when something must happen with zero exceptions.

The three highest-leverage hook patterns:

Guided walkthrough1 of 3
  1. After Claude edits a file, run your formatter or linter automatically so the codebase never drifts. The feedback also flows back to Claude, so it self-corrects.

You don't have to hand-write the JSON. Ask Claude to author the hook for you:

Have Claude write a hook

Write a hook that runs eslint --fix after every file edit, and a second hook
that blocks any Write or Edit to the db/migrations/ folder. Add them to
.claude/settings.json and show me the config.
Watch out
  • A Stop hook that keeps blocking will be overridden after several consecutive blocks so the session can't deadlock — your gate is a safety rail, not an infinite loop.
  • Hooks run with your shell's permissions. Review any hook script before committing it, exactly as you would CI config.

Move 3 — Custom slash-commands, skills & output styles​

Anything you prompt twice should become a primitive. The decision is simple: skills are knowledge, hooks are guarantees, MCP is action, slash-commands are entry points.

A slash-command (or a skill with disable-model-invocation: true) packages a repeatable workflow you trigger by hand. $ARGUMENTS makes it parameterized:

.claude/skills/fix-issue/SKILL.md

---
name: fix-issue
description: Triage and fix a GitHub issue end-to-end
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS:
1. gh issue view to read the issue
2. Search the codebase for the relevant files
3. Write a failing test that reproduces the bug
4. Implement the fix, then run tests and lint until green
5. Commit with a descriptive message and open a PR

Run it with /fix-issue 1234. Use disable-model-invocation: true for anything with side effects you want to trigger deliberately rather than have Claude reach for on its own.

Output styles change how Claude communicates across the whole session — terse for an expert, verbose-with-explanations for teaching, or a structured format your tooling can parse. Pair a custom slash-command (the what) with an output style (the how) and you've shaped both ends of the interaction.

The most under-used power move from the official docs: let Claude interview you before a big feature, then start a fresh session to build from the written spec.

Spec-by-interview, then build in clean context

I want to build [brief description]. Interview me in detail using the
AskUserQuestion tool — technical implementation, UI/UX, edge cases, tradeoffs.
Dig into the hard parts I might not have considered. When we've covered
everything, write a complete, self-contained spec to SPEC.md.

Move 4 — Build an MCP stack​

MCP servers are executable processes Claude calls over JSON-RPC to actually do things — query your database, read Sentry, pull a Figma design, file a Linear issue. A power-user "stack" is a small, deliberate set, not everything you can find:

Add servers to your stack

claude mcp add --transport stdio sentry -- npx -y @sentry/mcp-server
claude mcp add --transport http linear https://mcp.linear.app/sse

Two principles keep an MCP stack fast:

  • Prefer a CLI when one exists. gh, aws, gcloud, and sentry-cli are the most context-efficient way to talk to a service — Claude already knows them, and they don't load a tool schema into every turn. Reserve MCP for services without a good CLI, or where you want structured, typed access.
  • Keep the server list lean. Every connected server's tool definitions consume context up front. Trim servers you're not actively using; bloated tool lists crowd out your actual instructions.

For the deeper why, see Context Engineering — the same attention-budget logic that governs CLAUDE.md governs your tool list.

Move 5 — Headless & Agent SDK pipelines​

claude -p "prompt" runs Claude non-interactively — no session, parseable output — which is the door to CI, pre-commit hooks, and batch jobs. This is the headless / Agent SDK surface.

The classic fan-out-across-files pattern from the official best-practices guide:

Headless batch migration

# 1. Have Claude generate the work list first, then loop:
for file in $(cat files.txt); do
claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
  --allowedTools "Edit,Bash(git commit *)"
done

Two flags do the heavy lifting: --output-format json (or stream-json --verbose) makes results machine-readable, and --allowedTools scopes exactly what Claude may touch when no human is watching. Pipe it anywhere:

Claude as a pipeline stage

cat error.log | claude -p "Cluster these errors by root cause, output JSON" \
--output-format json | jq '.[] | select(.severity=="high")'
Watch out
  • Always test the prompt on 2–3 items before unleashing the loop on 2,000. Refine, then scale.
  • Unattended runs need verification baked in — a Stop hook or an in-prompt test step — or you've just automated producing plausible-but-wrong output at scale.

Move 6 — Plan-mode discipline & context engineering​

The single most reliable quality lever is separating research from execution. The four-phase loop from Anthropic's best-practices guide:

Guided walkthrough1 of 4
  1. Enter plan mode. Claude reads files and answers questions but makes no changes. Point it at the exact directories: 'read /src/auth and explain how sessions work.'

See Plan Mode for the discipline, and skip it when the diff fits in one sentence — planning has overhead. The reason this works is context economy: performance degrades as the window fills, so a 50-token instruction in a 2,000-token context lands far harder than the same instruction buried in 50,000 tokens. Practical habits:

  • /clear between unrelated tasks; a clean session with a better prompt beats a long polluted one.
  • After two failed corrections, stop correcting — /clear and rewrite the prompt with what you learned.
  • Delegate research to subagents so file-reading happens in their context, not yours.

The "level up your setup" path​

If you do nothing else, do these in order:

Guided walkthrough1 of 6
  1. Run /init for a starter, then cut every line that fails the test: 'would removing this cause Claude to make a mistake?' A bloated file makes Claude ignore the rules that matter.

CLAUDE.md mastery​

CLAUDE.md loads at the start of every conversation, so it is the highest-frequency context you control — and therefore the easiest to ruin by overstuffing.

Put in CLAUDE.mdKeep out
Bash commands Claude can't guessAnything Claude finds by reading code
Code-style rules that differ from defaultsStandard conventions Claude already knows
Test runner + how to run a single testFull API docs (link instead)
Repo etiquette (branch/PR naming)Info that changes frequently
Non-obvious gotchas and env quirks"Write clean code" platitudes

Treat it like code: review it when behaviour goes wrong, prune regularly, and use @path/to/file imports plus per-directory CLAUDE.md files so each part of a monorepo gets only what's relevant. Move sometimes-relevant knowledge into skills so it loads on demand instead of taxing every turn.

Check yourself

0/4
  1. You need a 500-file migration coordinated with adversarial cross-checking. Which tool fits best?
  2. What's the key difference between a hook and a CLAUDE.md instruction?
  3. Which flag scopes what Claude may do during an unattended `claude -p` batch run?
  4. Why does pruning CLAUDE.md improve adherence?
Power-move recall — flip each card
Term shown.
1 / 5
Key takeaways
  • The progression is the skill: one Claude → parallel subagents → script-driven dynamic workflows, chosen by who needs to hold the plan.
  • Hooks are the deterministic glue — lint on save, gate the stop, block forbidden writes — for what must happen every time.
  • Package repeated prompts into slash-commands/skills, shape delivery with an output style, and keep an MCP stack lean (prefer CLIs).
  • Headless claude -p with --allowedTools turns Claude into a CI/pipeline stage; always bake in verification for unattended runs.
  • Plan-mode discipline plus aggressive context economy (/clear, subagent research, a pruned CLAUDE.md) is the highest-reliability lever you have.

Sources & further reading​