PTENES
TRACK 2

🛠️ Practice

Now it's time to get hands-on. You move from “understanding the note” to build it with your own hands: a five-block Minimum Viable Prompt, a library of ready-to-paste components, a persona designed along four axes, the Tool Contract, the Operational loop that gives an agent discipline — and, ultimately, package everything into a Skill and a agent, actually checking what you built.

7
Modules
42
Topics
~4.5h
Duration
Intermediate
Level
THE PARTS ON THE WORKBENCH 🪪 <identidade> 🗣️ <tone> 🛠️ <tools> 🛡️ <safety> 🔁 <loop> ASSEMBLED BY HAND 🧱 system prompt 5 blocks fitted together lean · ready to run run · observe RUNS AND EVOLVES ▶️ runs today 👁️ observes reality 📈 grows for a reason THE PATH THROUGH THE COURSE PMV + library persona · tools · loop skill + agent and really verifies what you put together what runs and evolves

Learning path map

Detailed content

2.1 ~35 min

🚀 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.

What it is:

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.

Why learn:

The number one mistake beginners make is dumping everything in at once. A small prompt is one you can understand and debug.

Key concepts:

5 blocks, not 300 lines · runs today · grows for a reason · easy to debug.

What it is:

The five pieces: identity, tone, tools, safety e loop — each with a clear role.

Why learn:

Knowing why these five — no more, no less — keeps your prompt from getting bloated. Two of them (tools, loop) are optional.

Key concepts:

