🧩 Skills — packaged abilities
Your Jarvis already has hands (tools) and a soul (identity). What it needs is recipes: step-by-step procedures you don't have to repeat every time. That's a skill — a text file that packages "how to do something." In this module, you’ll learn what a skill is, why it’s worth packaging, how skills save memory, how they differ from a tool, how they run in more than one program, and how they improve on their own.
📒 What is a skill
Imagine a cake recipe stored in a folder. It isn't the cake, the oven, or the flour — it's the step by step that says what to do with all of this, in the right order. A skill (skill) is exactly that for your Jarvis: a text file that packages a repeated procedure. When you say “write a LinkedIn post,” the corresponding skill already knows the steps — research the topic, create a graphic, write the copy, review, and publish — without you having to explain each step again.
New here? A skill and a "reusable recipe" stored in a text file called SKILL.md. O .md and it’s just the Markdown extension—plain text with headings and lists that anyone can read and edit in a text editor. It’s not a program and doesn’t require installing anything: it’s written instructions that Jarvis follows.
🧩 Anatomy of a skill
Every skill has two parts: a short heading (the “label” on the recipe, with its name and when to use it) and the body (the actual step-by-step instructions). The header is always visible; the body is read only when the recipe is called.
- •Name — what the skill is called (e.g.,
post-linkedin). - •Description — a sentence saying when trigger (that’s what makes Jarvis decide to use it).
- •Steps — the recipe itself: do this, then that, using this criterion.
The key insight is that a skill is knowledge that becomes capability. You teach the procedure once, in writing, and it stays available forever—in any conversation, without you having to remember the details. And because it’s just text, you can read, edit, and version it like any document.
Key concepts
A recipe: step-by-step instructions packaged in a text file.
The Markdown file that stores the name, description, and steps.
Plain text, human-readable, with no coding required.
You write the procedure once; it becomes a permanent skill.
📦 Why package it
Without skills, you become a broken record: every time you ask for the same thing, you have to explain the 5 steps again. "Research the topic, but use only 2025 sources; then make a simple chart; the copy must be no more than 3 paragraphs; review the tone; and only then publish." Repeating this with every request wears you out, and the result comes out different every time, because the explanation is never identical.
✗ Without a skill (explaining every time)
- ✗You retype the same steps with every request.
- ✗The result varies: sometimes it forgets the review, sometimes the paragraph limit.
- ✗Knowledge lives only in your head—no one else can reuse it.
- ✗Improving the process means remembering to change the explanation next time.
✓ With a skill (one sentence is enough)
- ✓You say "write a LinkedIn post" and the steps run on their own.
- ✓The result is consistent: the same recipe, every time.
- ✓The recipe is in a file—you can share it with the team.
- ✓Did it improve? Edit the file once and it applies forever.
📊 Three concrete benefits of packaging
- •Consistency: the same quality every time, because the step-by-step process doesn’t change.
- •Speed: a sentence instead of a paragraph of instructions.
- •Collection: every skill you write stays on the shelf—it becomes a library of capabilities.
Key concepts
Save a repeated procedure in a file instead of in your memory.
The same recipe produces the same pattern of results.
Your skills library grows and is reused.
The improvement stays in the file and applies to all future uses.
🔎 Progressive Loading
Here’s the trick that makes skills inexpensive. Remember that the LLM has a limited working memory — the context window (we saw this in Track 1). If you dumped the full text of 50 skills into that memory, it would fill up before you even started. The solution is the progressive loading (in English, progressive disclosure): Jarvis only sees, at all times, the label for each skill—name and description, about ~100 tokens. The full body (the entire recipe) is only read when that skill is actually triggered.
New here? Frontmatter and the header at the top of the file (name + description), between two lines of three hyphens ---. Token and it’s the small piece of text the model counts as "memory used." Progressive disclosure = “reveal gradually”: show only the label until you need the content. It’s like a book’s index: you read the chapter titles and open only the chapter you’re interested in.
On the left, the library stores dozens of skills but only exposes each one's label (inexpensive). When you activate one, the complete body the recipe goes into working memory — only that one, only at that moment. That's how having many skills doesn't clog the context.
Key concepts
Reveal only the label until the skill is activated.
The lightweight header (name + description), always in view.
The tiny cost of keeping a skill available.
Dozens of skills without overloading working memory.
🔧 Skills vs. tools
Be careful not to confuse the two, because their names often appear together. In the previous module (3-3), you saw tools: Jarvis’s “hands”—searching the web, reading a file, sending an email. A tool is a atomic action: does a thing and returns the result. One skill and it’s another layer: it’s a procedure that decides which which tools to call, in what order, and what to do with each result. The tool is the verb; the skill is the recipe that uses several verbs.
🍳 The kitchen metaphor
In a kitchen, the tools are the knife, the oven, and the mixer — each performs one action. The skill and it's the cake recipe: "beat the eggs (mixer), cut the fruit (knife), bake for 40 min (oven)." The recipe orchestrates the tools thoughtfully—it knows the order, the quantities, and when something went wrong.
Without tools, the recipe has nothing to work with. Without the recipe, you have loose tools and no cake.
🔨 Tool = atomic action
- •“search the web,” “read a file,” “send an email.”
- •Does a thing and returns a result.
- •It doesn't decide anything on its own—someone has to call it.
- •Usually arrives via MCP (the “USB” for tools, from module 3-3).
🧩 Skill = procedure + judgment
- •“write a post,” “make a daily summary,” “triage the inbox.”
- •Orchestrates several tools, in the right order.
- •Applies judgment: "if you can't find a source, say so before publishing."
- •It’s just text (SKILL.md)—it doesn’t install anything; it only describes how to do it.
In short: a tool answers "what can I do" (an action). A skill answers "how do I I do such a thing well" (a procedure involving judgment and several actions). A skill almost always uses tools — but not every tool becomes a skill.
Key concepts
A tool does just one thing and returns the result.
The skill chains tools in the right order and with good judgment.
The skill decides what to do when something goes wrong.
A tool is a verb; a skill is a recipe that uses several verbs.
🔁 Portability (polyskill)
Because a skill is just a text file that follows an agreed-upon format (the Agent Skills spec), it isn’t tied to one program. The same recipe can run in the Claude Code and in the Codex (two different AI assistants) — all you need is a tool called polyskill that gets a single source and generates the right version for each one. You write the skill once; it works in more than one place.
New here? Agent Skills spec and it’s just an "agreed-upon format"—a standard for writing the skill file so different programs know how to read it. Polyskill and it’s the translator: from a single source, it emits (generates) the version for each program. Cross-runtime = “runs in more than one runtime environment.” Portability = the ability to take the same thing from one place to another without rewriting it.
⚠️ Honestly: what “multiple models” DOESN’T mean here
When people say that skills work with “multiple models,” that is portability (the same recipe runs in Claude Code and Codex) — and no advice from several brains weighing in together, or a recommendation on which model to choose. Portability = one file, multiple destinations. No magical voting among models. (We'll return to this myth in module 3-6, about Brains.)
Objective: create a minimal, portable skill — a SKILL.md with a header (name + description) and the recipe steps. Then we generate the version for another program with polyskill.
1) Create the folder and paste the content below into the file SKILL.md (swap the parts <...>):
mkdir -p ~/.jarvis/skills/<nome-da-skill> cat > ~/.jarvis/skills/<nome-da-skill>/SKILL.md <<'EOF' --- name: <resumo-do-dia> description: Use quando eu pedir um resumo do meu dia. Le a agenda e os e-mails nao lidos e devolve 3 bullets curtos. --- # Resumo do dia Passos: 1. Buscar os compromissos de hoje na agenda. 2. Listar os e-mails nao lidos das ultimas <24h>. 3. Resumir em <3> bullets curtos, do mais urgente ao menos. 4. Se nada for urgente, dizer "dia tranquilo" e parar. EOF
2) (Optional) Generate the version for another program from this single source:
polyskill build ~/.jarvis/skills/<nome-da-skill> --target codex
How to check: run cat ~/.jarvis/skills/<nome-da-skill>/SKILL.md and make sure the file opens with ---, has name: e description:, and then the numbered steps. In your Jarvis, ask "give me the summary of the day" — if it follows the 4 steps in order, the skill was recognized. If you ran step 2, check that a version appeared in the polyskill output folder for the target codex.
Teaching note: command names (polyskill) and paths are illustrative of the concept—the important thing is the file format (header between --- + steps). The spec is the format; the program just reads it.
Key concepts
The combined format that makes the skill readable by multiple programs.
The translator: from a single source, it outputs a version for each target.
The same skill runs in Claude Code and Codex.
"Multiple models" here means one file, several destinations.
🌱 Skills self-correct
The best part: a skill isn’t a stone—it’s something living system that improves with use. Every time the recipe runs, you (or Jarvis himself) notice what could be better: “I should have checked the source,” “the tone came out too formal,” “that step was unnecessary.” Since the skill is just text, all you have to do is edit the file and the next run is already better. The recipe learns from its own practice.
Runs
The skill does the actual task—creates the post, writes the summary.
Observes
You notice a snag: a step was missing, another was unnecessary, or the result needed tweaking.
Edit SKILL.md
You adjust the recipe text—a line added, a criterion made clearer.
Improves from then on
The fix applies to all future runs — without you having to remember.
📚 The skills library and its collection of capabilities
Every skill you write and refine is kept. Over time, you don’t have “an assistant”—you have a collection of finely honed skills that only grows. A Jarvis with 20 good skills is worth much more than a raw model, because it carries procedures tested in your own reality.
And because everything is readable text, this collection “outlasts the hype”: the technology changes, but your recipes remain useful.
📊 Why this is so powerful
- •Compounding improvement: small tweaks add up — today's skill is better than yesterday's.
- •Process memory: the lesson learned stays in the file, not in your head.
- •Transferable: a mature skill can be shared with others already polished.
Self-check (optional): Which sentence best describes a skill?
Key concepts
Each run reveals an adjustment; editing the file improves the future.
Small refinements add up over time.
Your library of refined skills is what makes Jarvis yours.
It’s just text: it remains useful even when the technology changes.
🎯 Module summary
Next module:
3-5 — Agents: the loop that works on its own