Module 01 · Structural Prompt Frameworks
Choosing the Right Framework for the Right Task
Open lesson + course map
On this lesson
Course outline
Module 1 · Structural Prompt Frameworks
Module 2 · Reasoning Patterns
Module 3 · Few-Shot and Example-Driven Prompting
Module 4 · Reusable Instruction Systems
A prompt framework is a budget for clarity. A one-line request is enough for some work; other tasks need RTF, CO-STAR, or a full specification with examples and tests.
By the end, you will have a decision card that maps your recurring tasks to the lightest prompt structure that makes their output reviewable.
// concept
Score Stakes, Complexity, and Reuse
Choose prompt weight on three axes: stakes (cost of an unnoticed error), complexity (inputs and constraints), and reuse (one-off versus repeated). Use this decision tree:
- Can you quickly fix a mistake before anyone else sees it? Use a one-liner.
- Is it routine with a clear role, task, and format? Use RTF.
- Do audience, tone, context, and response shape change the result? Use CO-STAR.
- Will it run repeatedly, feed another process, or face costly edge cases? Use structured fields, examples, refusal rules, and tests. High-stakes output still needs human review.
| Concrete task | Stakes | Complexity | Reuse | Right weight |
|---|---|---|---|---|
| Correct one typo | Low | Low | Once | One-liner |
| Turn meeting notes into five bullets | Low | Low | Occasional | RTF |
| Convert an update into Roman Urdu | Medium | Low | Repeated | RTF |
| Draft Daraz copy from verified facts | Medium | Medium | Repeated | CO-STAR |
| Explain a delivery delay to a UK client | Medium | Medium | Once | CO-STAR |
| Tailor a cover letter using only a real resume | High | Medium | Repeated | CO-STAR plus evidence check |
| Extract fields from inconsistent invoices | High | High | Automated | Full specification plus tests |
| Summarize a public policy for publication | High | High | Published | Full specification, sources, tests, human review |
// concept
See One Task at Every Weight
Use this sample input: “The homepage draft is two days late because product photos arrived late. Send the revised draft on Thursday.”
Bad prompt — under-structured:
Write a professional client update about a delay.The model must guess the reason, date, channel, and tone, so it may add an unapproved promise.
RTF — good for a routine internal draft:
Role: Act as a concise project coordinator.
Task: Rewrite the update below without adding facts:
"The homepage draft is two days late because product photos arrived late.
Send the revised draft on Thursday."
Format: One message of no more than 45 words.A realistic output is: “The homepage draft will be two days late because the product photos arrived later than planned. I will send the revised draft on Thursday.” RTF controls shape, not the relationship.
CO-STAR — good when the client experience matters:
Context: I am a freelance designer updating a repeat UK client.
Objective: Explain a two-day homepage delay and confirm Thursday delivery.
Style: Plain business English; short WhatsApp message.
Tone: Accountable and calm, not defensive or over-apologetic.
Audience: A repeat client who already knows the project.
Response: 35-55 words. Use only these facts: product photos arrived late;
the revised homepage draft will be sent Thursday. Do not invent a time.This preserves the facts while controlling wording. For a one-off message, that is enough.
Full specification — for team reuse: add {delay_reason} and {new_date}, accepted examples, a missing-date rule, and tests for empty, mixed-language, and hostile input. This weight pays off when repeatability or failure handling matters.
// concept
Avoid Both Prompt Extremes
Under-structuring lets the model fill missing facts, tone, or format. Over-structuring buries the instruction, creates conflicting fields, and costs more time than checking a simple output. Start light; move up when a real failure identifies the missing control.
// worked_example
Worked Example
Task: Classify each sample customer message and draft a reply.
Allowed categories: DAMAGED_ITEM, DELIVERY_DELAY, PRODUCT_QUESTION, OTHER.
Source boundary: Use only the message and the policy facts below.
Policy facts: A human must approve replacements. Tracking status is not provided here.
If a needed fact is missing, write "NEEDS HUMAN CHECK"; do not infer it.
Output: A markdown table with message number, category, reply, and human_check.
Sample messages (phone numbers and order IDs removed):
1. "Parcel aya lekin bottle damaged hai. Replacement?"
2. "Three days ho gaye. Tracking kahan hai?"
3. "Is perfume original?"Draft one classified correctly but promised a replacement and said the delayed order would arrive soon. Neither claim appeared in the policy facts. The fix was the source-boundary and missing-fact rule. A realistic revision is: 1 | DAMAGED_ITEM | I can send this for replacement review. | YES and 2 | DELIVERY_DELAY | I do not have tracking status; I will ask the team to check. | YES. Structure made unsupported claims easier to catch; it did not verify reality.
// failure_cases
Failure Cases to Diagnose
5 cases to diagnose
Everything becomes CO-STAR
Six fields for a typo is waste; use a one-liner.
“High stakes” means “long”
Length is not safety. Add source boundaries, tests, and review.
RTF role adds theatre
Replace “world-class genius” with relevant context such as “project coordinator.”
CO-STAR fields conflict
Resolve “warm” versus “no greeting” before running the prompt.
Reuse has no edge cases
Test missing, messy, and hostile inputs before promoting a prompt.
// pakistan_angle
Pakistan Angle
For Pakistani freelancers, a Roman-Urdu WhatsApp reply and formal English email may share facts but need different tone and format. Use RTF for internal translation; use CO-STAR for a Lahore client or overseas customer. Never paste CNIC numbers, phone numbers, bank details, or order IDs into a chat tool.
Free-tier limits, USD-priced plans, mobile data, and load-shedding make oversized prompts costly. Keep the card offline, prepare source text before reconnecting, and reserve full specifications for workflows that justify extra tokens and upload time. Check current official plan pages before relying on a quota.
// hands_on
Hands-On Exercise
5 steps
Build the personal decision card you will pin above your desk.
List eight tasks you actually perform: two writing, two analysis, two client or study, and two repeated workflow tasks.
Score each Low/Medium/High for stakes, complexity, and reuse.
Assign one-liner, RTF, CO-STAR, or full specification using the decision tree.
Pick one task and write both the assigned prompt and a version one weight lighter.
Run both on the same redacted input. Record one difference and whether the heavier prompt earned its cost. Done means your card contains eight justified choices, one side-by-side test, and no private data.
// completion_rubric
Completion Rubric
5 checks — tick as you verify
// sources
Sources
3 official sources — check every claim yourself
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: ““High stakes” means “long”.” The lesson describes it like this: “Length is not safety.” What does the lesson tell you to do about it?