From Prompt to Workflow: What Turns an Interaction Into a System
You have a prompt that worked. Maybe you have it in a note somewhere, maybe you scroll back through an old conversation to find it, maybe you just retype it from memory each time and it comes out slightly different. It’s the good one. It produced a summary you actually sent, or a draft you only lightly touched. So every time that task comes around, you go looking for it.
That search is the whole problem in miniature. The thing you’re hunting for isn’t a document. It lives in your head, and it works when you happen to remember all of it.
The perfect prompt is the wrong hunt
Most people, once they’ve been burned a few times by output that came back usable on Tuesday and useless on Thursday, conclude that they’re missing the right words. So they collect prompts. They read the roundups. They try phrasings.
The ceiling on that approach shows up fast: two requests that look nearly identical to you produce two different qualities of result, and you can’t tell which of the two hundred small differences between them mattered. Wording is the visible part. It isn’t the load-bearing part.
What actually separates a request that holds up from one that’s a coin flip is how much of your situation the request carries. A prompt is not a spell. It’s a set of conditions you hand to Claude, and everything you don’t hand over, Claude fills in with a reasonable guess. Reasonable guesses are exactly where generic output comes from. They’re also why the result changes: your guesses about what to include change day to day, so Claude’s guesses change to match.
Look at any request you’ve written and ask what it left to guesswork. In practice there are four places to look.
The first is the reality you’re working in. Not your biography, and not “I’m a manager” either. The operational version: who reads this, in what setting, at what register, under what constraint. A line like this goes to a client contact who skims it on a phone before a call does more work than three sentences about your role.
The second is the instruction itself: what to produce, in what shape, at what length, with what explicitly ruled out. Precision here is what removes rounds of correction later. “Write a summary” is a request. “Three sections, under 250 words, every point tied to a number from the source” is an instruction.
Then the material. Claude working from your actual notes gives you a summary of your meeting. Claude working from general knowledge gives you a summary of a meeting, which can read as fluent and still be wrong for you.
And the one almost everyone skips: what “done correctly” means, stated well enough that Claude can check its own output against it before handing it back. Not “is this good.” Something answerable, like does every item here have a name attached to it, and is there anything in this draft that isn’t in the source.
The use of this is diagnostic, not a licence to write longer prompts. When an output disappoints you, one of those four is usually thin, and you can add that one instead of rewriting the whole thing and hoping. A short prompt for a quick task is correct, not lazy. The point is knowing which piece is missing when the result comes back off.
The line between a prompt you retype and a workflow that exists
A well-built prompt still has a hard limit: it answers one case.
There’s one move that changes that. Take the prompt and find the parts that belong only to today — the specific names, the specific date, the specific length you happened to want. Replace each with a slot you fill in. That’s it. The thing that answered Tuesday’s request now answers every request of that kind.
Small move, large consequence. It’s the first moment the work stops living in your memory and starts living in a form.
But most of what you’d actually like off your plate isn’t one prompt anyway. It’s a short sequence. Take raw material, organize it, shape it into the output, tighten it, check it. You already do this — you just do it live, improvising each step based on what came back from the last one. Improvising is why the output is a different shape every time. You ask a little differently every time, because you’re a person, and it’s Thursday at five.
Designing the sequence in advance is what makes it a workflow. Three things have to be true before it earns the word.
It exists before you run it, as a thing that’s written rather than an idea you hold.
It’s repeatable. Similar input on a different day gives you the same type and quality of output, not the same output.
It has edges. It knows what starts it — an actual event, “right after the monthly numbers land” — and it knows where it ends, which is a verified result, not a message you feel done with.
A workflow is not a long chat. A long chat sprawls. It is also not one enormous prompt with everything crammed in. The rule that makes sequences work is that each step does one job: organize, then draft, then tighten, then check. Not because Claude can’t handle more at once, but because when a four-step sequence produces something weak, you can see which step did it. When one giant prompt produces something weak, you have no handle on it.
None of this needs code, tools, or anything technical. You run it by hand. It just runs the same way every time.
The moment an interaction becomes documented
The first run of any sequence is a diagnostic, not a validation. Run it on real material from your own week, never on a made-up case, because invented input is polite and hides the failures. Then find the single weakest step and change only that one. Change two and get a better result and you’ve learned nothing about which fix worked.
Then the part people skip.
A workflow you built and tested but never wrote down is a workflow you will rebuild from memory next time, badly. Writing it down is the line itself.
What has to be on the page is short: what this is called, what event triggers it, what has to be in your hands before you start, the full sequence with the slots left as slots, what the finished output looks like, and the check that tells you it’s done. Six things. Fifteen minutes.
The test for whether you’ve actually written it down is not whether you’d understand it. You wrote it, of course you’d understand it. The test is whether a competent colleague who doesn’t know the task could pick up the page and run it and get your result. That’s the bar, because that bar is the only one your future self — six weeks out, no memory of the reasoning — actually meets.
A prompt is something you have. A workflow is something that exists whether or not you remember it. The distance between them is one document.
This piece covers the Implement stage of the method I lay out in Stop Using Claude AI Like a Magic 8-Ball, which works through building your first one end to end.