Methodology · Prompt Engineeringprovenpartial

Structured Prompt Construction

also known as CO-STAR, component-based prompting, prompt scaffolding

Applies to: llm-appagentcoding-agentextraction-task

Tags: prompt-engineeringstructuretemplates

Build a prompt from named parts instead of one blob of text. Name the role, the context, the task, the examples, and the exact output format, and wrap each part in a tag so the model can tell them apart. A prompt with labelled parts is easier to read, test, and fix than a wall of instructions, and it is far easier to change one part without breaking the rest.

Methodology process overview

flowchart TD task[Task definition] --> role[Name the role] role --> ctx[State context + constraints] ctx --> ex[Show 2-3 examples] ex --> fmt[Pin the output format] fmt --> tags[Wrap each part in tags] tags --> reason[Ask for reasoning before answer] reason --> out[Slotted prompt]

Intent. Compose a prompt from explicit, labelled slots so each part can be read, tested, and changed on its own.

When to apply. Use this when a prompt is doing real work and has grown past a sentence or two. It pays off most when output format matters, when several people edit the same prompt, or when the same prompt must run on varied inputs. Don't apply it to a trivial one-line ask; that does not need slots.

Example scenario

An analyst needs a prompt that reads a vendor contract and returns renewal date, notice period, and auto-renew flag as JSON for a dashboard. The first version was one long paragraph of instructions; the model kept returning prose with the JSON buried inside. They rebuilt it with slots. Role: 'You are a contracts analyst.' Context: which clauses to read and which jurisdictions count. Task: extract the three fields. Examples: two contracts with their exact JSON answers. Output format: a fenced JSON object with three named keys, wrapped in an answer tag. They asked the model to note the clause it used inside a separate reasoning tag before the answer. The slotted prompt returned clean, parseable JSON on every test contract, and when the dashboard later needed a fourth field, they edited only the task and example slots without touching the rest.

Inputs

Task definition — What the prompt must accomplish, stated plainly enough to put in one slot.
Context and constraints — The background, audience, and rules the model needs but should not have to guess.
Two or three examples — Worked input-output pairs that show the format and tone better than instructions can.
Output contract — The exact shape the downstream code or reader expects, ideally a schema.

Outputs

Slotted prompt — A prompt split into labelled, tagged sections: role, context, task, examples, output format.
Reusable template — The structure left behind, ready to be re-filled for the next similar task.

Steps (6)

Name the role
Open with a one-line role that frames the task, for example a contracts analyst or a senior reviewer.
State the task and context
Put the task in its own slot and the background, audience, and constraints in another. Do not mix them.
Show two or three examples
Give worked input-output pairs. Examples teach format and tone faster than prose rules.
usesChain of Thought
Pin the output format
State the exact output shape the downstream consumer needs, as a schema where possible.
usesStructured Output
Wrap each part in tags
Wrap role, context, task, examples, and output in named tags so the model and any tooling can tell the parts apart.
Ask for reasoning before the answer
When the task needs thought, request the reasoning in a separate tag that comes before the final, parseable answer.