That is the whole test, and it is what separates a chain from the "workflow template" collections that repackage the same three steps under new names. Below is the pattern set the library builds from, the criteria any chain must meet to be worth reusing, and the failure modes that make a chain worse than a single good prompt.
Most of the reusable prompt chains that get shared publicly are described by their subject rather than their structure, which is why two chains for unrelated work turn out to be the same four steps. Naming the pattern at each step is what makes a chain comparable to another one, and comparable is the property that lets you choose between them.
The number in this library's name is the number of pattern slots it reserves, not a claim that a particular number of finished chains exist. Six patterns cover most of the reusable work.
The six patterns every reusable prompt chain is built from
| Pattern | What the step does | Typical use |
|---|---|---|
| Extract | Turns messy source text into a fixed list of fields | Pulling dates, totals or objections out of email threads |
| Transform | Rewrites content that already exists, under fixed rules | Turning notes into a summary in a house format |
| Draft | Writes something new from given constraints and examples | First drafts of emails, briefs or listings |
| Critique | Judges a draft against named criteria and returns findings only | Reviewing a draft before a human reads it |
| Gate | Checks a condition and routes to one of a fixed set of paths | Sorting urgent from routine, or escalate or proceed |
| Assemble | Joins approved pieces into one finished output | Building a report from sections the chain already cleared |
Six patterns, reused with different fields, produce most of what gets sold as a specialised chain product. A chain worth keeping is usually three to five steps, with at most one Draft and one Critique in it.
Criteria for judging a chain before you adopt it
Ask these five questions in order. Any "no" or "it depends" is a reason to rebuild rather than adopt.
- Does every step have one job? If a step says summarise, format and rewrite, split it. Multi job steps fail in ways you cannot isolate.
- Is each input specified? The step should say what data it receives, not assume it. Missing inputs are the main reason chain templates break when real work arrives.
- Are the constraints negative as well as positive? Every step needs at least one instruction about what it must not do.
- Is the stopping point obvious? A chain should end at a finished artefact or a held question, never at "generate more".
- Can you rerun one step without rerunning the chain? If step four always follows step three's output, the steps are not independent and the chain is harder to debug than the work.
What a well specified chain step looks like
Step [n], [pattern name]: [one job in a sentence] Input: [exactly what arrives, and where it came from] Produce: [the output shape, with fields named] Rules: [the constraints, including at least one prohibition] If the input is missing [name it], stop and ask for it. Do not fill it with a plausible value.
This block is the unit of the library. Written at this level of specificity, steps can be reordered, replaced or reused in a different chain without rewriting the rest.
Worked example: one chain, three jobs
A small agency wants one chain that turns client call notes into an internal summary, a client email, and a follow up list. Using the patterns above:
| Step | Pattern | Job | Output |
|---|---|---|---|
| 1 | Extract | Pull decisions, owners and dates from the notes | A fixed field list |
| 2 | Critique | Flag any decision without an owner or a date | Findings only, no rewriting |
| 3 | Draft | Write the client email using only cleared items | Email under a stated length |
| 4 | Gate | Send back for owner and date if step two found gaps | Held list, or pass |
| 5 | Assemble | Join the email, action list and next meeting time | One shareable brief |
Same chain, three jobs, because the extraction step is the only step that touches the raw source. When a fourth job appears, add a pattern at the front or the end. Do not add a second Draft in the middle, because the Critique step then has two things to review.
When a chain is the wrong tool
Some tasks should stay in one prompt. If the work is a single transformation with a known input, a chain adds latency, cost and failure points for no gain. The honest test is whether any step needs to be inspected, approved or rerun on its own. If nothing does, stay with one prompt.
Two other cases deserve scepticism. If a chain exists only to add a summary step at the end, it is a length tax. If a chain depends on a model producing output in a format you then have to repair before the next step can run, the step order is wrong, not the prompt.
Common chain mistakes
- Chains built around the tool, not the job. Naming a product in a step description couples the chain to a product that will change.
- No held question anywhere. Real work sometimes cannot proceed. A chain without a stop that returns control to a person will invent the missing piece.
- Two steps that could run in parallel, run in sequence. Chain length becomes latency for no gain in quality.
- Reusing steps whose inputs do not match. A step written for a tidy summary will fail on raw notes, whatever its label says.
- Keeping a chain nobody owns. If no one can say which inputs changed, the chain is stale and will quietly produce worse output.
Frequently asked questions
What is the difference between a prompt chain and a multi step prompt?
A multi step prompt asks one model to do several jobs in a single pass. A chain gives each job its own pass with its own instructions and its own output format, so a bad step can be rerun or replaced without touching the rest.
How long should a prompt chain be?
Three to five steps covers almost all reusable work. Each extra step adds a failure point and a chance for detail to be lost between formats, so add a step only when you need something inspected or approved on its own.
Can I reuse one chain across different clients or teams?
Yes, if you parameterise the inputs rather than rewriting the steps. Keep the rules and prohibitions fixed, and move the client, audience and tone into the fields at the top. If a client's project needs different rules inside a step, that is a second chain, not a variant.
Standardise the steps, not the product
Pick one job you repeat, name the pattern at each step, and write the constraints before you write the prompts. The chain library collects the system prompt patterns these steps are built from, so start there when a step needs more structure than a one liner.