Combining Techniques
- Describe the four layers of a compound prompt (role, task/purpose, constraints, output spec) and explain why the order matters
- Build a compound prompt incrementally from a bare request to a fully layered brief using the four-layer framework
- Decide when a compound prompt should be executed in a single message versus split across a multi-turn conversation
You've Learned the Techniques One at a Time. Now You Need to Use Them Together.
Most prompting courses teach techniques in isolation — role prompting, constraint setting, format specification, document grounding. The techniques work individually. But intermediate users consistently report the same frustration: they know the techniques but do not know how to combine them into a single coherent prompt without it feeling clunky, over-engineered, or inconsistent.
The goal of this lesson is to demonstrate how the techniques in this track layer into a compound prompt — and why the combination produces results that none of the individual techniques could produce alone. Think of it as the difference between knowing individual cooking techniques and knowing how they interact in a recipe.
The Four Layers of a Compound Prompt
A well-built compound prompt has four layers, in this order:
- Role or context: Who is the AI for this task? What context does it need?
- Task and purpose: What exactly is it producing, and why does it matter?
- Constraints: What limits apply — length, tone, format, what to include, what to exclude?
- Output specification: What does the deliverable look like — structure, format, completeness?
These four layers are not rigid sections you must label. They are the elements your prompt needs to contain, in any natural phrasing. The order matters because each layer provides context that makes the next layer more interpretable — the role anchors the task, the task justifies the constraints, and the constraints shape the output spec.
Building a Compound Prompt: Step by Step
Here is the same task built from a bare request to a fully layered prompt:
Level 0 — Bare request: "Write a LinkedIn post about our product launch."
Level 1 — Task + purpose: "Write a LinkedIn post announcing the launch of our B2B project management software. Goal: generate inbound demo requests from startup founders and operators."
Level 2 — Add role: "You are a B2B copywriter who specializes in straightforward, jargon-free SaaS marketing. Write a LinkedIn post announcing..."
Level 3 — Add constraints: "...Keep it under 250 words. No exclamation points. No bullet points — flowing prose only. Do not use the phrases 'game-changing,' 'revolutionize,' or 'excited to announce.'"
Level 4 — Add output spec: "...End with a question that invites comment rather than a direct CTA link. Write one version."
Level 0 will produce a generic template. Level 4 will produce something close to publishable for a specific brand voice, audience, and purpose.
Why Each Layer Adds Value
Role anchors the output to a perspective and voice. Without it, the model defaults to a generic helpful assistant writing generic content. With it, the output has a specific perspective that shapes word choice, emphasis, and tone throughout.
Purpose gives the model a success criterion to optimize for. "Goal: generate demo requests from startup founders" tells the model what the post needs to accomplish — which changes what it emphasizes, how it structures the hook, and what the call to action sounds like.
Constraints remove defaults you do not want — the formulaic phrases, the exclamation points, the bullet point format that reads as a listicle rather than a thought piece. These negatives are essential in the compound because without them, positive instructions cannot fully override the model's trained defaults.
Output spec resolves final ambiguity about the deliverable. One version or three? With a CTA or without? The output spec closes the remaining interpretive space so the model produces exactly what you need to evaluate, not what it thinks you might want.
When to Split a Prompt
Compound prompts work well for tasks where all the requirements can be held simultaneously. But some tasks benefit from being split across turns:
- When you are unsure about the structure and want the model to propose one before drafting
- When a single prompt would require the model to make many independent decisions simultaneously
- When you want to review an intermediate output before committing to the direction
The split-prompt approach (propose structure in turn 1, draft in turn 2, refine in turn 3) is a compound prompt executed across a multi-turn conversation rather than in a single message. Both work — the choice depends on how much intermediate review the task warrants.
The Full Recipe
The compound prompt formula: [Role] + [Task + Purpose] + [Constraints] + [Output Spec]. Apply in order. Use negatives in the constraints layer to remove defaults. Write the output spec specifically enough that there is only one reasonable interpretation. Review the output against both the explicit requirements and the implied purpose. Refine in the next turn.
This formula is not a template to fill in verbatim — it is a checklist to run mentally before hitting send. You will not always need all four layers. But knowing all four ensures you never leave out the ones that matter.
- The four layers of a compound prompt are role, task + purpose, constraints, and output spec — each provides context that makes the next layer more interpretable, so order matters
- Purpose gives the model a success criterion to optimize against, not just a description of what to write — it changes what the output emphasizes and how it is structured
- Negatives belong in the constraints layer of the compound; without them, positive instructions cannot fully override the model's trained defaults for format, hedging, and phrasing
- The compound prompt formula is a mental checklist, not a rigid template — run it before sending, use all four layers when all four matter, split across turns when intermediate review adds value
- A compound prompt written with all four layers takes roughly 90 seconds more than a bare request — the return is output that is typically ready to use, not ready to restart, and that ratio improves as the task's stakes increase