🌱 The minimum viable prompt
The smallest version that works. Before you write any rule, write the irreducible core — identity and one contract only —
and defines a concrete test that proves it works. This is the prompt-v0: the starting point for your lab.
Detailed content
Why start small
Every beginner has the same impulse: open a blank file and dump all the rules at once — format, tone, safety, edge cases, all before it has run even once. That impulse is the number one enemy of a robust prompt. The entire Track is about resisting it.
🧭 The principle
The best system prompts of 2026 aren't the longest—they're the most consolidated and justified. They reached a lean state after to grow and prune, not before. You can't prune what doesn't exist yet. That's why we start with the smallest possible core and let the prompt reveal what it really needs — guided by failing tests, not assumptions.
- •Every rule you write "just in case" is a rule no one has tested.
- •A short prompt is easy to read, easy to debug, and easy to explain.
- •If you can’t prove a behavior with a test, you don’t control it.
Robust because it's simple, not despite that
A lean prompt has less surface area for internal conflicts, fewer contradictory rules, and fewer lines competing for the model’s attention. Simplicity isn’t a compromise—it’s the source of robustness.
Identity + 1 contract — the irreducible core
The minimum core has exactly two parts: who the agent is (identity) and what it commits to do (a contract). Everything else — format, refusals, edge cases — is optional in v0. If you remove either of these two parts, the agent stops making sense. That's "irreducible."
🪪 Identity
One sentence: who is and, when useful, what context it operates in. It’s the anchor that keeps the model from drifting away from its persona.
You are a triage assistant for a support inbox.
📄 1 contract
A observable behavior promise: what it delivers, in what format, with what guarantee. One contract, not five.
For each message, output exactly one label: urgent, normal, or spam.
What makes something a "contract"
A contract is a statement that can be verified: “output has exactly one label out of three.” Compare that with a vague rule (“be helpful and responsible”) — that can't be tested, so it's not a contract; it's decoration. The practical rule: if you can’t write a test that fails when the contract is broken, the contract still isn’t well defined.
The danger of anticipating
Anticipating means writing a rule for a problem that hasn't happened yet. It seems prudent, but it creates debt: every preemptive rule is a rule without testing or real-world context, and often wrong — because you guessed the problem instead of observing it.
✓ React to a real problem
- •It ran, failed, you saw the failure → write the rule
- •Each rule starts with a test that justifies it
- •The prompt grows in response to the problems that exist
- •You always know why each line is there
✗ Anticipate an imaginary problem
- •"Better warn it never to use emoji" — before seeing one
- •Untested rules accumulate and contradict each other
- •The prompt bloats around fears, not facts
- •No one remembers why half the lines are there
⚠️ The symptom of the premature prompt
You open a prompt and find rules for cases the product has never encountered, prohibitions against things the model has never tried to do, and instructions no one can explain. This is the bloated prompt — and it will be the villain of the Trail. The antidote starts here: start minimal.
Define "works"—a concrete test before writing more
"Works" isn't a feeling. Before adding the next line to the prompt, you need one concrete criterion that says, unambiguously, whether v0 meets the contract. This criterion is your first test — and it comes before of any extra rule.
From contract to test, in 3 steps
Take the contract and make it observable
Contract: "output is exactly one of three labels." Observable: given an input, the output must be urgent, normal or spam — nothing else.
Choose 1 concrete case with an expected response
Input: "Server is down, clients have no access right now!" → expected: urgent. One clear-cut real case is enough for v0.
Define pass/fail objectively
Passes if the output is exactly urgent. Any extra explanation, label outside the list, or additional text = failure. A binary criterion, not “it turned out well.”
The test is the definition of done
While the test passes, v0 is ready—you don't touch it. You only go back to editing the prompt when a new test failure. That’s how growth stays honest (Module 4.2).
Guided example: the MVP of a simple agent
Let’s build a prompt-v0 end to end for our inbox triage agent.
Notice how it has just identity + 1 contract — no extra formatting rules, no preemptive refusal. It's the smallest version that works.
You are a triage assistant for a support inbox.
Contract:
For each incoming message, output exactly one label on a single line —
one of: urgent | normal | spam. Output nothing else.Why this is a good v0
- •Clear identity: one sentence anchors the persona and the domain.
- •A verifiable contract: "exactly one label, nothing else" — immediately testable.
- •Zero anticipation: nothing about tone, emoji, language, or edge cases—they only come in if a test calls for them.
INPUT: "Servidor caiu, clientes sem acesso agora!"
EXPECTED: urgent
PASS IF: output == "urgent" (exato, sem texto adicional)Run before improving
Paste the prompt-v0 in a playground, run the test-01. Did it pass? Stop. Resist the urge to "make a little improvement." Did it fail? Now you have a problem real to fix — and that’s exactly what Module 4.2 is about.
Deliverable: prompt-v0 + 1 test
The result of this module is the your lab’s starting point: two small files, versioned in git, that will be the first entry in your "evolution repo." Everything in the upcoming lessons will be a diff on these files.
📦 What to deliver
git commit -m "prompt-v0: triagem de inbox + test-01"✓ Good deliverable
- •Fits on screen — you can read the entire prompt at once
- •The test passes when you run it
- •You can explain each line in one sentence
✗ Signs that you anticipated
- •There are already tone/language/emoji rules in v0
- •More than one contract competing for attention
- •No tests — just “I thought it was good”
📌 Module Summary
prompt-v0 + 1 test, committed: the lab's starting point.Next: Module 4.2
Diff-based evolution and consolidation rounds — grow out of real need (not anticipation) and consolidate before bloating.