▸ SYSTEMPromptOS← Curriculum
Track 01 · Foundations · Lesson 03
SAMPLE LESSON

Anatomy of a Great Prompt

What you'll be able to do after this

  • ✓Diagnose exactly why a weak prompt is weak — and fix it in under 2 minutes
  • ✓Write any prompt using the 5-block RCTFE structure so the model knows its role, task, constraints, format, and examples
  • ✓Apply a fill-in-the-blank master template to any new job without starting from scratch
  • ✓Decide in 30 seconds whether to add examples (few-shot) or keep it zero-shot — and know why it matters
  • ✓Route structured prompts to the right model: when Claude's precision wins, when Gemini's capacity wins
01

Why “Be More Specific” Is Bad Advice

Most AI advice sounds like this: “write better prompts,” “be more specific,” “give it context.” That advice is technically correct and completely useless. You can't improve something you haven't decomposed.

A prompt isn't one thing — it's five things that the model reads and processes in sequence. When the output is wrong, one of those five things is missing or broken. Once you know which slot is empty, the fix is obvious. Without the framework, you're guessing.

This lesson gives you the five building blocks, shows you what failure looks like without them, and hands you a reusable template you can drop into your Reusable Prompt Library today.

“The model doesn't know what you know. Every missing block is a gap it fills with a plausible guess — which is usually wrong in exactly the subtle way that wastes your time.”

02

The 5 Building Blocks: RCTFE

Every reliable prompt contains these five elements. You won't always use all five — but you should consciously decide which to include and which to skip, not just forget them.

BLOCK
WHAT IT DOES · EXAMPLE
R

Role / Context

Tells the model who it is and what situation it's operating in. Sets the expertise level, perspective, and unstated assumptions that should govern every choice it makes.

e.g. "You are a senior product manager at a B2B SaaS company reviewing a PRD for the first time."

C

Context / Background

The specific situation the model needs to understand before doing any work. Not 'more context' — precise facts that change the output. Audience, constraints, prior decisions.

e.g. "This document is going to a technical team that already knows the problem. Skip the backstory."

T

Task

The single clear thing you want the model to produce. One verb, one deliverable. If your task block has 'and' in it, it's two tasks.

e.g. "Write a 3-bullet executive summary of the key risks and the recommended mitigation for each."

F

Format

The exact structure, length, and shape of the output. The most commonly omitted block — and the most powerful lever. Models default to verbose when format is missing.

e.g. "Output a markdown table with columns: Risk | Severity (H/M/L) | Mitigation | Owner. Max 6 rows."

E

Examples

One or more worked examples showing the model what good output looks like. Optional but high-leverage. Used when format alone can't convey the standard you want.

e.g. "Good row: API rate limits | H | Add retry logic with exponential backoff | Backend team. Bad row: Performance | M | Improve performance | TBD."

The acronym is RCTFE. That's awkward to say aloud, so think of it as a checklist: Role · Context · Task · Format · Examples. Before you send a prompt, scan the list. Any missing block is a coin flip for what you get back.

03

Before / After: See the Difference

Here is the same job — summarize a meeting — written as a weak one-liner and then rebuilt block by block into a prompt that produces consistent, usable output.

WEAK PROMPT — missing 4 of 5 blocks
Summarize this meeting.

What's missing: No role (which expert lens?), no context (who reads this? what do they care about?), no format (bullet list? table? prose?), no examples. The model will produce a generic 3-paragraph text that restates the meeting in order — rarely useful for anything.

STRONG PROMPT — all 5 blocks present
You are a chief of staff who has been in this meeting and is now briefing a stakeholder who was not present. [ROLE] The stakeholder is the VP of Engineering. They care about decisions, blockers, and who owns what — not the discussion that led there. They have 2 minutes. [CONTEXT] Read the transcript below and output a structured summary. [TASK] Format: ## Decisions Made (numbered list — one sentence each, past tense) ## Action Items (table: Owner | Action | Due Date) ## Open Blockers (bulleted — flag any item without a clear owner) ## What Was NOT Resolved (1–3 bullets — things discussed but deferred) Do not include any discussion narrative. Maximum 250 words total. [FORMAT] Example of a good Action Item row: Maria Chen | Send final API contract to Legal for review | 2026-08-01 Example of a bad row: Team | Follow up on API | TBD [EXAMPLE] Transcript: {paste_transcript}

