Detailed content
🪜 What is progressive disclosure
Progressive disclosure (progressive disclosure) is a principle borrowed from interface design:
show only the essentials first, and reveal details only when needed. In a skill, this means
that the SKILL.md loads the main flow, and the deep knowledge stays stored in files that are read only on demand.
🪜 Why this matters
Everything that goes into SKILL.md costs context every time the skill runs — even the detail that specific run won't use.
- •Layer 1 — always visible: the description (in the index).
- •Layer 2 — when triggered: the SKILL.md body.
- •Layer 3 — on demand: the files for
references/,scripts/,assets/.
💡 Practical tip
Think of a product manual: the cover tells you what it is, the table of contents shows the chapters, and you read chapter 7 only when you need chapter 7. A well-structured skill works the same way—it doesn't dump the whole book in front of you.
📚 The references/ folder
The folder references/ holds the deep
knowledge of the skill: HTML templates, design systems, color tables, checklists, long examples. These are things that
would make the SKILL.md huge if they were inline—and not every run needs them.
minha-skill/
├── SKILL.md ← enxuto: fluxo + roteamento
└── references/
├── DESIGN-REFERENCE.md ← paleta, componentes, tokens
├── TEMPLATE.md ← esqueleto da saída
└── CHECKLIST.md ← revisão antes de entregar
📊 A real-world case
The itinerary generator dissected in the course keeps a document of Design System separate, with a color palette, typography, and a library of 12 components (hero banner, flight cards, day selector, budget breakdown...). The SKILL.md just says "follow the design system"—it doesn't repeat all of that inline.
Result: the main file stays readable, and the heavy details enter context only when the page is actually being built.
💡 Practical tip
Rule of thumb: if a block in your SKILL.md exceeds ~40 lines and is "reference knowledge" (a table, a template), it probably belongs in references/.
⚙️ The scripts/ folder
When a task has deterministic logic — filtering data, transforming a file, calling an API with fixed rules — it's better to write a script and make the skill run it, instead of asking Claude to reinvent the logic on every call. Code runs the same way every time; regenerated prose doesn't.
✓ Good candidate for a script
- ✓Repeatable calculation (scoring, parsing, conversion)
- ✓API call with a fixed format
- ✓Structured data transformation
- ✓Anything that needs to be exact and identical every time
✗ Not a scripting job
- ✗Judgment, writing, creativity
- ✗Decisions that depend on conversation context
- ✗Natural language interpretation
- ✗Tasks where "it depends" is the right answer
## Workflow
1. Ask the user for the leads CSV path.
2. Run `python scripts/qualify_leads.py <path>` to score each lead.
3. Read the script's JSON output and summarize the top 10.
# A lógica de scoring vive no script — não é regenerada
# em cada execução. O Claude orquestra, o código calcula.
🖼️ The assets/ Folder
assets/ holds the static resources
that the skill uses or references: sources, images, icons, a ready-made example output, a configuration file. The idea is to
keep the skill self-contained — everything it needs travels with it, so it works
the same on any machine.
📦 The value of a ready-made example
One of the most valuable assets is a complete sample output. The itinerary generator, for example, includes a sample file (a demo trip that has already been rendered).
- •Anchors quality: Claude sees the expected level.
- •Documents the format better than a thousand words.
- •Serves as a test: the new output should be just as good.
🧷 Self-contained in practice
Well-made skills avoid external dependencies. The itinerary generator's "one file, zero dependencies" principle — inline CSS and JS, base64 images, just one external font — follows the same spirit: the deliverable doesn't break because a server went down or a link changed.
🪶 Keeping SKILL.md concise
This is the golden rule of the structure: the SKILL.md is a
a router, not an encyclopedia. It should contain the workflow, decisions, and rules
—and point to for the details, don't dump them all. A bloated SKILL.md costs you context with every invocation.
✓ Goes in SKILL.md
- ✓Frontmatter (name + description)
- ✓The high-level workflow
- ✓The hard rules and principles
- ✓The "read X when Y" table
✗ Goes in the supporting files
- ✗Complete HTML/CSS templates
- ✗Long tables of query data
- ✗Calculation logic (becomes a script)
- ✗Huge output examples
⚠️ The bloated SKILL.md symptom
If your main file has 800 lines and most of them are tables and templates used only in half of the runs, you’re paying for context for nothing every time the skill runs. Move the bulk to references/ and let SKILL.md breathe.
💡 Practical tip
Read your entire SKILL.md aloud. If you find yourself “skipping” a block because it’s just a reference table, Claude doesn’t need it every time either — that block is a candidate to become a supporting file.
🗺️ Routing Between Files
Having support folders only works if the SKILL.md know when
to open each one. The pattern is simple and powerful: a conditional instruction like
"read references/X.md when you’re going to do Y". This turns a pile of files
into a skill you can navigate on its own.
## Quando ler cada arquivo
| Se você vai... | Leia primeiro |
|-----------------------------|----------------------------|
| construir a página de saída | references/DESIGN.md |
| revisar antes de entregar | references/CHECKLIST.md |
| calcular o score | (rode scripts/score.py) |
Não leia tudo de uma vez — abra cada arquivo só na etapa
que precisa dele.
Name the condition
"When building the output," "when the user asks for a review." The condition must be recognizable within the workflow.
Point to the right file
One explicit path per condition. Avoid “read everything in references/”—that defeats the benefit of progressive disclosure.
Reinforce “only when needed”
Make it explicit that the files should not be loaded in advance. This line protects the context.
🧰 Copyable prompts
Use these prompts to refactor your skills using progressive disclosure.
Aqui está meu SKILL.md: <cole>. Aponte quais blocos são
"conhecimento de consulta" (tabelas, templates, exemplos longos)
que deveriam sair para references/, e quais blocos são fluxo/regras
que devem ficar. Justifique cada um.
Para uma skill que faz <descreva>, proponha a árvore de pastas
(SKILL.md + references/ + scripts/ + assets/) e diga, para cada
arquivo, o que ele contém e em que etapa do workflow é lido.
Escreva uma seção "Quando ler cada arquivo" para minha skill,
em forma de tabela (condição → arquivo a abrir), deixando claro
que os arquivos só devem ser carregados sob demanda.
📤 Sample Output
One SKILL.md lean and delegates to supporting files—the progressive disclosure pattern in action.
---
name: invoice-builder
description: Builds a clean PDF-ready HTML invoice. Use when the
user wants to "create an invoice", "bill a client", or /invoice.
---
# Invoice Builder
## Workflow
1. Collect client, items, amounts, due date.
2. When building the layout, read `references/TEMPLATE.md`.
3. Before delivering, run `references/CHECKLIST.md`.
## Rules
- Never invent line items the user didn't provide.
- Totals must match the sum of the lines exactly.
## When to read each file
| If you are... | Read first |
|----------------------|-------------------------|
| building the layout | references/TEMPLATE.md |
| reviewing the output | references/CHECKLIST.md |
Load support files only at the step that needs them.
✏️ Practical exercises
1. Classify each block
Choose an existing skill and classify each section of SKILL.md as: "stays" (workflow/rules), "moves to references/", or "becomes a script". Count how many lines you could move out.
2. Draw the tree
For a skill that generates audit reports, design the complete folder tree (SKILL.md + references/ + scripts/ + assets/) and explain why each item is where it is.
3. Create a runnable SKILL.md with a reference ⭐
Write a SKILL.md lean PLUS one file references/TEMPLATE.md of support. The SKILL.md should include a routing instruction ("read the template when building the output"). Then ask Claude to run the skill and confirm that it opens the template only at the right step—not before.
📂 Module summary
Next module:
1.3 — Descriptions that trigger