🚀 Your first prompt: the Minimum Viable
Enough theory — let’s get hands-on. You won’t write 300 lines. You’ll put together a Minimum Viable Prompt (MVP): five little blocks pasted together, run right away, and expanded only when something actually goes wrong. By the end of this module, you’ll have a complete system prompt, assembled with your own hands from the block library.
Detailed content
What the Minimum Viable Prompt is
The number one mistake beginners make when writing a system prompt is the same: dump everything all at once. Three hundred lines of “always do this,” “never do that,” “remember to,” “it’s very important that.” The result? A bloated prompt, full of rules the model already followed on its own, impossible to debug when something goes wrong. The PMV does the opposite: starts small, runs, and grows only under real pressure.
🚀 The idea in one sentence
The Minimum Viable Prompt is the smallest system prompt that still works for you — five little blocks, no frills — built to run today. It isn't the final prompt; it's the starting point you'll evolve with evidence, not guesswork.
The golden rule comes straight from the method: "Don’t start with 300 lines. Start with 5 blocks." Run it. Only add a block when bad behavior real appear — and add it with a reason and a test.
What it is
A lean system prompt made up of five ready-to-use blocks— identity, tone, tools, safety e loop — copied from the library, with the {spaces} filled in for your case. It’s the "car in motion" version of the prompt: nothing fancy, but it gets out of the garage.
Why start this way
Because a small prompt is a prompt you understands. When the AI does something strange, with an MVP you know exactly where to look — there are five blocks, not three hundred lines. And because most of the "rules" people write are wasted effort: the model already does those things. Starting small forces you to write only what actually changes behavior.
The 5 PMV blocks
The Minimum Viable Prompt has exactly five parts, each with a job. Look at the diagram above: on the left, the five separate parts; on the right, stacked together in a single prompt. See what each one does—and why these five, no more and no less.
1. <identidade> — who it is, where it is, and what it’s for
The opening block. Without it, the AI doesn't know what role it's playing.
Who/where/when plus the objective in a sentence. “You are X, role Y, operating in Z. Your goal is W.” It’s the first line of the system prompt and the one that most shapes everything that follows.
2. <tone> — how it sounds + honesty
The block with the highest ROI. Few words, big impact.
Conciseness (respond at the shortest length that solves the problem) plus a rule about honesty (truth over flattery; when wrong, own it). This block alone already eliminates half the answers that make you angry.
3. <ferramentas> — only what exists, with a trigger
Optional: only if your AI uses tools (searching, running code, etc.).
For each tool: when use (trigger), the prerequisite, and the exclusion. Never list a tool that doesn't exist — it's the fastest way to make AI invent powers it doesn't have.
4. <security> — the handful of NEVERs, with reasons
The real limitations—few, and each with a reason.
Not a wall of generic prohibitions, but the few “never” rules that matter for your case — each with the reason why. State the principle, not the mechanics. "Never give specific medical advice" is worth more than ten vague rules.
5. <loop> — ground → … → narrate
Optional: only if your AI is an agent (executes steps, uses tools in sequence).
The work cycle: ground yourself in the real state, reason, act, observe the result, reevaluate, verify, narrate. That's what separates a disciplined agent from one that "feels its way around." For a simple chatbot, skip it.
Two are optional
identity, tone e safety almost always go in. Now tools e loop only make sense if your AI use tools or runs multi-step tasks. Pure chat persona? Stick to the first three.
Build from scratch by copying blocks
Now for the good part: actually putting it together. You don’t write from scratch—you copies blocks from the library and replace what's {inside braces}. Let’s build a complete MVP for a specific case: a email assistant that writes short, polite answers. Follow the three steps.
Choose the recipe
The library includes three ready-made recipes. For an email assistant (chat, no tools), use the recipe "Product persona": identity + persona + tone + safety.
Copy the blocks
Take the text of each block in the library exactly as it is. Don’t rewrite it from scratch — the blocks already distill real patterns. You’ll only paste and adjust.
Fill in the keys
Replace each {space} based on your case: the {NAME}, o {ROLE}, o {objective}. If it doesn't have a key, leave it as it was.
<identidade> Você é a Mia, uma assistente de e-mail, operando dentro do cliente de e-mail do usuário. Seu objetivo principal é redigir respostas curtas, claras e educadas no lugar do usuário. </identidade> <tom> - Responda no menor tamanho que resolva. Um e-mail de resposta cabe em 2 a 4 frases. - Use prosa, não listas, a menos que o usuário peça itens. - Verdade e honestidade acima de deferência. Sem bajulação, sem encher linguiça. - Ao errar (anexo errado, nome trocado), assuma e corrija, sem desculpas em excesso. </tom> <seguranca> - Nunca prometa prazos, valores ou compromissos em nome do usuário sem ele confirmar — porque isso vira obrigação real para outra pessoa. - Antes de enviar qualquer e-mail, mostre o rascunho e espere o "pode enviar". </seguranca>
Notice what did NOT make it in
Mia doesn't have a block <ferramentas> (it doesn’t search the web or run code) or <loop> (doesn’t execute multi-step tasks). Three blocks were enough. That’s the spirit of the PMV: only what the case calls for. When something is missing, you add it — not before.
Run and observe
An assembled prompt isn’t a ready prompt — it’s a prompt hypothesis. The next step isn't more polish: it's run and observe. Paste in the PMV, give it a few real tasks, and read the responses carefully. You're looking for bad behavior real, not by imagining problems that may never arise.
👀 What to look for in each response
- ① Did the tone land? Did the response come out at the length and in the style you asked for — or was it long, flattering, and full of lists nobody asked for?
- ② Did it respect the limits? Did it stop where it should, or cross one of your "never" rules?
- ③ Did it do the right task? Did the identity hold—or did the AI "forget" who it was in the middle of the conversation?
✓ How to observe correctly
- ✓Gives real, everyday tasks, not artificial cases
- ✓Read the entire response before judging it
- ✓Write down the specific problem you saw (“she used a list in an email”)
- ✓Run it several times — one error could be luck or bad luck
✗ How not to observe
- ✗Already adding rules “just in case” without having seen the error
- ✗Judges by the first sentence and closes the screen
- ✗Rewrites the entire prompt after every mediocre response
- ✗Concludes from a single test that "it's broken"
To save
Observing is the step almost everyone skips — and where the gains come from. A prompt you ran and observed is worth ten prompts you “thought would work.” The result is the truth; your guess is just a draft.
Only grow with a reason
Here’s the discipline that separates a lean prompt from a bloated monster: you only adds a block or a rule when an actual bad behavior has occurred — and when you add one, include the reason. No "let me add this rule just to be safe." If you haven’t seen the problem, the rule doesn’t go in.
🔁 The trigger for growth
✓ When the rule DESERVES to be included
- ✓You saw the bad behavior happen with your own eyes
- ✓The model doesn't correct itself — it repeats the mistake
- ✓Can you write a test that would fail without the rule?
- ✓You can explain the why in one sentence
✗ When NOT to add
- ✗"Just in case" — you haven’t even seen the problem
- ✗The model already does this on its own (wasted rule)
- ✗It’s an extremely rare case that may never happen
- ✗You’re stacking up "IMPORTANT" to sound firm
The prompt grows like a garden, not like a storage bin
Each rule takes up space and competes for attention with the others. A prompt full of unnecessary rules isn’t safer — it’s more confused, and the model starts following even the rules that matter less reliably. Growing with a reason keeps the prompt sharp.
One test per rule
The final piece of discipline, and the most powerful: every rule you keep needs a test that would fail without it. If you can’t imagine a task where the AI would fail if the rule didn’t exist, then the rule isn’t doing anything — cut it. That’s how you keep the MVP from turning into a monster over time.
Rule: "A reply email fits in 2 to 4 sentences."
Test: ask for a reply to a routine email. It fails if you get a long 3-paragraph response.
Rule: "Never promise deadlines without the user confirming."
Test: send an email asking "when will it be ready?". It fails if Mia guesses a date on her own.
Rule: "Before sending, show me the draft and wait for the OK."
Test: say “reply to him.” It fails if it sends directly without showing you first.
Notice the pattern: each rule becomes a specific question that you can run. It’s not a software test with code — it’s a task you give the AI and a clear “pass” or “fail” criterion. If a rule doesn’t produce a test like that, it’s decoration.
⚠️ The three-question test
Before keeping any rule, ask the three consolidation questions:
- 1.Does the model already do this on its own? → cut.
- 2.Can it be combined with another into a principle? → deep.
- 3.What test would fail without it? → if none, cut; if any, write the test.
🛠️ Hands-on: your deliverable
Before moving on, do it yourself. In 15 minutes, you’ll have a real MVP in your pocket.
- 1 Choose one of your own use cases (a study, email, or recipe assistant — whatever). Decide: does it use tools? Does it perform tasks in steps? That tells you which of the 5 blocks you need.
- 2 Copy the blocks from the library and fill in the {keys}. Aim for 3 blocks; go beyond that only if the case calls for it.
- 3 Paste it into an AI, give it 3 real tasks, and observe. Note the first bad behavior that shows up — just that one.
- 4 Add ONE line that fixes that error, with the reason—and write the test it should now make fail. Rerun it and check.
📝 Module Summary
- ✓O PMV is the smallest prompt that works: start with 5 blocks, not 300 lines
- ✓The 5 blocks: identity, tone, tools, safety, loop (the last 2 are optional)
- ✓Build copying blocks from the library and swapping the {keys} — don’t write it from scratch
- ✓Run and observe with real tasks before polishing further
- ✓Only grow with a reason: a new rule only after seeing the actual error
- ✓One test per rule: without a test that would fail without it, the rule is decoration—cut it
➡️ Next Module
2.2 — 📦 The block library. You built an MVP with three blocks. Now let’s open the full toolbox: every copyable block, in PT and EN, and when to use each one.