Reusable Prompts & Workflows

A finished spec helps one job. The prompt that reliably produces good specs helps every job, forever - so the highest-leverage thing you can save is not the answer but the method that got it. Yet almost nobody does, because prompts feel disposable: you type, you get a result, you move on. Treat them instead as small, valuable tools the practice owns.

What makes a prompt worth saving is that it is reusable - written so it works again with different inputs, not welded to one job. Compare these two. The throwaway version: "Write a finishes schedule for the Kapoor bathroom, porcelain floor, MS partition, the usual." It worked once because you held all the context in your head. The reusable version names its slots:

Role: you are drafting for [Practice], following our finishes-schedule
template in project knowledge.
Task: produce a finishes schedule for [room].
Inputs I will give: floor, wall, ceiling, skirting, notable fittings.
Rules: use our clause wording; SI units; insert [VERIFY] for any
figure, standard or product code I have not supplied - never invent one.
Output: the schedule as a table, then a short list of what you flagged.
---
[room]: master bathroom
[floor]: 600x600 matt porcelain ...

The reusable version has the role, the task, the named inputs, the rules and the output format made explicit and separable from the specifics - so anyone can drop in a new room and get consistent work. That is the whole craft: not clever wording, but a clear, parameterised structure that survives being handed to someone else. It rests on the ordinary principles of good prompting from Module 1 - role, context, task, format, constraints - now written for reuse rather than typed once and forgotten.

Save these where the studio can find them - ideally beside the knowledge they act on, in or next to the relevant Project - and give each a plain name and a one-line note on what it is for. A prompt nobody can locate is not a library; it is a lost chat.

Much real practice work is not one prompt but a sequence: research, then structure, then draft, then check. Trying to do it all in one giant prompt usually produces a mediocre blur, because you are asking Claude to make every decision at once with no chance for you to steer between stages. The better pattern is a workflow - a documented chain of prompts with a human checkpoint between the important steps.

Take turning a messy client meeting into an issued brief. As a workflow it might read:

Step 1  Paste raw notes -> "Extract every stated requirement and every
        implied one; list open questions."  [you check the list]
Step 2  "Draft the brief using our brief template; mark assumptions."
        [you correct assumptions, add what only you know]
Step 3  "Draft a short email to the client listing the open questions
        for confirmation."  [you verify, send]

Three things make this more than three prompts in a row. First, the checkpoints: you read and correct between steps, so an error in step one does not silently poison step three. Second, each step is a small, bounded task, which Claude does far better than a sweeping one. Third, the chain is documented, so the next person runs the same reliable method instead of improvising. Where a Project holds your knowledge, a workflow is the standing procedure for acting on it - the studio's operating instructions for a recurring job.

Be deliberate about where a human must sit in the chain. The rule from the whole course applies: scrutiny scaled to the stakes. A divergent, low-stakes step (brainstorm mood-words) needs only a glance. A convergent, high-stakes step (a clause that goes to site, a number in a fee letter) needs a hard checkpoint where a competent person verifies before the chain continues. Write those checkpoints into the workflow explicitly, as steps in their own right - "[you verify against the source]" - so they are never skipped under deadline pressure. A workflow without human checkpoints is not efficiency; it is automated risk.

A prompt that lives only in your head, or in your chat history, is not a studio asset - it is a dependency on you. The point of this module is to move value out of individuals and into the practice, and that requires writing things down in a form a colleague can pick up cold.

A good entry in a studio prompt library is short and has a predictable shape. Give each one: a name ("Finishes schedule from room inputs"); a one-line purpose; the prompt itself, with its slots clearly marked; a note on what to check in the output; and, where useful, a tiny worked example showing good inputs and a good result. That last part is what turns documentation people ignore into documentation people use - a colleague sees the shape of a good run and copies it.

Store the library somewhere shared and durable - a shared drive, a wiki, or as a document inside the relevant Project - not in scattered chats. Name a custodian, exactly as with Projects in 9.1, whose job is to keep entries current and prune the ones that no longer work. And version them: models and features change, and a prompt tuned for last year may need adjusting, so date each entry and note when it was last confirmed to work.

Guard against two failure modes. The first is a library that grows into an unusable sprawl of near-duplicates; prune hard, keep one good prompt per job rather than five. The second, more dangerous, is a library that quietly encodes a bad habit - a prompt that omits a verification step, or bakes in an assumption that is usually but not always true. Because a documented prompt carries authority, its flaws propagate. So review library prompts the way you review a standard detail: not just "does it work?" but "is it safe when someone runs it without thinking?" A reusable prompt should make the safe path the easy path.

You do not build a prompt library in a weekend; you grow it from real work. The healthiest way to start is a simple rule the whole studio adopts: when a prompt works unusually well, spend two minutes capturing it before you move on. Name it, paste it into the shared library, note what to check. That habit, kept, quietly assembles a genuinely useful playbook over a few months - far better than a big up-front effort that guesses at what people need.

Watch for the prompts and workflows that recur, because those are the ones worth investing in properly - turning a rough capture into a polished, parameterised, well-documented entry with a worked example. The finishes schedule, the client update, the option-comparison matrix, the meeting minutes, the fee-proposal skeleton: most practices have perhaps a dozen jobs that make up the bulk of their repeat Claude use. Get those dozen excellent and you have most of the value.

Keep it honest about limits. A saved prompt is not a guarantee - Claude can still produce a plausible-but-wrong result from a perfect prompt, so the "what to check" note and the human checkpoints are not optional trimmings; they are the part that keeps the library professional. And a prompt tuned to a specific model or feature may drift as those change; the quarterly review that keeps Projects clean should sweep the prompt library too.

The reward is compounding. Each good prompt captured makes the next similar job faster; each workflow documented makes the studio less dependent on any one person's memory; and because it is all written down, you can improve the method once and everyone benefits the same day. That is the difference between eight people each rediscovering Claude and a practice that gets steadily, collectively better at it - which is exactly what the next lesson, rolling Claude out across the team, is built to protect.