Prompt Engineering Mastery

Course Content

Prompt Engineering Mastery

6 sections · 32 lessons

What are some best practices for writing good prompts?


What you need to know

Most prompt failures come from missing information, not bad wording. The model fills every gap with its own default. The practices below close those gaps.

The core practices

  1. Be explicit about the goal and audience. "Summarise for a non-technical manager in 3 bullets" beats "summarise".
  2. Give the reason for a rule. "Keep it under 60 words because it shows on a phone card" lets the model make sensible trade-offs; a bare "60 words" does not.
  3. Separate instructions from data. Wrap documents, tickets or user text in tags such as <clause> or <ticket>. The model then knows what to act on and what to read.
  4. Specify the output format. For machine-read output, use the provider's JSON-schema mode rather than only asking politely.
  5. Define the fallback. "If the clause has no deadline, write none stated." Without it, the model invents one.
  6. Say what to do, not only what to avoid. "Write in plain English" works better than "don't use jargon, don't be verbose, don't...". A long list of "never" can anchor the model on the thing you banned.
  7. Use normal volume. CRITICAL and MUST in capitals made older models listen; current models over-apply them and become rigid. Save emphasis for the one rule that tests show is ignored.
  8. Place long documents first. With long inputs, put the document at the top and the question at the end; for very long contexts, restating the key instruction after the document helps.
  9. Decompose big jobs into steps or separate calls, and test each.
  10. Version and test every change against the same cases, one change at a time.

Practices that are now outdated

  • "Think step by step" on reasoning models — they already reason; use the effort setting.
  • Prefilling the answer (starting the assistant turn with {) — the newest Claude models reject a prefilled assistant turn; use structured outputs.
  • Threats, tips and bribes ("I'll tip $200") — no reliable effect on current models.

A real-life example

A legal-clause summariser returns inconsistent output. The original prompt:

Text
Summarise the following clause. DO NOT give legal advice!!! Be concise.The supplier shall remit all invoiced amounts within thirty (30) days ofreceipt, failing which interest shall accrue at 1.5% per month...

Output varies from one line to three paragraphs, and sometimes says "you should negotiate this", which is legal advice. The rewritten prompt:

Text
Summarise the clause for an account manager who is not a lawyer. Theyuse your summary to decide whether to escalate to Legal.<clause>The supplier shall remit all invoiced amounts within thirty (30) days ofreceipt, failing which interest shall accrue at 1.5% per month...</clause>Return exactly three lines:Obligation: ...Deadline: ... (write "none stated" if absent)Penalty: ... (write "none stated" if absent)Describe what the clause says; do not recommend actions.

The output is now three fixed lines — "Deadline: 30 days from receiving the invoice", "Penalty: 1.5% interest per month" — and on a 60-clause test set the "advice" failure drops from 9 cases to 0.

Follow-up questions to expect

  • "XML tags or Markdown headings for structure?" — Either works if consistent. Tags are clearer for wrapping long, untrusted content because the boundary is unambiguous.
  • "How long should a prompt be?" — As long as the context requires and no longer. Every line should be something the model could not know on its own.
  • "How do you debug a bad prompt?" — Collect failing cases, find the pattern, fix the missing information for that pattern, and re-run the full test set to catch regressions.