Chaining & Workflows prompts

Help me design a prompt chain.

WHAT I WANT TO PRODUCE: [THE FINAL OUTPUT]
WHAT I HAVE TO START WITH: [THE INPUT]
WHY ONE PROMPT IS NOT ENOUGH: [WHAT GOES WRONG]
HOW OFTEN I WILL RUN THIS: [one-off / occasionally / many times]
WILL A PERSON BE INVOLVED BETWEEN STEPS: [yes / no / at some points]

Produce:

1. THE STEPS - the chain broken down, each with: what it takes in, what it produces, and why it is a separate step. A step exists because it needs different instructions, different context, or a checkpoint, not simply because the task is long.

2. THE INTERFACE BETWEEN STEPS - the most important design decision. For each handoff: exactly what format passes between them. Vague intermediate outputs are where chains fail, because step two receives something it cannot reliably parse or interpret.

3. THE STATE PROBLEM - each step starts fresh and knows only what it is given. List, for each step, what it needs from earlier steps, and confirm the design passes it explicitly. Assuming the chain remembers something is the single most common chain bug.

4. THE ERROR PROPAGATION - if step one produces something wrong, step two will work on it faithfully and the error compounds. Identify the steps where an error would be most damaging, and what check belongs after them.

5. THE HUMAN CHECKPOINTS - I said whether a person is involved. The most valuable place for one is after any step that makes a decision the rest depends on. Say where.

6. THE PROMPTS - written for each step, each self-contained with the context it needs.

7. THE PARALLEL STEPS - anything that does not depend on the previous step's output and could run independently, then be combined.

8. THE CONSOLIDATION QUESTION - whether any two of these steps should be one. Chains have overhead, and an unnecessary split adds failure points without benefit.

9. THE FAILURE HANDLING - what happens when a step produces unusable output: retry, retry with the error included, fall back, or stop. Say which for each step.

10. IF I WILL RUN THIS MANY TIMES - what to log so failures can be diagnosed, and what to check to know the chain is still working.

11. THE SIMPLER ALTERNATIVE - honestly, whether this needs a chain at all, or whether a better single prompt would do it. Chains are frequently built for problems that were really underspecified prompts.

Help me build a two-pass workflow.

WHAT I AM PRODUCING: [THE OUTPUT]
MY CURRENT SINGLE PROMPT:
"""
[PASTE]
"""
WHAT IS WRONG WITH THE SINGLE-PASS OUTPUT: [THE WEAKNESSES]
WHAT GOOD LOOKS LIKE: [YOUR STANDARD]

Produce:

1. WHY TWO PASSES HELP - a single prompt asks the model to plan, produce and polish simultaneously, and the planning suffers. Separating them usually improves structure most, because the first pass can concentrate on getting the shape right.

2. THE SPLIT - what belongs in each pass. Common and effective splits:
   - Plan, then write
   - Write, then critique, then revise
   - Produce a rough version, then improve against specific criteria
   - Generate options, then select and develop
   Recommend one for my task and say why.

3. PASS ONE - the prompt, focused on getting the substance and structure right without polish. Explicitly telling it not to polish helps, because effort spent on prose in a draft that gets restructured is wasted.

4. THE INTERMEDIATE OUTPUT - what pass one should produce, in what form. If it is a plan, the plan should be specific enough to write from. Vague plans produce the same generic output as no plan.

5. PASS TWO - the prompt, taking pass one's output and improving it against my stated standard. This pass needs the criteria stated explicitly; a general instruction to improve produces superficial editing.

6. THE CRITERIA - my stated weaknesses and standard, turned into checkable criteria for pass two to work against.

7. THE PRESERVE INSTRUCTION - what pass two must not change. Revision passes routinely rewrite things that were fine, and specifics get replaced by generalities. State what to protect.

8. THE CHECKPOINT - whether to look at pass one before running pass two. Usually worth it: a wrong plan corrected in ten seconds saves regenerating everything downstream.

9. THE DIMINISHING RETURNS - a third pass rarely helps and often flattens the output into hedged, generic prose. Say what to watch for.

