The workflow: an assembly line

What it is and why it matters

When I ask Claude for a new feature in a single message, it does everything itself, in one go: it searches, decides, writes and at the end tells me “done”. For small things that's fine. On a real feature, though, the steps get mixed up. It searches halfway through, plans while it writes, and the check is done by whoever just wrote the code.

A workflow brings order. It's a script Claude writes for your task and Claude Code runs in the background: it launches several subagents, each with its own job, and passes the results from one to the next. The plan no longer lives in Claude's head, it lives in the script. And meanwhile you can keep using the session.

I use it like an assembly line. Five stations, one agent per station, one task each. Every agent gets the piece from the step before and, before working on it, checks that it was done right. If it wasn't, the line stops.

Why it matters: whoever tries to break the code isn't whoever wrote it, so it looks for exactly the holes the author can't see. And if the file list or the plan is wrong, you find out right away, before anyone builds on top of it.

1. The first time: ask for a workflow

You don't write the script. Just ask for it in your own words, like “use a workflow”: Claude writes the script and starts it. The word ultracode in the prompt works too, but you don't need it: a direct request counts the same.

This is the prompt I paste into Claude Code. In place of the square brackets, put the feature you want, described the way you'd explain it to a person.

Use a five-step workflow to: [describe the feature]. Each step is a different agent, with a single task, and it receives the result of the step before.
1. SEARCH: find the files and functions in the code that are involved, with the reason for each.
2. PLAN: check that the list is right and complete, then write a plan in bullet points: what changes, in what order, how it gets verified.
3. BUILD: check that the plan holds up, then follow it and run the tests.
4. BREAK: try to break what was built (empty data, logged-out user, double click, phone). If you find a bug, send it back to step 3 with the description and try again, two times at most.
5. SUMMARY: check that the tests pass, then write what changed, what was tested and what's left to do.
If a step finds a problem in the step before, it stops and says so: nothing moves forward until it's fixed.
Name the workflow "chain" and read the feature to build from args.

What each station does:

• SEARCH doesn't touch anything. It only brings back the list of files, with the reason for each one.
• PLAN first checks the list, then writes what changes, in what order and how it gets verified.
• BUILD checks that the plan holds up, follows it and runs the tests.
• BREAK is the station that makes the difference. It tries the cases you usually forget: empty data, logged-out user, double click, phone. If it finds a bug it sends it back to BUILD, two times at most, so the loop doesn't go on forever.
• SUMMARY checks that the tests pass and tells you what changed, what was tested and what's left to do.

The line “If a step finds a problem…” is the one that holds everything together. Without it, a wrong list at the first step becomes a wrong plan, and then wrong code that passes the tests.

The last line, on the other hand, is for later, when you save it. The command's name comes from the script, so you ask it right away to call it chain. And it reads the feature from args, meaning the input you pass it when you launch it: that way the same chain works on a different feature every time, instead of redoing the first one.

Before it starts, Claude Code usually asks for your permission and shows you the planned phases. From there you can also open the script and read it before you say yes.

2. Follow it while it works

The chain runs in the background, so you can keep typing in the session. To see how far along it is:

/workflows

• You see the phases one under the other, each with its agents.
• Use the arrow keys to pick a phase, press Enter to go in and see what each agent did: the task it got, the tools it used, the result. Esc takes you back.
• p pauses and resumes the run, x stops the selected agent, or the whole run if the run itself is selected.

3. Save it once

When you're happy with a run, you don't have to paste the prompt again every time. You save it as a command:

1. Type /workflows and select the run you want to keep.
2. Press s: the save dialog opens.
3. Use Tab to choose where: .claude/workflows/ in the project, or ~/.claude/workflows/ in your home folder.
4. Press Enter.

In .claude/workflows/ the chain works for that project, and if you commit it, anyone who clones the repository gets it too. In ~/.claude/workflows/ you have it in all your projects, and only you can see it.

What you save is the run's script, not the prompt. So every time, the chain does the same steps, in the same order, with the same checks. And the command takes the name written in the script: that's why the prompt asked it to call it chain.

4. Launch it whenever you want

From the next session on, one line is all it takes, with the new feature:

Run /chain for: add sign-in with Google

What you write after “for:” reaches the script in args, and the chain works on that feature. You still follow the work from /workflows, phase by phase.

5. Before you use it for real

It uses more tokens

A workflow launches several agents, so one run uses more tokens than a normal request, and it counts toward your plan's limits. Try it on something small first. In /workflows you can see how many tokens each agent uses while it works, and you can stop the run whenever you want.

If /workflows isn't there

Workflows are available on all paid plans, but on the Pro plan you have to turn them on: open /config and look for the Dynamic workflows row. If they're off there, neither /workflows nor the saved commands work.

The same chain, without a workflow

Alternatively, put the same text in .claude/skills/chain/SKILL.md. It becomes a skill, and you launch it with /chain. Three tweaks: in place of [describe the feature] write $ARGUMENTS, so Claude Code fills in whatever you type after the command; turn the first sentence into “Follow these five steps to:”; remove the last line, the one about chain and args. Then ask Claude to use a different subagent for each step. And use one route or the other, not both with the same name: that way you always know which /chain you're launching.

Run /chain for: add sign-in with Google. Use a different subagent for each step.

The steps are the same. What changes is who holds the thread: with the skill, Claude passes the work from one helper to the next, and the results go through your conversation. With the workflow, the script does it, and you only get the final summary.

Common mistakes

• Using the chain for a piece of copy or a color. Five agents for one line are just waiting and tokens: for small things a normal message is enough.
• Removing the line “If a step finds a problem…”. Without a check between one step and the next, an early mistake makes it all the way to the end: always keep it.
• Removing the line about chain and args. Without it, the command gets a different name and may keep redoing the feature from the first time: keep it in the prompt.
• Starting straight away with a big feature. The first time, try it on something small and check in /workflows how many tokens it uses.
• Trusting the summary without looking. Read what's left to do and try the feature yourself, at least once on your phone.

Checklist

• The prompt has the five steps and the check line
• The feature is described in place of the square brackets
• The workflow is named chain and reads the feature from args
• First run on something small
• I follow the run from /workflows
• Saved with s, in the project or in ~/.claude/workflows/
• I read the summary and tried the feature myself

Frequently asked questions