How to write a prompt that doesn't fall apart

Most prompts fail in the middle. You get something back, it's 70% of what you wanted, and you spend the next ten minutes in back-and-forth trying to fix it.

Here's a four-part structure that cuts most of that out.

The four parts

Context — Who you are, what you're working on, what matters here.

Task — The specific thing you need.

Format — What the output should look like.

Constraints — What it must not do, include, or assume.

None of these are mandatory. But the more of them you skip, the more the model fills in those gaps with its own assumptions — and those assumptions are usually wrong.

Context

Context is the part people skip most often. It's not throat-clearing. It tells the model what situation it's solving for.

Bad: "Write a project update."

Better: "I'm a solo founder. I need to send a weekly update to three investors who are busy and don't read long emails. This week we hit 200 users and ran into a Stripe bug that delayed payouts by two days."

The second version tells the model who's reading, what they care about, and what actually happened. The output will be significantly different.

Task

The task is the specific ask. Keep it to one thing. If you need two things, write two prompts.

Bad: "Summarize this and make it shorter and also add a conclusion."

Better: "Summarize this in three bullet points, each under 20 words."

Specific asks get specific outputs. Vague asks get vague outputs.

Format

Tell the model exactly how you want the output structured.

• Bullets vs. prose
• Length (word count, number of items)
• Sections and headers
• Tone (conversational, formal, blunt)

If you don't specify, the model will choose. It'll usually choose "a few paragraphs with a friendly intro."

Constraints

Constraints are what the model must not do. They're surprisingly powerful.

• "Don't use the word 'leverage'."
• "Don't include caveats or disclaimers."
• "Don't invent information. If you don't know, say so."
• "Don't start with a compliment about my question."

Negative constraints are often more effective than positive instructions because they're unambiguous. The model can't wiggle out of them.

Putting it together

Before: "Write me an email to a client about our project delay."

After: "Context: I'm a freelance developer. My client runs a small e-commerce store. Their site launch is delayed by one week because of a third-party shipping API issue I couldn't have predicted.

Task: Write a one-paragraph email apologizing for the delay and explaining the cause.

Format: Under 100 words, plain language, no jargon.

Constraints: Don't over-apologize. Don't promise anything I haven't already committed to."

You can feel the difference. The second prompt has a much narrower solution space. That's what you're going for.

A quick test

Read your prompt and ask: could ten different people interpret this ten different ways?

If yes, the model will produce ten different outputs — none of them exactly right. Narrow it until the answer is no.