1 Course position and tonight’s promise

Day 2 builds on your Day 1 safety card. In 60 minutes, you will turn a vague weekly status-update request into a reusable prompt template with clearly marked blanks, a checked sample output, and one recorded revision.

2 What you will learn and why it matters

• Predict why a vague request produces uneven results.
• Build with Role–Task–Context–Format and the eight prompt parts.
• Tell system, user, and assistant messages apart.
• Use examples, constraints, tone, audience, and safe file/image context.
• Compare the same safe request across tools and verify before keeping it.

A stronger prompt does not make a tool truthful. It makes the requested draft and the checks easier to see, improve, and reuse.

3 A familiar real-world situation: predict before you prompt

Fictional sample values: Asha coordinates a volunteer club. She types, “Write my weekly update.” Before reading any output, predict what is missing: audience, confirmed facts, tone, length, headings, and a rule against inventing achievements.

4 Simple explanation, then accurate vocabulary

A prompt is a set of instructions and inputs. A role describes the perspective or job for the response; a task states what to do; context supplies relevant facts; and format says how the result should be arranged. These are useful handles, not magic words.

5 Why vague requests fail

Vague requests force a tool to fill gaps. It may choose a different audience, assume facts, produce an unusable length, or sound confident about an invented detail. That is a specification problem before it is a writing problem.

6 Role–Task–Context–Format formula

Use R–T–C–F as a quick builder: Role = “helpful communications editor”; Task = “draft a weekly status update”; Context = the approved fictional facts below; Format = “four headings, 90 words, plain English.” It is a starting structure, not a promise of accuracy.

Role: Act as a [ROLE] for [AUDIENCE].
Task: Draft a [ARTIFACT] that helps the reader [PURPOSE].
Context: Use only these approved facts: [FACTS / SOURCE NOTES].
Format: Return [HEADINGS / BULLETS / LENGTH / FILE TYPE].
Constraints: Do not invent facts. Mark missing information as [NEEDS CONFIRMATION].
Verification: List factual claims for me to check before I send it.

7 System, user, and assistant messages

A system message is a higher-level instruction that may set behavior or safety boundaries. A user message is the request and supplied input. An assistant message is the tool’s response. Interfaces differ, and a user cannot assume they can view or override every system instruction.

8 Eight parts of a strong prompt

For work that matters, expand R–T–C–F into eight visible parts. Not every tiny request needs every part, but each part gives you a place to diagnose a weak result.

9 Examples, constraints, tone, and audience

A short example can demonstrate layout or voice, but clearly label it as sample text. A constraint is a boundary: “use supplied facts only,” “maximum 90 words,” or “do not give medical, legal, or financial advice.” Tone describes how it should sound; audience describes who needs to understand it.

10 File and image context

A file or image can add context, but it can also contain private data, misleading labels, or text the tool reads incorrectly. Use the minimum safe excerpt, describe what you want checked, and compare the result with the original yourself.

• Check permission and remove names, IDs, account details, hidden comments, and confidential material.
• Use a fictional sample or type the necessary facts when upload is not appropriate.
• Tell the tool what the file or image represents and what it must not infer.
• Verify extracted text, dates, totals, captions, and visual claims against the original.

11 Iterative follow-up prompts

A first draft is a checkpoint, not a finish line. Compare it with the requested facts and format, name one visible mismatch, and ask for a focused revision. Keep the original facts available; a follow-up can otherwise drift from what you approved.

12 Cross-tool comparison

Different tools may follow the same request differently because of their design, settings, available context, and safety rules. Compare safe, non-sensitive outputs using the same prompt and a human checklist; do not assume the longest or most fluent answer is best.

13 Interactive process model: build, inspect, revise

The moving card represents your reusable prompt template; the model-response card represents a tool’s draft; the review gate is your human check; and the final card is the saved portfolio artifact. Simplification: real tools also use internal instructions and technical processing that this picture does not show.

14 Facilitator-led live demonstration: show one realistic failure

Start with the vague sample request. Read the output against the known facts and point to the failure: it claims a record attendance figure that was never supplied. Do not explain private reasoning; narrate visible decisions: missing facts, unsupported claim, and unclear format.

• Choose New chat or its current equivalent and use fictional club facts.
• Run the vague request and underline missing/assumed details.
• Revise with R–T–C–F plus audience, tone, constraints, and verification list.
• Compare before/after against the approved facts and requested four headings.
• Export or save the template with a meaningful name; reopen it.

15 Your reusable prompt template: before and after evidence

Save the after version as “Day 2 — Weekly Update Prompt Template.” Keep the bracketed blanks so you can safely reuse it for another approved task.

16 Learner lab: build your own safe prompt artifact

1. Prepare non-sensitive, approved facts or use the fictional club sample.
2. Predict what a vague request would omit.
3. Run one first attempt; do not treat it as final.
4. Build with R–T–C–F and add audience, tone, constraints, and verification.
5. Check every factual detail against your source and compare the requested format.
6. Revise one mismatch, export/save, reopen, and add a one-line reflection.

17 Behind the scenes, limitations, safety, and verification

• The prompt card represents instructions and permitted context, not every hidden setting in a product.
• The model response is generated wording; it is not a source or proof.
• The verification gate represents your check of facts, links, calculations, permissions, format, and provider terms.
• The exported artifact proves you saved a version, not that it is correct or approved.

18 Common confusion, errors, troubleshooting, and best practices

• Best practice: write a clear outcome before naming a tool.
• Best practice: preserve approved facts separately from draft language.
• Trainer tip: ask, “Which visible prompt part or source changed this decision?”

19 Takeaways

• Vague requests leave the tool to fill important gaps.
• R–T–C–F and the eight parts make a prompt easier to inspect and reuse.
• System, user, and assistant messages have different roles; the assistant reply still needs review.
• Use minimum safe context, verify facts, and make focused revisions.
• Keep a named template, checked sample output, source/checklist, and reflection in your portfolio.

Your Day 2 artifact is complete when you can reopen it and explain one prompt part you added, one fact you checked, and one revision you made.

20 What comes next

Next is Topic 03—Choose the Right Prompt Pattern. Keep your Day 2 template: you will compare patterns for tasks such as summarising, brainstorming, transforming, and checking without losing your safety and verification steps.

• Reopen your named template.
• Keep a fictional sample and its source/checklist.
• Write down one prompt situation that still feels unclear.