Learning path map
🚀 Your first prompt
5 blocks, not 300 lines
📦 The block library
Copy, paste, adjust
🎭 Persona design
The voice along four dimensions
🔧 Tool Contract
AI calls the right one at the right time
🔁 The operational loop
The disciplined brain ⭐
🛠️ Skill and Agent
Package it and hire
✅ Faithful verification and reporting
Know that it worked, don’t just assume
Detailed content
🚀 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 with five little blocks, run it right away, and only expand it when something actually goes wrong.
The smallest system prompt that already serves you — five little blocks, no frills — put together to run today. It's the starting point, not the final prompt.
The number one mistake beginners make is dumping everything in at once. A small prompt is one you can understand and debug.
5 blocks, not 300 lines · runs today · grows for a reason · easy to debug.
The five pieces: identity, tone, tools, safety e loop — each with a clear role.
Knowing why these five — no more, no less — keeps your prompt from getting bloated. Two of them (tools, loop) are optional.
identity · tone (highest ROI) · tools (optional) · safety · loop (if it's an agent).
The practical setup: you copy blocks from the library and change only what is {inside braces}. Real example: the “Mia” email assistant, in three blocks.
It isn’t written from scratch—the blocks already distill real patterns. The exercise also shows what was NOT included and why.
Copy, don’t invent · replace the keys · use the recipe · only what the case calls for.
The step almost everyone skips: paste in the PMV, give it real tasks, and read the responses looking for concrete bad behavior—not imagined problems.
A prompt you’ve run and observed is worth ten you "thought would work." The result is the truth; the guess is a draft.
Real tasks · read the entire response · note the specific problem · run it several times.
The discipline that separates a lean prompt from an overgrown monster: only add a block or rule when a real bad behavior has appeared—and explain why you’re adding it.
A "just to be safe" rule is wasteful: either the model was already doing it, or it handles a case that never happens. If you haven’t seen the problem, the rule doesn’t belong.
You saw the error · add it with the reason why · run it again and check · don’t pile on “IMPORTANT.”
For each rule added to the prompt, write a test case that would fail without it. If you can’t write the test, perhaps the rule doesn’t need to exist.
It’s what turns “prompt guesswork” into engineering: every line gets evidence justifying its presence and alerting you if it stops being useful.
A test that would fail without the rule · evidence for each line · a rule without a test is suspicious · proof, not a guess.
📦 The block library (copy-paste)
In 2.1, you assembled an MVP with three blocks. Now we're opening the whole toolbox: each block is ready-to-copy text distilled from a real pattern, with {espaços} waiting for your use case. There's just one rule: don't paste them all.
The block that opens every prompt: who the AI is, the model, and the goal in one sentence, with {spaces} for you to fill in.
It’s the anchor present in 100% of prompts. Having it ready avoids the anti-pattern of a buried or bloated persona.
Anchor · {NOME} {PAPEL} {objetivo} · short and precise · always present.
The block that defines how the AI sounds—concision plus a rule of honesty (truth over flattery; own up when you make a mistake).
It’s the highest-return block: on its own, it already eliminates half the answers that drive you crazy—long, ingratiating, and full of lists.
Conciseness · truth > deference · own the mistake · highest prompt ROI.
The block that sets a verbosity ceiling for the AI: answer in the fewest words that get the job done, without padding or dumping unnecessary lists.
Without a budget, the model tends to write too much. A clear concision rule adjusts the response length to what the question actually calls for.
Verbosity ceiling · prose vs. list · get to the point · calibrate to the request.
The block that states precedence when two instructions conflict: core policy > system > user > default.
Without an explicit order, conflicting instructions leave behavior to chance. The block says in advance who’s in charge.
Precedence · central policy · conflict resolution · user > default.
The block that requires the AI to cite and preserve the source of its claims—the reference format that points to the source, as in Perplexity's standard.
Without a citation, the answer becomes "trust me." Preserving the source makes the AI verifiable and reduces the chance that a fabricated claim passes as fact.
Cite the source · reference format · verifiable · don’t make up sources.
Three ready-made combinations — product persona, task agent, domain specialist — that tell you which blocks to pick for each type of AI.
The library has many blocks, but your use case only calls for a few. Recipes help you avoid the mistake of pasting everything in and bloating the prompt for no reason.
Product persona · task agent · domain specialist · use only what’s needed.
🎭 Persona design: the 4 axes
"Be nice" isn’t a persona — it’s a wish. A real persona is shaped by four knobs: what it values, how it sounds, how it guides the conversation, and when it stops to check. Four axes, adjustable like a mixing board.
The first axis: what the persona values when it has to choose—speed vs. care, brevity vs. completeness, truth vs. pleasing others.
Values are the compass that guides behavior in cases the prompt didn’t anticipate. Without them, the persona is just a veneer of tone.
Priority in conflict · stated trade-off · compass · guides judgment.
The second axis: the audible way of speaking — formal or casual, warm or dry, with or without humor — the texture of the voice.
It’s the axis the user feels within seconds. Deliberately calibrating it is what distinguishes a pleasant chatbot from a robotic or sycophantic one.
Formal vs. casual · warm vs. dry · humor · voice texture.
The third axis: how the persona guides the conversation — asks questions before acting or makes assumptions and delivers; waits for instructions or suggests the next step.
Sets the pace of collaboration. An AI that asks too many questions gets tiring; one that never asks misses the mark. This axis adjusts that balance.
Ask vs. act · proactive vs. reactive · conversation pace · calibrated initiative.
The fourth axis: in what situations the persona stops, asks for confirmation, or hands off — before something irreversible, expensive, or out of scope.
It’s the persona’s emergency brake. Without an escalation rule, the AI “decides on its own” things it should confirm—and the damage comes later.
Stopping point · ask for confirmation · before the irreversible step · hand it off.
The unbreakable rule: persona shapes how the AI converses, but never contaminates what it delivers. A cynical email, flattering code — forbidden.
It’s the most common persona mistake: letting the “vibe” spill into the user’s product. Separating voice from artifact is what keeps the persona useful.
Persona ≠ artifact · governs the conversation · doesn’t contaminate the deliverable · the only hard rule.
Three real personas, verbatim — the friendly, the robotic, and the cynical/pragmatic — shown as different combinations of the same four axes.
Seeing the four buttons in distinct positions makes the mixing board tangible: you start shaping your voice in four lines instead of in the dark.
Friend · robot · cynic/pragmatist · same table, different positions.
🔧 Tools and the Tool Contract
Listing the tools isn’t enough. The AI will call the wrong one, ignore dependencies, or make ten calls in a row when one batched call would do. The solution is the Tool Contract: six ready-made clauses that say when to call, what comes first, what never to use, and how to group calls.
The clause that says when each tool should be called—the “if the user…” that connects intent to the right action.
Without a trigger, the AI uses the tool at the wrong time or forgets to use it. A clear condition is what makes the call happen at the right moment.
"If" condition · intent → action · right moment · don't call reflexively.
The clause that requires one step before another—the canonical example: "You MUST use the Read tool at least once before editing."
Many agent errors stem from skipping the step of reading the actual state. Making the prerequisite explicit prevents blind action.
Dependency · read before editing · required order · avoid blind action.
The clause that prohibits one path in favor of another— "Use specialized tools instead of terminal commands…", from Cursor.
When there are two ways to do something, the AI chooses the worse one at the wrong time. Saying “use X, never Y” removes the ambiguity.
Strong preference · use X, never Y · specialized tool · no ambiguity.
The clause that says to group independent calls—batching or running in parallel what doesn't depend on each other, as with parallelism in Claude Code.
Ten queued calls are slow and expensive when one batch would do. Knowing how to batch them directly improves speed and cost.
Batch vs. queue · parallelism · independence · speed and cost.
The clause that separates the behind-the-scenes work from what you say: AI uses the tool but reports the result in natural language, without exposing internal technical names.
"I’ll run the tool grep_search" doesn’t help the user—it’s confusing. Talking about the effect, not the mechanism, keeps the conversation clear and useful.
Effect, not mechanism · natural language · hidden workings · clean conversation.
The clause that says to use one tool's output as the next tool's input—search, then read what the search found, then act on it.
Without chaining, the AI repeats work or acts on outdated data. Passing the result along is what gives the task continuity.
Output → input · continuity · don’t redo · fresh data.
🔁 The operational loop: the disciplined brain
The course’s key module. A disciplined agent doesn’t rush to the keyboard—it grounds itself in reality, reasons, acts in batches, pauses to read what came back, and only then decides what to do next. This cycle has a name: GROUND → REASON → ACT → OBSERVE → RE-EVALUATE → VERIFY → NARRATE.
The opening argument: agent discipline doesn't come from a magic phrase, but from a repeatable cycle of thinking, acting, and checking.
Prompt tricks break on new cases; a loop generalizes. It's the difference between an agent that thinks and one that just "probes quickly."
Repeatable process · not a trick · generalizes · think vs. grope.
The first phase of the loop: look at the actual state—read the file, check what exists—before reasoning or acting on an assumption.
Almost every serious agent error starts with an unverified assumption. Grounding yourself in reality is the cheapest antidote there is.
Real state · read before assuming · factual basis · antidote to hallucination.
The middle phases: reason through a short plan, then take action — grouping independent tasks into batches instead of doing them one at a time.
Thinking ahead prevents wasted effort; acting in batches prevents delays. Together, they’re the agent’s way of “working smart.”
Short plan · batch action · independence · use good judgment.
The heart of the loop: stop to read what the action returned and reassess the plan in light of it—instead of running on autopilot.
It's the phase almost every agent skips—and where the difference lies. If you don't observe, you repeat the mistake; if you do, you correct course.
Read the response · reassess · correct course · get out of autopilot.
The closing phases: verify that it really worked (run the actual check) and honestly describe what happened — including what failed.
"Report outcomes faithfully": saying it worked without checking is the cardinal sin. Verifying + reporting faithfully is what makes the agent reliable.
Real check · accurate report · say what failed · trust earned.
The final adjustment: calibrate how many loops the task deserves—a trivial question doesn't need seven phases; a risky migration needs them all.
Too much looping on a simple task is wasteful; too little looping on a serious task is risky. Calibrating the effort is what makes the cycle practical.
Scale the effort · trivial vs. risky · proportionality · practical cycle.
🛠️ Building a Skill and an Agent
The system prompt was just the beginning. Now you move up a level: package a skill in a Skill (which triggers automatically based on its description) and, when the work calls for it, “hire” an agent with clearly defined start and end points. Five layers, where each piece fits, with a real INEMA example.
A packaged skill: a description that says when it should trigger, plus instructions on how to perform the task.
A well-written description makes the skill show up at the right time, automatically. If it's poorly written, it never triggers or triggers at the wrong time.
Packaged skill · triggering description · automatic trigger · execution instructions.
The five-layer stack: identity → rules/hooks → skills → agents → tools, each with its role in the system.
Knowing where each piece belongs helps you avoid confusing a rule with a skill, or an agent with a tool — it’s the map of the territory.
Identity · rules/hooks · skills · agents · tools.
The distinction between the main agent, which leads the conversation, and the subagent, which is "hired" for a subtask with its own context and returns the result.
Subagents isolate context and divide the work. Confusing the two leads to dumping everything in one place—or fragmenting unnecessarily.
Primary agent · subagent · isolated context · returns a result.
The criterion for when it’s worth creating an agent: when there’s a role with a clearly defined beginning and end—“build an agent where it makes sense,” not just because it’s trendy.
Too many agents add needless complexity; too few pile up the work. The “defined role” criterion tells you when a piece is justified.
Defined role · clear beginning and end · where it makes sense · not for fashion.
The practice of launching several subagents at once when subtasks are independent — each in its own context, without waiting in a queue.
It’s the parallelism of the agentic level: it divides a large job into simultaneous workstreams and combines the results at the end. It’s only worthwhile when there’s real independence.
Simultaneous workstreams · independence · combine at the end · agentic parallelism.
A concrete case study: a real skill from the INEMA ecosystem, shown from the inside—description, instructions, and where it fits in the layers.
Seeing a real skill completes the cycle: you move beyond the abstract and recognize each part of the module working together.
Case study · real skill · pieces working together · from abstract to concrete.
✅ Faithful verification and reporting
The final Practice module, and the one that separates those who “think it worked” from those who know it worked. An edit is only a hypothesis; a real check is proof. Here you build the habit of running the actual test, confirming before anything irreversible, and reporting plainly.
The mindset shift: every change the AI makes is a hypothesis that it worked — it becomes a fact only after a real check.
Confusing "I edited it" with "it works" is behind half the bugs declared fixed. Treating an edit as a hypothesis forces you to prove it.
Editing = hypothesis · check = evidence · "edited" ≠ "works" · proof before claiming.
The rule for a test that truly proves it: run the application, test, or query that actually exercises the change — not a ls or echo that pretends to verify.
A fake check creates false confidence—worse than none at all. Only a real test, one that would fail if the change were wrong, counts as evidence.
Real test · no theater · would fail if wrong · real evidence.
The safety rule: before an action that can’t be undone — deleting, sending, publishing, overwriting — stop and ask for explicit confirmation.
Reversible errors can be fixed; irreversible ones become losses. That restraint is what separates a reliable AI from one that "did it on its own."
Irreversible action · ask for confirmation · reversible vs. irreversible · safety brake.
The obligation to report the result as it was— "Report outcomes faithfully: if tests fail, say so with the output…" — without softening it or pretending it succeeded.
A polished report destroys trust faster than the error itself. Saying "it failed; here's the output" is what makes AI worthy of trust.
Faithful reporting · no hedging · show the output · honesty > appearances.
The method when something fails: stop, diagnose the cause, and fix it based on a hypothesis—instead of blindly repeating the same action and expecting a different result.
An agent that “flails” tries the same thing ten times and makes everything worse. Recovering methodically is what turns an error into a fix, not a spiral.
Diagnose the cause · don’t repeat blindly · fix it with a hypothesis · turn errors into fixes.
The closing rule: every turn ends with a report — what was done, what remains pending, what the user needs to do — never silence without closure.
A turn that ends silently leaves the user in the dark, with no way to know whether it worked or got stuck. Closing the loop is both courteous and clear.
Close the loop · what was done / pending · never in silence · clarity for the user.