The strong prompt produces a table your VP can scan in 90 seconds. The weak prompt produces a wall of text they'll skip. Same model, same transcript, completely different results — because the structure left nothing to chance.

04

The Master Template

Here is the RCTFE structure as a fill-in-the-blank template. Copy it into your Reusable Prompt Library as prompt-master-template.md. Whenever you need to build a new prompt from scratch, open this file instead of a blank page.

MASTER TEMPLATE — save to prompt-master-template.md
You are {role_and_expertise}. {describe any relevant perspective or stance — e.g. "You are skeptical of scope creep"} Context: {audience for this output} {relevant background facts the model needs — constraints, decisions already made, prior context} {what the audience cares about and what they don't} Task: {one clear verb + one deliverable} {if there is a second deliverable, separate it explicitly rather than joining with "and"} Constraints: - {hard rule 1 — what the model must NOT do} - {hard rule 2} - {optional: word count, tone, or scope boundary} Format: {exact output structure — headings, table columns, list format, or prose length} {if a section is optional, say so} {example of the shape of a good output, even just one row of a table} Examples: (include this block only when format alone can't convey the standard) {a worked example of good output} {optionally: a worked example of bad output, with a note on why it fails} Input: {paste your content here}

The {variables} in curly braces are yours to fill before each run. The comments after each block (what the audience cares about, what NOT to do) are reminders to yourself — delete them when you save a finished prompt. What stays is the structure.

05

When to Add Examples (and When Not To)

The E in RCTFE is optional — but it's the single highest-leverage block when the output standard is hard to describe in words. The decision rule is simple:

Zero-shot (no examples)

  • ◦The output format is fully specifiable in words (e.g. a markdown table with named columns)
  • ◦The task is a standard job the model has seen thousands of times (summarize, translate, classify)
  • ◦You want speed — examples add tokens and latency
  • ◦You're iterating quickly and don't have a worked example yet

Few-shot (1–3 examples)

  • ✓The quality bar is hard to articulate but you know it when you see it (tone, voice, judgment calls)
  • ✓The task involves classification or labeling with non-obvious category boundaries
  • ✓Previous zero-shot runs were consistently off in the same specific way
  • ✓You have a gold-standard example of good output you've already produced

The most useful example you can include is not just a “good” output — it's a good and a bad output side by side, with a one-line note explaining the difference. That contrast teaches the model the boundary you care about more precisely than any description.

Practical rule: Start zero-shot. If the output is consistently wrong in the same direction after two tries, add one example of what you want and one of what you got. That single comparison usually fixes it.

06

Routing: Claude vs Gemini for Structured Prompts

The RCTFE structure works on both models. But they respond differently to the five blocks — and knowing the differences makes your prompts more reliable on the first run.

What you needUse ClaudeUse Gemini
Strict format complianceYes — Claude follows explicit format instructions more reliably; rarely invents extra sectionsSometimes adds unrequested sections or reformats; specify format twice if critical
Few-shot examples (1–3)Yes — highly consistent at matching example patterns, even subtle onesGood for structural patterns; less reliable at matching tone or voice from examples
Long input (50k+ words)Limited — use Gemini for initial intake; hand structured output to ClaudeYes — long-context intake is Gemini's primary strength; process the whole doc in one pass
Judgment-heavy tasks (nuanced role / constraints)Yes — the R and C blocks land better; Claude follows unstated implications of the roleLiteral — give it explicit rules rather than expecting it to infer from context
High output volume (many rows, long tables)Fine for moderate volume; may truncate very long structured outputsYes — handles high-volume structured generation without truncation

The default routing rule for structured prompts: Claude for precision, Gemini for volume. If you need the output to look exactly like your template says, use Claude. If your input is massive and the structure is straightforward, use Gemini. For the most demanding work — large input, precise output — route through both: Gemini to process the raw material, Claude to shape the final result.

For a full routing table across all task types, see the Gemini vs Claude lesson.

Continue Learning

Now build a library of these prompts

The next lesson walks you through setting up a versioned prompt library with 5 ready-to-use templates built on the RCTFE framework — your first compounding AI OS asset.

Next: Build a Reusable Prompt Library →Subscribe for ongoing lessons — $19/mo→