Back to library

Prompt Chaining

A single prompt handles a single task cleanly. When a task has multiple steps — each requiring different reasoning, format, or context — chaining is the right pattern. This skill designs prompt chains for common PM workflows, defines the data contract between each step, and handles the failure modes that make chains brittle.

---

Context

When to chain vs. when to use a single prompt:
Use a single prompt when...Use a chain when...
The task has one clear outputThe output of step 1 is the input for step 2
Reasoning and output are the same typeDifferent steps require different reasoning modes
The task is short enough to fit in one context windowVolume of input/output exceeds one window
You want speedYou need quality at each stage
The core rule: Each link in the chain should do exactly one thing. If you find yourself writing "and then" inside a single prompt, that's a sign it should be two steps.

---

Step 1 — Map the workflow

Decompose the task into atomic steps with single action verbs (extract, classify, score, rewrite, summarise, evaluate). Maximum chain length: 5 steps.

Common patterns: Research synthesis chain, Feature brief chain, Weekly signal digest chain.

Step 2 — Define the data contract between steps

For every step transition: output type and format with example, input requirement, and handling for malformed or empty input.

Step 3 — Write each prompt in the chain

Each prompt must: include input format from previous step, validate input before processing, surface errors explicitly with "CHAIN ERROR" output. Final step produces human-readable output; intermediate steps produce structured data.

Step 4 — Define chain-level error handling

Step-level failure stops the chain and reports to user. Cascading failure prevention via human checkpoints at ambiguous steps. Partial chain execution saves last completed step's output.

Step 5 — Build the chain runner

Complete run guide with all prompts in copyable blocks, expected outputs, checkpoints, error handling, and automation notes.

Step 6 — Test the full chain

Three test inputs: clean input, noisy input, edge case. Document results and known limitations.

Quality check before delivering

Every step has exactly one action verb — no "and" steps
Data contracts are defined for every step transition
Each prompt validates its input before processing
CHAIN ERROR outputs are defined and consistent
Checkpoints are placed before irreversible actions
Chain length is ≤ 5 steps
Suggested next step: If you want to automate this chain, the data contracts in this document are the spec your automation engineer needs to build it in n8n, Make, or as a Claude Project.