10. THE SINGLE-PROMPT COMPARISON - run both and compare, because the two-pass version costs more and should be earning it.

11. WHEN ONE PASS IS BETTER - for short outputs, for tasks where coherence matters more than structure, and for anything where the model's first instinct is usually right. Say if that applies here.

Help me process a long document.

THE DOCUMENT: [WHAT IT IS AND ROUGHLY HOW LONG]
WHAT I WANT FROM IT: [THE TASK - summarise, extract, analyse, translate, restructure]
WHY IT DOES NOT FIT: [too long for the context window / quality degrades / it misses things]
WHAT MATTERS MOST: [completeness / accuracy / the overall picture / specific details]

Produce:

1. THE SPLITTING STRATEGY - how to divide it. The split should follow the document's own structure (sections, chapters, topics) rather than arbitrary length, because splits mid-argument produce chunks that cannot be processed meaningfully. Say how to split mine.

2. THE OVERLAP - adjacent chunks should overlap slightly so nothing that spans a boundary is lost. Say how much for my document type.

3. THE CONTEXT PROBLEM - each chunk is processed without knowing what came before. For some tasks this is fine; for others it produces nonsense, because a passage's meaning depends on earlier material. The fix: give each chunk a short summary of the document and what precedes it. Say whether my task needs this.

4. THE APPROACH - two main patterns:
   - MAP-REDUCE: process each chunk independently, then combine the results. Good for extraction and for finding things. Poor for anything requiring an overall judgement.
   - REFINE: process the first chunk, then pass the running result forward with each subsequent chunk. Good for summarisation and for building a cumulative picture. Slower, and errors propagate.
   Recommend one for my task.

5. THE PER-CHUNK PROMPT - written, including the document-level context.

6. THE COMBINATION STEP - how results are merged. This is where quality is usually lost: a summary of summaries loses specifics and flattens emphasis. Say what to preserve explicitly.

7. THE COMPLETENESS CHECK - how to verify nothing was missed. For extraction tasks, a count. For summarisation, checking that each section is represented.

8. THE EMPHASIS PROBLEM - chunked processing treats every part as equally important, so a document with one crucial page and forty routine ones produces a summary that gives them equal weight. Say how to handle this for mine.

9. THE ALTERNATIVE - if the model's context window would actually hold this document, chunking may be unnecessary and harmful. Say whether my stated length genuinely requires it, since context windows have grown and much chunking advice predates that.

10. THE QUALITY DEGRADATION NOTE - even within a large context window, quality can fall for material buried in the middle of a very long input. If I said quality degrades rather than that it does not fit, that is a different problem: say what to do about it.

Help me combine these outputs.

WHAT I HAVE:
"""
[PASTE THE OUTPUTS, LABELLED]
"""
HOW THEY WERE PRODUCED: [several prompts / the same prompt run several times / different models / chunks of a document]
WHAT I WANT: [one combined output / the best of them / a synthesis]
WHAT MATTERS: [completeness / quality / consistency / specific details]

Produce:

1. THE COMBINATION TYPE - what I am actually doing, because each needs a different approach:
   - SELECTION: pick the best one
   - MERGE: combine complementary parts into one
   - SYNTHESIS: produce something new from what they collectively show
   - RECONCILIATION: they disagree and the disagreement must be resolved
   Say which mine is.

2. IF SELECTING - the criteria to judge against, and the warning that a model asked to pick the best tends to favour the longest or the most confident. Say what to specify to prevent that.

3. IF MERGING - the risk is that combination averages toward the generic. The best parts of each output are usually its specifics, and merging tends to keep the structure and lose the detail. The instruction that prevents it: preserve specific examples, figures and phrasings verbatim rather than paraphrasing them into a combined version.

4. THE DUPLICATION - where the outputs say the same thing in different words, which to keep. Usually the more specific version.

5. THE CONTRADICTIONS - where they disagree, do not average. Averaging two contradictory claims produces something neither source supports. Flag each disagreement and either pick one with a reason or present both.

