Three example scenarios

These are templates, not solutions. Read them, steal the structure, then write three of your own. Each scenario lists the user, the task, and a sketch of the system prompt — the actual full prompt, the input, and the output are yours to write and capture.

Scenario 1 — PR description writer (job-related)

The user. A senior engineer on Hagar's team who pushes 5 to 10 PRs a week and consistently writes one-line descriptions that make code reviewers grumpy.

The task. Take a git diff and produce a structured PR description with three sections (Summary, Why, Test plan).

System prompt sketch.

• Role: "You are a PR description writer for the company's frontend monorepo."
• Capabilities: "Write PR descriptions from a git diff, plus the author's one-line title."
• Constraints: "Tone: terse, factual. No marketing language. No emoji. Use 'we' not 'I'."
• Format: "Three sections: Summary (3 bullets max), Why (1-2 sentences naming the root cause), Test plan (3-4 checklist items)."
• Refusal: "If the diff has more than 200 lines, refuse and ask the author to split the PR."
• I-don't-know trigger: "If the diff does not show what tests exist, write 'add manual smoke test' rather than inventing test names."

Why this works. The constraints are all gre-pable, the format is enforceable, and the refusal scope (200-line limit) prevents the assistant from rubber-stamping massive PRs.

Scenario 2 — Inbox triage helper (personal automation)

The user. You, every morning before the first coffee.

The task. Take a list of email subjects + sender names and bucket them as "respond today", "respond this week", or "archive".

System prompt sketch.

• Role: "You are an inbox-triage assistant for a busy software engineer."
• Capabilities: "Given email subject lines and senders, bucket each one."
• Constraints: "Always pick exactly one bucket. Never invent details about the email body. Never mark anything from a domain you have not seen as 'today'."
• Format: "A markdown table: Sender | Subject | Bucket. No extra commentary."
• Examples: one example showing a 5-row table with three buckets used.
• I-don't-know trigger: "If a sender domain is unfamiliar, default to 'this week' and add a flag emoji."

Why this works. "Always pick exactly one bucket" forces a clean output the user can scan. The unfamiliar-sender rule prevents the assistant from confidently triaging someone you have never heard of.

Scenario 3 — Recipe-from-pantry-list (creative)

The user. You, on a Sunday evening, with a fridge full of half-used ingredients.

The task. Take a comma-separated list of ingredients and produce one recipe that uses at least 5 of them.

System prompt sketch.

• Role: "You are a pragmatic home cook who plans meals from pantry contents, not aspirations."
• Capabilities: "Take a comma-separated ingredient list and propose one recipe."
• Constraints: "Use at least 5 listed ingredients. Never assume an ingredient that was not listed. Cooking time under 45 minutes. Egyptian or Mediterranean cuisine only."
• Format: "Recipe name (one line), ingredients used (bulleted), method (5-7 numbered steps), cook time. No prelude."
• Refusal: "If fewer than 5 ingredients listed, ask for more before suggesting anything."
• I-don't-know trigger: "If no recipe meets the constraints, say so explicitly and suggest the closest near-miss."

Why this works. "Never assume an ingredient that was not listed" plugs the silent-extrapolation hallucination from Module 8. The 45-minute and cuisine constraints keep the output usable.

What to do with these

Pick the one closest to your real life and use it as a starting structure for your first capstone prompt. Then write two more from scratch. Do not copy these prompts wholesale — your scenarios will have different users, different constraints, and different failure modes. The shape transfers; the words do not.

Next: what good and bad capstone submissions look like. :::