Phase 0 · Foundations
Prompt lab
By the end, you'll be able to…
- Fix a vague prompt so it produces a usable answer first time
- Add the context and format constraints a prompt needs to be reliable
- Iterate on a mediocre answer instead of starting from scratch
Why it matters
You've learned how models work, how to prompt, and how to stay safe. This is where you put it together by doing. Four graded exercises take you from a broken prompt to a good one, with a model answer to check yourself against each time. Attempt each one before you peek; the learning is in the attempt, not the answer.
How to use this lab
Four exercises, each the same shape: a briefing, a broken or missing prompt, and your job: write a better one and actually run it in a tool. Then, and only then, open the model answer to compare. There's no single correct prompt; the model answers show one strong version and explain what makes it work, so you can judge your own against the same standard.
Keep to the Phase 0 privacy rules throughout: practise on your own low-stakes material or on the Fernway sample files, never on confidential or personal data. Everything here uses the Fernway meeting notes so you can follow along even without your own material to hand.
A quick reminder of the framework you're applying, from the prompting lesson: role, task, context, format, plus be specific, and show an example where tone matters.
Exercise 1: Fix a vague prompt
Briefing. A colleague wants to announce that Fernway is moving the whole team onto a new expenses form by the end of July (that's a real action from the meeting notes). They typed this:
Write something about the new expenses form.
Your task. That's a classic vague prompt: no audience, no facts, no length, no format, so it can only produce filler. Rewrite it. Before you look, ask: who's it for, what exactly must it say, how long, in what shape? Write your version and run it.
When you've attempted it, compare:
You're writing a short internal announcement email to the Fernway team. We're moving everyone onto the new online expenses form, and everyone must be using it by the end of July, with no more emailing receipts. Keep it friendly and brief: a subject line plus about 80 words. End with a clear next step telling people where to find the form and who to ask for help.
Why this works: It supplies all four missing pieces: role (an internal announcement, friendly tone), task (announce the switch and the deadline), context (the specific change and why), and format (a short email with a subject line and a clear next step).
How to grade yourself. Full marks if your prompt named the audience, stated the deadline, gave a length, and asked for a specific format. Half marks if you added detail but left the tool guessing on one of those. The tell of a good prompt: the answer comes back nearly ready to send.
Exercise 2: Add context to a context-free prompt
Briefing. From the notes: customers keep saying they log an issue and never hear back, and it turns out the website contact form has been sending to an old inbox nobody checks. Someone wants help drafting a short internal note to the team explaining the problem. They typed:
Write a note explaining the problem.
Your task. The task is clear but the tool has no idea what problem; it'll invent one. Add the context: what's actually happening, who the note is for, what you want people to take away. Write and run your version.
Then compare:
Write a short internal note to the Fernway operations team. The situation: we've discovered our website contact form has been sending customer messages to an old inbox no one monitors, which is why some customers report logging an issue and never hearing back. I want the team to understand what happened, that we're fixing where the form sends to, and that we'll review the unanswered messages. Keep it calm and factual, about 100 words, no blame. Don't invent any details I haven't given you.
Why this works: It hands the model the actual situation instead of making it guess, names the audience, sets the tone, and adds the guardrail 'don't invent details' so the tool sticks to the facts given.
How to grade yourself. Full marks if the tool could write a note you'd actually send because you gave it the real situation. If your answer still had "[describe the problem]" gaps, you left the context out; that's the whole lesson of this exercise.
Exercise 3: Design a prompt with format constraints
Briefing. You want to turn the whole messy meeting into something usable: a quick summary plus a clean, sortable list of who owes what. This is where format does the heavy lifting.
Your task. Write a prompt that specifies the exact output shape, not just "summarise the notes" but the precise structure you want back, including how to handle the actions that have no owner. Run it against the Fernway meeting notes.
Then compare:
From the meeting notes below, produce two things. First, a summary of no more than four sentences that a manager could read in thirty seconds. Second, a table of every action item with three columns: Action, Owner, Due date. If an action has no owner in the notes, put 'UNASSIGNED' in the Owner column rather than leaving it blank or guessing. Don't add any actions that aren't in the notes. Notes: [paste the Fernway meeting notes].
Why this works: It defines the output precisely: a length-limited summary, then a table with named columns, plus an explicit rule for the awkward edge case (unassigned actions) so nothing is silently dropped.
How to grade yourself. Full marks if you specified the structure and handled the edge case (the unassigned actions; there are two in the notes). A good format prompt leaves the tool no room to freestyle: you should be able to predict the shape of the answer before you read it.
Exercise 4: Iterate on a mediocre output
Briefing. You ran a prompt asking for a customer-facing apology about the missed support issues, and got back something technically fine but too long, too corporate, and missing the specific promise to fix it this week. A beginner deletes it and starts over. You won't; you'll iterate in the same chat, where the tool can still see its own draft.
Your task. Without rewriting the whole request, write the follow-up message that steers the existing draft to where you want it. Be specific about what to change and what to keep. Run it on a draft you generated in Exercise 2 or a fresh one.
Then compare:
Good, but three changes. Cut it to about 90 words. Make the tone warmer and less corporate, write it like a real person apologising, not a press release. And add a clear sentence promising we'll resolve their specific issue this week. Keep the opening apology, that part's right.
Why this works: It gives concrete, itemised feedback (shorter, warmer, add the specific promise) while explicitly telling the model what to preserve, so iteration improves the draft instead of trading one problem for another.
How to grade yourself. Full marks if your follow-up named specific changes and what to keep, and you did it as a follow-up rather than a fresh prompt. The skill here is treating the first answer as a draft to direct, not a final verdict to accept or reject.
Try it now
Common mistakes
- Peeking before attempting. The model answers only teach you if you've already tried. Write yours first; comparing a real attempt is where the learning is.
- Treating the model answer as the only right one. It's one strong version, not the version. If yours gets an equally usable result by a different route, that's a pass.
- Skipping the run. Reading the prompts isn't the exercise; running them in a real tool and reading what comes back is. Do it.
- Over-trusting the output because your prompt was good. A great prompt gives you a fluent, well-shaped answer, but for anything with facts, figures or a customer on the other end, apply the verification habit before you use it. Better prompting improves the writing, not the truthfulness.
Keeping current
The prompting skills you've drilled here are durable and will carry across tools and years. What shifts is what tools accept as input and the odd model-specific behaviour, so when you want the current best practice for a particular tool, check its official guidance, such as OpenAI's prompt engineering guide. This lesson was verified on 13 July 2026. Next stop, the Foundations checkpoint.