6. THE UNIQUE CONTRIBUTIONS - what each output has that the others do not. These are the parts most likely to be lost in combination and are frequently the most valuable.

7. THE COMBINATION PROMPT - written, with the preservation instructions in place.

8. IF THESE ARE THE SAME PROMPT RUN SEVERAL TIMES - agreement across runs is weak evidence and disagreement is informative. Where the runs differ, that is where the task is underspecified or the model is uncertain. Say what the variation tells me.

9. IF THESE ARE FROM DIFFERENT MODELS - where they agree and where they differ, and what that suggests. Do not assume the more confident one is right.

10. THE STRUCTURE OF THE COMBINED OUTPUT - specified, so the combination has a shape rather than being a concatenation.

11. THE HONEST CHECK - whether combining actually improves on the best single output. Frequently it does not, and picking one is the better answer.

Help me build a research-then-write workflow.

WHAT I AM PRODUCING: [THE FINAL OUTPUT]
WHAT RESEARCH IT NEEDS: [WHAT INFORMATION IS REQUIRED]
WHERE THE INFORMATION COMES FROM: [my own knowledge / documents I have / web search / a database / the model's knowledge]
WHAT GOES WRONG WITH A SINGLE PROMPT: [THE PROBLEM]

Produce:

1. WHY SEPARATING HELPS - asking a model to research and write in one pass produces confident writing built on whatever it happened to recall, with no visibility into what was used. Separating them makes the material inspectable before it becomes prose, which is the entire point.

2. THE RESEARCH STEP - what to gather, in what structure. The output should be a set of specific facts, claims and sources rather than prose, because prose hides which parts are supported.

3. THE SOURCING REQUIREMENT - each item in the research output marked with where it came from: a document I supplied, a search result, or the model's own knowledge. This distinction is essential and is invisible in a combined pass. Model-recalled facts need verification; supplied-document facts need checking against the document.

4. THE VERIFICATION STEP - what I check before writing begins. Specifically: any figure, date, name, citation or claim that the output will rest on. This checkpoint is the whole value of the workflow, and skipping it makes the split pointless.

5. THE FABRICATION WARNING - if the source is the model's own knowledge, citations and specific figures are the highest-risk items and are frequently plausible and wrong. Say what to check and that a reference which does not resolve to a real source means everything else needs scrutiny too.

6. THE GAP IDENTIFICATION - the research step should say what it could not find, rather than filling gaps with plausible material. Write the instruction that produces this.

7. THE WRITING STEP - a prompt that takes the verified research and produces the output, with the instruction to use only what is in the research block and to flag anything it needs that is not there.

8. THE NO-NEW-FACTS RULE - the writing step must not introduce claims that were not in the research. This is the instruction that makes the workflow trustworthy, and it needs stating explicitly because the natural tendency is to fill in.

9. THE PROMPTS - written for each step.

10. IF USING SEARCH OR DOCUMENTS - how to pass the material in, and the instruction to distinguish what the source says from what the model concludes from it.

11. THE HONEST NOTE - this workflow makes errors visible; it does not prevent them. The verification step is done by me, and the workflow only works if I actually do it.

Help me build a multi-perspective review.

WHAT IS BEING REVIEWED: [THE OUTPUT OR WORK]
WHO IT IS FOR: [AUDIENCE]
WHAT COULD GO WRONG WITH IT: [THE RISKS]
WHAT PERSPECTIVES MATTER: [IF YOU KNOW]
HOW MANY PASSES I AM WILLING TO RUN: [NUMBER]

Produce:

1. THE PERSPECTIVES - which viewpoints would find different problems. A single general review finds general problems; specific perspectives find specific ones. For my work, the useful ones might include:
   - The sceptical reader who does not accept the premise
   - The person who has to act on it
   - The person whose interests it affects negatively
   - Someone checking it for accuracy
   - Someone checking it against a standard or requirement
   - A new reader with no context
   Recommend the most useful ones for my stated risks.

2. WHY SEPARATE PASSES - one prompt asking for a comprehensive review produces a shallow pass across everything. Each perspective in its own pass produces depth, because the model is not dividing attention. Say how many passes my case warrants.

3. THE PERSPECTIVE PROMPTS - written for each, with:
   - Who this reviewer is and what they care about
   - What they are looking for specifically
   - The instruction to find problems rather than to assess generally, because models default to approval
   - The instruction to quote the specific passage for each finding

4. THE ADVERSARIAL FRAMING - the most useful review pass is one instructed to find what is wrong rather than to review. 'Identify the three weakest points and why a critic would attack them' produces more than 'review this document'.

5. THE NEW-READER PASS - frequently the most valuable and least used: reviewing as someone with no context, reporting where they would be confused, what they would assume, and what they would not understand. This catches problems the author cannot see.

6. THE CONSOLIDATION - how to combine the findings: grouped by severity rather than by reviewer, with duplicates merged and contradictions between perspectives noted rather than resolved. Where two perspectives disagree, that is a real tension in the work.

7. THE PRIORITISATION - the findings ranked, since a list of thirty comments is not actionable. What determines priority for my stated risks.

8. THE FALSE POSITIVE PROBLEM - adversarial review passes produce some findings that are not real problems. The consolidation step should filter these, and I should be willing to dismiss some.

9. THE REVISION - whether to revise after each pass or after all of them. Usually after all of them, because revising between passes means later reviewers see different material.

10. THE LIMIT - a model reviewing text shares the blind spots of the model that wrote it, if the same one produced both. It catches omissions, inconsistency and unclear passages. It does not reliably catch a wrong premise or a factual error. Say what still needs a person.

Help me decide whether to build a prompt chain.

WHAT I AM TRYING TO DO: [THE TASK]
MY CURRENT APPROACH: [PASTE YOUR PROMPT OR DESCRIBE THE CHAIN YOU ARE CONSIDERING]
WHAT IS NOT WORKING: [THE PROBLEM]
HOW OFTEN I DO THIS: [FREQUENCY]
WHO MAINTAINS IT: [just me / a team / it needs to keep working unattended]

Produce:

1. THE DIAGNOSIS - is the problem actually solved by splitting? Chains solve: too many requirements in one prompt, dependent decisions being made implicitly, outputs too long to stay coherent, and the need for a checkpoint. They do not solve: a vague task, missing context, an underspecified output format, or the model lacking information it needs. Say which mine is.

2. THE SINGLE-PROMPT TEST - what a better single prompt would look like for my task. Try this before building a chain, because a great many chains are built around prompts that were simply underspecified, and the chain inherits the vagueness at every step.

3. THE COSTS OF CHAINING - stated honestly:
   - More steps to run and more to go wrong
   - Each step loses the context of the others
   - Errors compound rather than being caught
   - More expensive in tokens and time
   - Harder to debug when the output is wrong, because the fault could be anywhere
   - Something to maintain

4. THE COHERENCE LOSS - for anything where the parts must hang together (writing, argument, narrative, design), chaining produces output that reads as assembled. Say whether my task suffers from this.

5. THE MAINTENANCE QUESTION - I said who maintains it. A chain that must keep working unattended needs error handling, logging and monitoring, which is a different undertaking from a prompt. Say what that actually involves so the decision is informed.

6. THE FREQUENCY TEST - for a one-off task, a chain is usually not worth building; doing the steps manually is faster than automating them. For something run hundreds of times, the investment pays. Say where mine sits.

7. THE MIDDLE OPTION - a chain run manually, with me moving output between steps. Most of the benefit, none of the infrastructure, and appropriate for anything done occasionally.

8. THE MINIMUM CHAIN - if a chain is warranted, the fewest steps that solve the problem. Chains grow, and each added step is a failure point.

9. THE RECOMMENDATION - better single prompt, manual chain, or built chain, with reasoning.

10. IF THE ANSWER IS A BETTER PROMPT - the rewritten version.

Be willing to recommend against building anything. Most chain problems are prompt problems.