Learning objectives. Apply a practical, repeatable prompt structure; judge when each part of that structure is necessary and when it's overkill; avoid the common failure of over-engineering a simple request; and use HPC-10 as a scaling tool rather than a checklist you fill in every time regardless of the task.

Why this matters

The previous module established what belongs in a well-formed request. This one answers a question that trips people up constantly: do I need all of that, every time? The honest answer is no — and knowing when to skip most of it is as important a skill as knowing how to include it.

Plain-English explanation

Think of a simple, practical structure:

Goal → Context → Task → Constraints → Inputs → Output → Evaluation

For a quick, low-stakes request, most of this collapses to nothing — you just ask. For a request that matters, that you'll reuse, or where getting it wrong is costly, each part earns its place. The skill is judging which situation you're in, not applying the full structure by rote.

Core lesson

PLAIN ENGLISH — the structure, worked through plainly

Goal — why this request exists (the objective from Module 2)
Context — the background the AI needs about your specific situation
Task — the concrete ask
Constraints — rules, exclusions, boundaries
Inputs — the actual material to work from (a document, data, a draft)
Output — the shape you want back
Evaluation — how you'll judge whether it's good

A one-off, low-stakes question ("what's a polite way to say no to a meeting?") needs almost none of this — a task and maybe a tone constraint is plenty. A client-facing deliverable, a repeated weekly report, or anything where a wrong answer is expensive deserves the full structure, because the cost of ambiguity scales with how much is riding on the result.

PRACTITIONER — the over-engineering trap

A surprisingly common failure, once people learn structured prompt engineering, is applying the full seven-part structure to a two-minute task — "rewrite this sentence to be friendlier" does not need a stated objective, three constraints, and a success metric. This wastes your time and, per Module 5's context research, can actually dilute the AI's attention on what matters, because you've buried a simple instruction inside unnecessary scaffolding. Match the structure's weight to the task's stakes and repeatability, not to how sophisticated you want to look.

A practical rule of thumb: if you'll use this exact request only once and a wrong answer costs you nothing but re-asking, keep it to a sentence or two. If you'll reuse it, if it's client-facing, or if a bad result is costly to catch, use the full structure — and consider saving it as a template (the Prompt Library later in this course is built exactly for this).

ADVANCED — structure as a schema, not a script

Treat the seven-part structure the way a developer treats a schema: it defines the slots that might need filling, not a script you read aloud every time. OpenAI's own documented prompt structure — Identity → Instructions → Examples → Context, with context placed last, closest to what it needs to act on — is a close cousin of this same idea, ordered slightly differently for their models' behaviour. The lesson generalises: the existence of a slot doesn't obligate you to fill it if it's empty for this task. An empty Constraints slot is a legitimate answer, not a gap.

Beginner example

Low-stakes, no structure needed: "Give me three subject line options for a newsletter about our new opening hours."

Higher-stakes, full structure earns its place: "Goal: I need this Facebook post to bring people into the shop this weekend, not just get likes. Context: independent bookshop, small local audience, we're running a rare 20%-off weekend. Task: write the post. Constraints: under 80 words, warm and low-pressure tone, no exclamation-mark overload. Output: just the post text, no explanation. Evaluation: would a regular customer feel genuinely invited, not sold to?"

Business example

An operations manager at a logistics firm builds two prompt habits, deliberately different in weight. For internal one-off questions ("what's a reasonable way to phrase a delay notice?") she asks directly, no structure. For the monthly client-facing capacity report — reused, client-visible, and costly if wrong — she uses the full structure, saved as a template with the current month's figures dropped into the Inputs slot each time. The distinction isn't laziness on the first one; it's correctly calibrated effort.

Practical exercise

Take five AI requests you'd plausibly make this week. For each, decide: does this need the full seven-part structure, a partial version, or just a direct ask? Write out the two that need the fullest treatment using the complete structure, and leave the rest as plain requests. Notice how the decision itself gets faster with practice.

Common mistakes

Applying the full structure to trivial requests, wasting time and diluting the actual instruction.
Applying no structure at all to something client-facing or repeated, and accepting inconsistent results as normal.
Treating the seven parts as a rigid script rather than a set of slots to fill only where they add real information.
Forgetting Evaluation — the part most often skipped, and the one Module 11 shows is usually where reliability actually breaks down.

Expert insight

The mark of someone who has actually internalised prompt structure isn't that they always use it — it's that they can tell, in about two seconds, whether a given request needs it. That judgement, not the structure itself, is the actual skill this module is teaching.

Knowledge check

Name the seven parts of the Goal→Context→Task→Constraints→Inputs→Output→Evaluation structure.
Give an example of a request that needs almost none of this structure, and one that needs all of it.
Why can over-applying structure to a simple task make the result worse, not just slower to write?
What does it mean to treat the structure as "a schema, not a script"?
Which part of the structure is most often skipped, and why does that matter later in the course?

Module summary

A practical prompt structure — Goal, Context, Task, Constraints, Inputs, Output, Evaluation — gives you slots to fill when a request is worth the effort, and permission to skip most of them when it isn't. The skill is judging which situation you're in, and matching your effort to the task's stakes and repeatability rather than applying maximum structure by default.

Further exploration

OpenAI, Prompt Engineering developer guide — the Identity→Instructions→Examples→Context ordering referenced above, and a useful comparison point for how a specific vendor operationalises the same underlying idea.

Anatomy of an Effective Prompt