Build a dynamic Claude Code workflow: a walkthrough

Reading about dynamic workflows is one thing; building one is another. This walkthrough takes you from an empty project to a working Claude Code setup that loads a skill on demand, calls an MCP server for live data, gates its own edits with a hook, and delegates a search to a subagent. Every step is concrete, in the order you'd actually do them. By the end you'll have a mental template you can reuse for your own tasks.

The running example is small but realistic: a service that reconciles failed payments. We want Claude Code to investigate a failure, pull the relevant transaction from a database, propose a fix, and never edit a file in the protected migrations directory without flagging it. That single task touches every piece of the dynamic harness.

Step 1: Establish the project's standing context

Start with a project memory file at the repo root that Claude Code reads at the beginning of every session. Keep it short and durable — facts that are true across all tasks, not instructions for one task. For our example that means: the service is a TypeScript worker, payments live in Postgres, the migrations folder is off-limits without explicit sign-off, and tests run with a single command.

The discipline here matters. Standing context should answer "what is always true about this codebase?" Anything task-specific belongs in the prompt or a skill, not the memory file, or you'll pay its token cost on every unrelated task. A bloated memory file is the most common reason a Claude Code setup feels sluggish and unfocused.

Step 2: Write a skill for the reconciliation procedure

The reconciliation steps are detailed and used only when a payment fails, so they belong in a skill, not standing context. Create a folder with a clear name and a one-line description that tells the model exactly when to reach for it — "Use when investigating or fixing a failed or stuck payment." That description is the only thing loaded until the skill fires.

Inside the skill body, write the actual procedure as plain instructions: check the transaction status, confirm the gateway webhook was received, verify idempotency keys before retrying, never double-charge. Include a small helper script if a step is mechanical. Now the procedure is advertised for pennies and fully loaded only when a real payment failure pulls it into context.

flowchart TD
  A["Payment failure task"] --> B["Read project memory"]
  B --> C{"Skill relevant?"}
  C -->|Yes| D["Load reconciliation skill"]
  D --> E["Call MCP: fetch transaction"]
  E --> F["Propose code fix"]
  F --> G{"Touches migrations dir?"}
  G -->|Yes| H["Hook blocks & asks"]
  G -->|No| I["Apply edit & run tests"]

Step 3: Connect an MCP server for live transaction data

Claude can't reconcile a payment it can't see. Configure a Postgres MCP server so the model has a typed tool to query transactions. In the server config you point it at the database and, critically, scope its credentials to read-only on the tables it needs. The model now has a tool whose schema describes exactly what arguments a query takes and what shape comes back.

Once connected, you don't tell Claude to use the server — you let the loop discover it. When the loaded skill says "check the transaction status," the model sees a matching MCP tool in its menu and calls it, getting structured rows back rather than guessing. This is the moment the static skill and the live data join up: the skill knows what to do, the server provides the actual state.

Step 4: Add a hook to enforce the guardrail

Standing context says the migrations directory is protected, but a model instruction is a request, not a rule. To make it a rule, add a hook that runs before any file edit. The hook inspects the target path; if it's inside the migrations folder, it blocks the edit and returns a message telling Claude to surface the change for human approval instead of applying it.

This is the key architectural insight of the step: hooks turn soft guidance into hard enforcement. The model can reason all it likes, but the hook executes deterministically outside the model's control. Use hooks for anything where "the model usually remembers" isn't good enough — protected paths, secret-scanning, mandatory formatting, required test runs.

Step 5: Delegate the noisy search to a subagent

Suppose the fix requires finding every call site that constructs a payment retry. Across a large codebase that's a lot of reading, and you don't want all those files clogging the main transcript. Delegate it: spawn a subagent with the focused brief "find all places that build a retry request and report file, line, and the key it uses." The subagent works in its own context window and hands back a tidy list.

The orchestrator never sees the subagent's dozens of file reads — only the distilled answer. That keeps the main loop's context clean and focused on the fix itself. Remember the cost discipline: delegate when the search is large enough that isolation clearly pays, since a subagent run consumes meaningfully more tokens than reading a couple of files inline.

Step 6: Let the loop close itself

With everything wired, the run looks like this end to end: Claude reads the memory file, recognizes a payment failure, loads the reconciliation skill, queries the transaction over MCP, finds call sites via a subagent, proposes an idempotent fix, gets blocked by the hook only if it strays into migrations, applies the safe edit, and runs the test command — looping back if a test fails. You wrote none of that sequence as code. You provided capabilities and constraints; the harness assembled the path.

That's the template to internalize. Standing context for what's always true, skills for procedures loaded on demand, MCP servers for live state, hooks for hard rules, subagents for bounded heavy lifting. Compose those five and you can build a dynamic workflow for almost any engineering task.

Frequently asked questions

Do I need to write code to define the workflow's steps?

No. You configure capabilities — skills, servers, hooks — and the model sequences them at runtime. The only code you write is inside helper scripts, MCP servers, and hooks, none of which dictate the overall order of operations. The sequence emerges from the agent loop reacting to results.

What's the difference between putting a rule in the memory file versus a hook?

The memory file is guidance the model usually follows; a hook is enforcement it cannot bypass. Use the memory file for context and preferences, and a hook for anything where a single miss would be costly, like editing protected files or leaking secrets. They complement each other.

How do I keep the skill from loading when it isn't needed?

Write a precise one-line description that names the exact trigger condition. The model uses that description to decide relevance, so "Use when investigating a failed payment" loads far more selectively than a vague "payment helpers." Sharp descriptions are the main control you have over skill firing.

Bringing agentic workflows to your phone lines

CallSphere applies this same build-from-primitives approach to voice and chat: assistants that load the right procedure per call, pull live records mid-conversation, and book work safely. See a working version at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.