The Challenge Briefing + Scenario Selection
Reviewed by Human · Updated September 11, 2026
Most engineers think a "prompt" is a single message. That belief is exactly why their AI tools work in a demo and collapse the moment a real user does something unexpected.
Everything in Arc 3 was building toward this: you don't write prompts anymore, you design systems. This boss challenge gives you one messy, realistic scenario and asks you to build the whole thing — the layer the user never sees, the prompts they do, the way those prompts hand off to each other, and what happens when the input is garbage. No hand-holding. That's the point.
You'll build a complete system for ONE of three scenarios. Each one breaks in a different, instructive way. Open to see them.
What "complete" actually means here
A complete prompt system is not four good prompts in a folder. It has four load-bearing parts: (1) a **system prompt** that fixes the persona, scope, and non-negotiable rules; (2) **user prompts** that do the actual per-task work; (3) a **chain** — the defined order in which those prompts run and pass information forward; and (4) **error handling** — what the system does when the input is missing, contradictory, or out of scope. Ship three of the four and you don't have a system, you have a prototype that will embarrass you in production.
Your turn
Commit to a scenario now, before you know how hard it'll get. Write a two-line brief: which scenario, and the single failure you most need your system to prevent.
Reflect
The failure you named is the spine of your system prompt. Every rule you write in Module 2 should be traceable back to preventing it.
What Is a Prompt System?
**Prompt system**: A coordinated set of prompts — a persona-fixing system prompt, one or more task prompts, an execution order, and defined failure behavior — engineered to handle a whole class of tasks reliably rather than one task once. The shift from prompt to system is the shift from *getting a good answer* to *guaranteeing a good-enough answer across inputs you can't preview*. A single clever prompt is a lucky shot. A system is a machine that keeps hitting the target when the inputs move. **System prompt**: The persistent instruction layer the end user never edits, which sets identity, scope, and rules for every interaction. Everything you learned about locking down behavior in role-and-persona prompting lives here.
The hardest part isn't the prompts.
In real deployments, most system failures aren't bad prompt wording — they're missing error handling for inputs the designer never imagined. The prompts you'll agonize over in Modules 2–3 are the easy 70%. The chain and edge cases in Module 4 are where systems actually die.
You've written an excellent system prompt and three sharp user prompts, but you haven't defined what happens when a user submits an empty or off-topic input. What do you have?
You've finished this module.
Mark it complete to earn your XP and keep your streak alive.
Progress saved locally · Sign up to earn XP