identity · tone (highest ROI) · tools (optional) · safety · loop (if it's an agent).

What it is:

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.

Why learn:

It isn’t written from scratch—the blocks already distill real patterns. The exercise also shows what was NOT included and why.

Key concepts:

Copy, don’t invent · replace the keys · use the recipe · only what the case calls for.

What it is:

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.

Why learn:

A prompt you’ve run and observed is worth ten you "thought would work." The result is the truth; the guess is a draft.

Key concepts:

Real tasks · read the entire response · note the specific problem · run it several times.

What it is:

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.

Why learn:

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.

Key concepts:

You saw the error · add it with the reason why · run it again and check · don’t pile on “IMPORTANT.”

What it is:

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.

Why learn:

It’s what turns “prompt guesswork” into engineering: every line gets evidence justifying its presence and alerting you if it stops being useful.

Key concepts:

A test that would fail without the rule · evidence for each line · a rule without a test is suspicious · proof, not a guess.

View Full
2.2 ~35 min

📦 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.

What it is:

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.

Why learn:

It’s the anchor present in 100% of prompts. Having it ready avoids the anti-pattern of a buried or bloated persona.

Key concepts:

Anchor · {NOME} {PAPEL} {objetivo} · short and precise · always present.

What it is:

The block that defines how the AI sounds—concision plus a rule of honesty (truth over flattery; own up when you make a mistake).

Why learn:

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.

Key concepts:

Conciseness · truth > deference · own the mistake · highest prompt ROI.

What it is:

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.

Why learn:

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.

Key concepts:

Verbosity ceiling · prose vs. list · get to the point · calibrate to the request.

What it is:

The block that states precedence when two instructions conflict: core policy > system > user > default.

Why learn:

Without an explicit order, conflicting instructions leave behavior to chance. The block says in advance who’s in charge.

Key concepts:

Precedence · central policy · conflict resolution · user > default.

What it is:

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.

Why learn:

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.

Key concepts:

Cite the source · reference format · verifiable · don’t make up sources.

What it is:

Three ready-made combinations — product persona, task agent, domain specialist — that tell you which blocks to pick for each type of AI.

Why learn:

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.

Key concepts:

Product persona · task agent · domain specialist · use only what’s needed.

View Full
2.3 ~35 min

🎭 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.

What it is:

The first axis: what the persona values when it has to choose—speed vs. care, brevity vs. completeness, truth vs. pleasing others.

Why learn:

Values are the compass that guides behavior in cases the prompt didn’t anticipate. Without them, the persona is just a veneer of tone.

Key concepts:

Priority in conflict · stated trade-off · compass · guides judgment.

What it is:

The second axis: the audible way of speaking — formal or casual, warm or dry, with or without humor — the texture of the voice.

Why learn:

It’s the axis the user feels within seconds. Deliberately calibrating it is what distinguishes a pleasant chatbot from a robotic or sycophantic one.

Key concepts:

Formal vs. casual · warm vs. dry · humor · voice texture.

What it is:

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.

Why learn:

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.

Key concepts:

Ask vs. act · proactive vs. reactive · conversation pace · calibrated initiative.

What it is:

The fourth axis: in what situations the persona stops, asks for confirmation, or hands off — before something irreversible, expensive, or out of scope.

Why learn:

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.

Key concepts:

Stopping point · ask for confirmation · before the irreversible step · hand it off.

What it is:

The unbreakable rule: persona shapes how the AI converses, but never contaminates what it delivers. A cynical email, flattering code — forbidden.

Why learn:

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.

Key concepts:

Persona ≠ artifact · governs the conversation · doesn’t contaminate the deliverable · the only hard rule.

What it is:

Three real personas, verbatim — the friendly, the robotic, and the cynical/pragmatic — shown as different combinations of the same four axes.

Why learn:

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.

Key concepts:

Friend · robot · cynic/pragmatist · same table, different positions.

View Full
2.4 ~35 min

🔧 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.

What it is:

The clause that says when each tool should be called—the “if the user…” that connects intent to the right action.

Why learn:

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.

Key concepts:

"If" condition · intent → action · right moment · don't call reflexively.

What it is:

The clause that requires one step before another—the canonical example: "You MUST use the Read tool at least once before editing."

Why learn:

Many agent errors stem from skipping the step of reading the actual state. Making the prerequisite explicit prevents blind action.

Key concepts:

Dependency · read before editing · required order · avoid blind action.

What it is:

The clause that prohibits one path in favor of another— "Use specialized tools instead of terminal commands…", from Cursor.

Why learn:

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.

Key concepts:

Strong preference · use X, never Y · specialized tool · no ambiguity.

What it is:

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.

Why learn:

Ten queued calls are slow and expensive when one batch would do. Knowing how to batch them directly improves speed and cost.

Key concepts:

Batch vs. queue · parallelism · independence · speed and cost.

What it is:

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.

Why learn:

"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.

Key concepts:

Effect, not mechanism · natural language · hidden workings · clean conversation.

What it is:

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.

Why learn:

Without chaining, the AI repeats work or acts on outdated data. Passing the result along is what gives the task continuity.

Key concepts:

Output → input · continuity · don’t redo · fresh data.

View Full
2.5 ~40 min

🔁 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.

What it is:

The opening argument: agent discipline doesn't come from a magic phrase, but from a repeatable cycle of thinking, acting, and checking.

Why learn:

Prompt tricks break on new cases; a loop generalizes. It's the difference between an agent that thinks and one that just "probes quickly."

Key concepts:

Repeatable process · not a trick · generalizes · think vs. grope.

What it is:

The first phase of the loop: look at the actual state—read the file, check what exists—before reasoning or acting on an assumption.

Why learn:

Almost every serious agent error starts with an unverified assumption. Grounding yourself in reality is the cheapest antidote there is.

Key concepts:

Real state · read before assuming · factual basis · antidote to hallucination.

What it is:

The middle phases: reason through a short plan, then take action — grouping independent tasks into batches instead of doing them one at a time.

Why learn:

Thinking ahead prevents wasted effort; acting in batches prevents delays. Together, they’re the agent’s way of “working smart.”

Key concepts:

Short plan · batch action · independence · use good judgment.

What it is:

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.

Why learn:

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.

Key concepts:

Read the response · reassess · correct course · get out of autopilot.

What it is:

The closing phases: verify that it really worked (run the actual check) and honestly describe what happened — including what failed.

Why learn:

"Report outcomes faithfully": saying it worked without checking is the cardinal sin. Verifying + reporting faithfully is what makes the agent reliable.

Key concepts:

Real check · accurate report · say what failed · trust earned.

What it is:

The final adjustment: calibrate how many loops the task deserves—a trivial question doesn't need seven phases; a risky migration needs them all.

Why learn:

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.

Key concepts:

Scale the effort · trivial vs. risky · proportionality · practical cycle.

View Full
2.6 ~40 min

🛠️ 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.

What it is:

A packaged skill: a description that says when it should trigger, plus instructions on how to perform the task.

Why learn:

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.

Key concepts:

Packaged skill · triggering description · automatic trigger · execution instructions.

What it is:

The five-layer stack: identity → rules/hooks → skills → agents → tools, each with its role in the system.

Why learn:

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.

Key concepts:

Identity · rules/hooks · skills · agents · tools.

What it is:

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.

Why learn:

Subagents isolate context and divide the work. Confusing the two leads to dumping everything in one place—or fragmenting unnecessarily.

Key concepts:

Primary agent · subagent · isolated context · returns a result.

What it is:

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.

Why learn:

Too many agents add needless complexity; too few pile up the work. The “defined role” criterion tells you when a piece is justified.

Key concepts:

Defined role · clear beginning and end · where it makes sense · not for fashion.

What it is:

The practice of launching several subagents at once when subtasks are independent — each in its own context, without waiting in a queue.

Why learn:

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.

Key concepts:

Simultaneous workstreams · independence · combine at the end · agentic parallelism.

What it is:

A concrete case study: a real skill from the INEMA ecosystem, shown from the inside—description, instructions, and where it fits in the layers.

Why learn:

Seeing a real skill completes the cycle: you move beyond the abstract and recognize each part of the module working together.

Key concepts:

Case study · real skill · pieces working together · from abstract to concrete.

View Full
2.7 ~35 min

✅ 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.

What it is:

The mindset shift: every change the AI makes is a hypothesis that it worked — it becomes a fact only after a real check.

Why learn:

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.

Key concepts:

Editing = hypothesis · check = evidence · "edited" ≠ "works" · proof before claiming.

What it is:

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.

Why learn:

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.

Key concepts:

Real test · no theater · would fail if wrong · real evidence.

What it is:

The safety rule: before an action that can’t be undone — deleting, sending, publishing, overwriting — stop and ask for explicit confirmation.

Why learn:

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."

Key concepts:

Irreversible action · ask for confirmation · reversible vs. irreversible · safety brake.

What it is:

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.

Why learn:

A polished report destroys trust faster than the error itself. Saying "it failed; here's the output" is what makes AI worthy of trust.

Key concepts:

Faithful reporting · no hedging · show the output · honesty > appearances.

What it is:

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.

Why learn:

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.

Key concepts:

Diagnose the cause · don’t repeat blindly · fix it with a hypothesis · turn errors into fixes.

What it is:

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.

Why learn:

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.

Key concepts:

Close the loop · what was done / pending · never in silence · clarity for the user.

View Full
←
Back
Track 1 — Fundamentals
Next
Track 3 — Advanced
→