Detailed content
⚡ Slash commands: time-saving shortcuts
You type / and a list of actions appears immediately. These are the slash commands — the cheapest way to control your session state. Two are essential from here on: /context shows how much of the context window has already been used, and /clear clears the conversation and starts from scratch.
Quick actions built into Claude Code, triggered by typing /. Think of keyboard shortcuts, but in text.
They’re the cheapest way to manage the session. Knowing what takes up space and when to reset prevents quality from dropping.
/clear = open a new tab (fresh context) · custom commands · skills become commands when installed.
The two commands you’ll use most in this module
/context # quanto da janela já foi consumido /clear # zera a conversa — igual a abrir uma aba nova / # abre a lista de todos os comandos disponíveis
💡 Practical tip
Several skills appear as slash commands when installed. When you're not sure what's available, just type / and scroll through the list — it’s your session “menu.”
🧠 Context and Tokens: The Invisible Cliff
Every conversation has a cliff. The longer it gets, the worse the performance—a phenomenon called context rot. It's the #1 beginner mistake: using the same window all day. Managing context is exactly what separates a good result from a mediocre one.
Context rot is the drop in performance as the conversation grows. The more history piles up, the more the model loses track.
Context is a finite resource. Treat it as disposable, and quality will stay high from one task to the next.
One task, one window · when you're done, discard it (/clear) · /context to see the usage · the right model for the task.
Open and measure
Run /context at the beginning to see the current window usage.
Do one focused task
A small, well-defined task. Don't mix five topics in the same window.
Done? Discard
Run /clear before starting something new. Fresh context, preserved quality.
📊 The right model for the right task
- •Not every task requires the heaviest model—simple tasks run well on lighter models.
- •Using the lightweight model for simple tasks saves money and scales better.
- •Save the strongest model for difficult reasoning and critical review.
🎯 Skills: the expert's recipe book
A skill is a set of instructions—a file SKILL.md with a name, description, and step-by-step instructions—which Claude loads automatically when the task fits. Without a skill, the model improvises; with a skill, it follows a tested recipe and consistently delivers the same quality standard.
A reusable procedure packaged in a SKILL.md. Ask "put together a presentation" and the presentation skill kicks in without you naming it.
Skills are "the science behind the output." Every task you repeat is a candidate for a skill — encode it once and benefit from the pattern forever.
The skill is discovered by description (the trigger) · check what’s available by typing / + a name · three parts: name, description, content.
✓ Well-made skill
- ✓Clear description of the when use it—it’s what makes the skill "kick in" at the right time.
- ✓A short, direct procedure that's easy to follow.
- ✓Tested: you request the task and the skill triggers automatically.
✗ Skill that doesn’t light up
- ✗Vague or generic description — Claude never knows when to apply it.
- ✗A long, confusing step-by-step process full of exceptions.
- ✗Never tested — you only find out it doesn’t trigger when it matters.
Build your skill from scratch—ask like this
Vamos criar uma skill para padronizar meu resumo de reunião. Comece pela DESCRIÇÃO (quando ela deve ser usada), depois o passo a passo. Entregue como um SKILL.md pronto para revisar.
Going deeper (optional): the description is everything
Claude chooses the skill by reading the description, not the body. A generic description ("help with texts") rarely triggers; a specific one ("use when the user asks for a meeting summary with decisions and next steps") fires at the right time. Give it your best, as if it were the trigger—because it is.
🔌 MCP: the universal outlet
O Model Context Protocol (MCP) is an open standard that lets the model talk to APIs and services without you writing the integration. An API is a technical manual machines use to talk to other machines; MCP is the standardized adapter on top of it. You don't code the "glue"—you list the MCP server and ask in English.
An open standard (announced by Anthropic in late 2024) that gives Claude a window into your tools: email, data, scrapers, services.
Instead of memorizing endpoints and writing integration code, you talk to the tool. Today, almost every serious tool has an MCP server.
API = machine-to-machine · MCP = wrapper that exposes only what’s needed · Local MCP keeps your key on your machine, with no intermediary.
✓ With MCP
- ✓You ask in Portuguese: "pull up my latest unread emails".
- ✓The key stays in an environment variable, never in the chat.
- ✓One standard works for any tool with an MCP server.
✗ Without MCP (raw API)
- ✗You memorize endpoints and write the integration "cheat sheet" by hand.
- ✗Risk of pasting a key in the wrong place.
- ✗A different codebase to maintain for each service.
Create a local MCP (example: video service)—ask like this
I want to create a local MCP for [SERVICE]. The API key is already set as an environment variable. List the available features, choose the ones most useful for my needs, and create the local MCP. At the end, explain how to call it in a conversation.
🔒 Never put keys in chat
The API key lives in a local environment variable — never pasted into the conversation or a versioned file. A local MCP runs directly on your machine and keeps the key there, away from any intermediary.
👥 Subagents: delegate to finish faster
Instead of one worker doing everything in sequence, you open a team. Subagents are agents launched for separate tasks, each with its own context window. Independent work runs in parallel and finishes sooner.
Parallelization: multiple agents working at the same time, each with their own context.
Great for multi-angle research and breaking a project into workstreams. Independent tasks finish sooner.
Delegate parts that don’t depend on each other · each subagent returns only the conclusion (not the raw history) · this protects your main context.
Break it into independent parts
Break the task into workstreams that don't depend on each other (X, Y, Z).
Launch the subagents
"Create three subagents — one analyzes X, another Y, and another Z." Each returns only the conclusions.
Collect and consolidate
Bring the results together in a comparison table in the main agent.
Parallel fan-out — ask like this
Do [TASK]. Create three independent subagents: - subagent 1: analyzes [angle X] - subagent 2: analyzes [angle Y] - subagent 3: analyzes [angle Z] Each one returns only its conclusions. Then consolidate them into a comparison table.
🔁 Critique loop: one creates, another reviews
"Claude evaluates Claude’s work." Ask it to create is one thing; asking review is completely different—and greatly improves the result. Automatic review catches errors the author doesn’t see.
A workflow where one agent creates the deliverable and another takes on the role of critical reviewer, pointing out gaps and returning the corrected version.
Review catches what the author can’t see. You can even use a different model as the reviewer to bring in a second point of view.
Separate the roles (author vs. critic) · explicitly ask for critique · iterate for one or two rounds · other model CLIs can join as external reviewers.
Switch roles to review—ask like this
Você acabou de criar [ENTREGÁVEL]. Agora mude de papel: seja um revisor crítico e rigoroso. Aponte furos, vieses e o que faltou. Em seguida entregue a versão final corrigida.
Going deeper (optional): why separating roles works
When the same agent creates and judges in the same breath, it tends to defend its own draft. By explicitly asking “now be the critic,” you reset its stance: the goal becomes finding problems, not justifying choices. One or two rounds are usually enough — more than that has diminishing returns.
Self-check (optional): what is the best way to avoid the context rot?
🧪 Guided Hands-On Example: Mini-Research “Where to Live”
Let's bring together skills + subagents + critique loop on a real task — and see context management in practice.
Clean session
Run /clear and then /context to confirm it's at zero.
Launch subagents
"Research the best place to live. Three subagents: finance/tax, quality of life, climate and safety. Each returns only the conclusions."
Consolidate
When all three come back, ask the lead agent for a comparison table.
Critique loop
"Now act as a critical reviewer: point out gaps, biases, and what’s missing. Then deliver the corrected final version."
Check the context
Run /context. Notice how much the window has grown — and why you'll want to /clear before the next task.
✏️ Exercises
1. Context hygiene (easy)
Run /context, do a short task, run /context again and then /clear. Criterion: you know how much the task consumed, and the window resets to zero after the /clear.
2. Use a Ready-Made Skill (medium)
Install a collection of skills from a trusted source, verify a skill with / + a name and use it for a real task. Criterion: the skill appears in the list and produces output in its format.
3. Your First Skill (medium)
Create a skill for a task you repeat (e.g., standardizing meeting summaries). Criterion: when you request the task, the skill is triggered and the result is consistent.
4. Local MCP (medium)
Connect a tool you use via MCP (with the key in the environment). Criterion: you call the tool in Portuguese without writing the endpoint, and the key never appeared in the chat.
5. Critical work in parallel (difficult)
Ask for any creation, then launch a reviewer subagent to critique it and return the final version. Criterion: the final version fixes at least one issue identified in the critique.
⌨️ Ready-to-use prompts
Four instructions for activating the power features. Use them as a starting point and adapt them to your situation. The full library is in the Library → Prompts.
Check and clear context
Antes de começarmos, me diga: o que está ocupando minha janela de contexto agora? Se passar de metade, sugira o que descartar. (equivalente a /context)
Create a skill from scratch (canonical)
Quero criar uma skill para [TAREFA QUE REPITO]. Primeiro escreva a DESCRIÇÃO (quando esta skill deve ser usada). Depois o passo a passo que você deve seguir toda vez. Entregue como um SKILL.md pronto para eu revisar.
Original (EN):
I want to create a skill for [REPEATED TASK]. First write the DESCRIPTION (when this skill should trigger). Then the step-by-step you must follow every time. Output it as a ready-to-review SKILL.md.
Launch subagents in parallel
Do [TASK]. Create three independent subagents: - subagent 1: analyzes [angle X] - subagent 2: analyzes [angle Y] - subagent 3: analyzes [angle Z] Each one returns only its conclusions. Then consolidate them into a comparison table.
Audit a third-party skill before installing it
Vou instalar esta skill de terceiros. Leia o SKILL.md, me diga em bullets o que ela executa, que acessos ela pede e qualquer sinal de risco. Só recomende usar se for seguro.
⚠️ Common errors
- ✗Use the same window all day. Long conversation = context rot = quality drop. One task per window;
/clearwhen finished. - ✗Install a skill from a questionable source. A skill is code that runs on your machine. Read the
SKILL.mdand install only from trusted sources. - ✗Pasting API keys into chat. Keys belong in local environment variables, never in the conversation text or version-controlled files.
- ✗Skip the review. Accepting the first draft without a critique loop lets errors slip through. Creating and reviewing are different steps.
- ✗Parallelize dependent tasks. Subagents shine at independent work. If part B depends on A, running them in parallel only creates rework.
✅ Module summary
/context measures, /clear resets; one task per window beats the context rot.Completion checklist
- ☐ I know how to use
/contexte/clearand understand what context rot. - ☐ I installed and used a ready-made skill from a trusted source.
- ☐ I created at least one skill from scratch (name + description + step-by-step instructions).
- ☐ I connected an external tool via MCP, with the key in the environment.
- ☐ I launched subagents in parallel and consolidated the results.
- ☐ I ran a critique loop (create → review → final version).
- ☐ I can choose the right model for simple vs. complex tasks.
🎉 End of Track 1!
You've completed the Fundamentals. Next track: Build — start with module 2.1, from building a website from scratch to deployment.