Structuring Effective Prompts

I want to start with something that genuinely surprised me about this lesson — the framing is that prompt structure is about forcing the model to behave. Not guiding it. Forcing it.

Yes, and that framing is correct, which I suspect is why it surprised you.

It surprised me because most people treat prompting like a polite request. 'Could you perhaps, if you don't mind, summarise this document.' And then they're baffled when they get something vague back.

The model is not baffled by your vagueness. It is perfectly happy to match your energy. You gave it nothing to work with, so it produced something that technically addresses your words while meaning almost nothing. That is not a failure on its part.

Right. And the three-part structure — Context, Task, Output Format — is essentially a way of removing that wiggle room. You're not leaving the model room to interpret what you meant. You're telling it exactly what role it's operating in, what you want done, and what the answer should look like when it arrives.

Context is the one people skip most confidently, as though the model has been following their week.

To be fair, context feels redundant when you already know what you're talking about. That's the trap — you assume shared understanding that simply isn't there.

It's not a trap so much as an assumption of telepathy. 'Summarise this for my stakeholders' — which stakeholders, what do they already know, what are they going to do with it, what does 'summarise' mean to you this afternoon? These are not difficult questions. They are simply questions people find inconvenient to answer.

Although — and I think this is worth saying — the Output Format section is doing more work than it gets credit for. Specifying a JSON schema or a numbered list isn't just tidiness. It's actually the thing that makes the output usable in a pipeline, or parseable by another system. It's engineering, not aesthetics.

Correct. And it also forces clarity of thinking upstream. If you cannot specify what the output should look like, you do not yet know what you actually want.

That's a good point, and I'll grant you that freely, but I'd push back on the implication that unclear thinking is always laziness. Sometimes you're genuinely exploring. You don't know what you want yet. And a rigid three-part structure can actually work against that.

This lesson is titled Intermediate. If you are still in the 'I don't know what I want' phase, you may be in the wrong lesson.

Or the lesson could acknowledge that the structure is a tool for specific situations rather than a universal law. A well-structured prompt for extracting data from a document is not the same problem as using a model to help you think through an ambiguous question. Treating the framework as always-applicable is how you get people rigidly following templates and wondering why the outputs still feel hollow.

That is... a reasonable distinction, and I won't pretend otherwise. The lesson is about structured, technical prompting. People who apply it to open-ended exploration will get odd results, though I maintain that is a reading comprehension issue more than a framework failure.

We'll call that a partial concession and move on. The actual skill here is developing the habit of asking yourself three things before you type anything: what context does this model need, what am I actually asking it to do, and what should the answer look like. That's not a template. That's a thinking discipline.