🟣 How to use this module
Each pattern has a block copy-run: the goal, the prompt to paste, and how to check whether it worked. The parts between <assim> are variables—replace them with your own case. The patterns are tool-independent: they work for building workflows, generating documents, or creating agents.
A weak prompt and a strong prompt can ask for the same thing — but lead the AI down different paths. The weak prompt dictates steps, is vague about the output, and mixes tasks; the strong one describes the outcome, specifies the format, and handles one task at a time. The seven patterns in this module are the levers that turn one into the other.
Illustrative diagram — the same goal, two prompts. The patterns below are what move the request from the top line to the bottom one.
🎯 Define the goal, not the steps
What it is
The root pattern: say what should happen, not how do. “Identify technical questions and draft a response” is a goal; “use an IF node with regex, then a code node…” is a technical step. You describe the destination; the AI maps the route using everything it knows.
What is it?Prompt — the message you write to AI. Plan Mode — the mode in which the AI researches first and proposes a plan before taking action.
Why learn
When you dictate steps, you limit the AI to your (probably incomplete) knowledge of the tools. When you describe the goal, it chooses the path—and often finds a better one than you would have imagined.
🎯 Goal: ask for an outcome, letting AI choose the path.
Quero um resultado, não um passo a passo. Objetivo: <descreva o que deve acontecer, ex.: "quando chegar um e-mail com 'urgente' no assunto, registrar numa planilha">. Você escolhe as ferramentas e a estrutura. Antes de construir, me explique em 1 parágrafo a abordagem que pretende usar e por quê. Não dite passos técnicos de volta para mim — proponha a melhor rota.
✅ How to verify: the AI responds with an approach and a rationale (not questions about "which node to use"). If it asks you to define the steps, reinforce: "you decide the best way".
✓ Objective
- ✓"Summarize these notes into decisions, tasks, and next steps."
- ✓"Research topic X and generate a brief with 3-5 sources."
- ✓"You decide the architecture; explain your choice to me."
✗ Technical steps
- ✗"Create a trigger node, connect it to an IF, then to a code node…"
- ✗"Use library Y at version Z with parameter W."
- ✗Micromanage each setting.
Key concepts
Say the “what.”
AI chooses the "how."
Use everything it knows.
Ask why that route was chosen.
📐 Be specific about the output
What it is
A clear goal includes a clear output: format, structure, quantity, name, and where to save it. “Build a lead scraper” is vague; “extract 75 CEO profiles from technology companies into a table with name, company, and title, saved in saidas/leads.csv" is specific. Specificity also works as a definition of "done".
Why learn
Vague output produces vague results and more back-and-forth—each round trip costs tokens and time. And without a defined target, AI may research too much or get stuck in a loop, unsure when to stop.
🎯 Goal: set the output format, quantity, name, and location.
<descreva o objetivo>. Especificações da saída: - Formato: <ex.: arquivo .csv / tabela markdown / documento .docx> - Estrutura/colunas: <ex.: nome, empresa, cargo> - Quantidade exata: <ex.: 75 itens> (pare ao atingir isso — esse é o "pronto") - Nome do arquivo: <ex.: leads.csv> - Onde salvar: <ex.: pasta saidas/> Se faltar alguma informação para cumprir isso, pergunte antes de começar.
✅ How to verify: the output has the requested format, quantity, and name, in the requested location. If it says "approximately," reinforce the exact quantity as the stopping criterion.
🎯 Practical tip
"Done" needs to be measurable. "75 profiles" has an endpoint; "some leads" doesn't. Without a clear endpoint, AI can search indefinitely and waste tokens.
Key concepts
csv, docx, table…
Exact number = “done.”
What to name the file.
Where to save.
🗺️ Plan Mode first, execute later
What it is
Start all non-trivial work in Plan Mode: the AI researches whatever is needed, asks clarifying questions, and proposes a plan. You review and approve it; only then does it execute (ideally with bypass permissions (so you don’t have to interrupt at every step).
What is it?Bypass permissions — a mode in which AI performs approved actions without asking for confirmation each time. Use it after approving a plan so the build can run without interruptions.
Illustrative diagram — aligning on the plan is the cheapest stage at which to change your mind. That's why you plan first.
Why learn
Correcting the plan’s direction costs one sentence; correcting it midway through the build means redoing nodes and spending tokens; correcting it after everything is ready costs even more. Plan Mode concentrates decisions in the low-cost phase.
🎯 Goal: require planning and questions before any build.
Entre em plan mode. Objetivo: <descreva o resultado>. Antes de construir qualquer coisa: 1. Pesquise os recursos/padrões necessários. 2. Me faça todas as perguntas de esclarecimento que tiver. 3. Apresente um plano numerado para eu aprovar. Não escreva nem altere arquivos até eu dizer "aprovado". Depois disso, pode executar sem pedir confirmação a cada passo.
✅ How to verify: the first response is a plan + questions, not code. You answer, approve, and only then does the build start.
Key concepts
Before proposing.
Resolve questions in the plan.
You give the “okay.”
Execute without interruption.
💬 Feedback, not corrections
What it is
When something doesn't turn out well, give specific feedback ("I like the structure, but the tone is too formal — make it more casual") instead of straightforward fix ("this is wrong, do it again"). Feedback says what to keep and what to change; dry correction only signals dissatisfaction.
Why learn
Feedback helps the AI adjust the reasoning and, when applicable, update the underlying workflow/skill — don’t just patch the visible output. It also powers the self-improvement loop: the error becomes a lasting lesson.
🎯 Goal: give feedback that preserves what’s good and directs the change.
Feedback sobre o que você entregou: - O que ficou bom (mantenha): <ex.: a estrutura e a divisão em seções> - O que mudar e por quê: <ex.: o tom está formal demais; quero algo mais casual e direto, porque o público é técnico e informal> Aplique a mudança e, se isso vier de um workflow/skill, atualize a regra lá também para valer nas próximas vezes.
✅ How to verify: the new version keeps what you praised and changes only what you pointed out. If there’s a workflow/skill, confirm the rule was updated (not just the output).
Key concepts
Be specific.
Say both sides.
Explain the reason.
Update the rule.
🧑🔬 Treat the agent as a specialist
What it is
The relationship model: you’re the manager; the AI is the developer. You define the goal, context, and criteria; then approve and review. The AI, like an experienced developer, chooses tools, writes, tests, debugs, and self-corrects. Treating it as an expert (rather than a tool that needs micro-instructions) is what brings out its best.
Illustrative diagram — the two-way relationship: you delegate outcomes and give feedback; the AI executes and returns them for review.
Why learn
Anyone who micromanages limits AI to their own limited knowledge. Anyone who delegates (with clear criteria) lets AI apply everything it knows—and can also ask it to explain the reasoning behind its choices, turning each build into a mini-lesson.
🎯 Goal: delegate as you would to a specialist and learn from their choices.
Aja como um desenvolvedor sênior especialista em <ex.: automações n8n>. Objetivo: <descreva o resultado>. Critérios de sucesso: <ex.: roda sem erro, trata caso de borda X, saída no formato Y>. Você decide a abordagem. Conforme for construindo, explique em 1 linha por que escolheu cada ferramenta ou estrutura importante, para eu aprender. Se eu estiver errado em alguma suposição, me corrija.
✅ How to verify: the AI makes technical decisions and briefly explains them instead of asking you "which tool to use." You finish understanding why those choices were made.
Key concepts
Defines and approves.
AI decides the "how."
Trust the repertoire.
Each build is a lesson.
🔥 The errors that cost the most tokens
What it is
Some habits burn tokens and, worse, degrade quality: reusing a bloated conversation for a new task, not defining “done” (the AI researches too much or gets stuck in a loop), leaving servers MCP connected for no reason (each one adds tool definitions to the context), and fixing the same thing three times (a sign of polluted context).
What is it?Context rot — quality drops as the session gets longer; after ~60% of the context, expect more errors. /clear restarts the conversation; /compact summarize while keeping the essentials.
✓ Saves tokens and preserves quality
- ✓One task per session;
/clearbefore the next one. - ✓Define "done" (quantity/criterion) in the prompt.
- ✓Turn off MCP servers you aren't using.
- ✓Start fresh if you’ve fixed the same thing 2+ times.
✗ Burns tokens and worsens the output
- ✗Use a huge conversation for something unrelated.
- ✗Make a request without a target: “find some leads” (endless loop).
- ✗Leave all MCPs on all the time.
- ✗Keep insisting in the same session after 3 corrections.
Why learn
Tokens have a direct cost, but the biggest cost is quality: bloated context makes AI lose sight of the rules. Knowing the threshold strategy (green up to 50%, yellow 50-70%, orange 70-85% run /compact, above 85% run /clear) keeps the session healthy.
Key concepts
By session.
Prevents loops.
Turn off what you aren't using.
/clear when you get stuck.
✅ Checklist of the 12 tips
What it is
A consolidation of the patterns into a 12-item checklist you run through in your head before each build. It’s the module’s practical summary—and the reference card you come back to when something “isn’t working out.”
Always start in Plan Mode. Research + questions + plan before touching any files.
Be clear about the goal. "75 tech CEO profiles," not "build a scraper."
Define what "done" means. Measurable criterion for the AI to stop.
Treat AI as a specialist. You manage; it develops.
Manage the context. /compact ~70%, /clear when switching tasks; one task per session.
Use the self-improvement loop. Specific feedback updates the workflow/skill.
Store keys in environment files. Never in chat.
Test with different inputs. Working with just 1 input = a one-shot script.
Save tested skills. What works becomes reusable.
Start fresh when it gets stuck. Have you fixed the same thing 2+ times? /clear and reprompt.
Turn off unused MCP servers. Each one consumes context.
Watch the build early. Learn, and stop if it goes off track.
🎯 Goal: a reusable header that applies the standards all at once.
Entre em plan mode e aja como especialista. Antes de construir: pesquise, me faça perguntas e proponha um plano para eu aprovar. Objetivo: <descreva o resultado>. Saída: <formato, quantidade exata, nome do arquivo, pasta>. "Pronto" = <critério mensurável de parada>. Chaves/segredos: leia do arquivo de ambiente, nunca do chat. Ao final, teste com 2-3 inputs diferentes e me mostre os resultados.
✅ How to verify: the AI responds with a plan + questions (patterns 1 and 3), follows the format and the "done" criteria, and presents tests with varied inputs at the end (tip 8).
You’ve corrected the AI for the third time on the same point in the same long conversation. What’s the best next step?
📌 Module Summary
Next Module:
3.2 — The Plan → Build → Troubleshoot → Optimize Cycle