🏗️ meta-skill-creator: o template canónico
A skill meta-skill-creator faz scaffolding completo de uma skill nova seguindo o padrão iAmasters: YAML frontmatter, secções padronizadas, edge cases, gates de qualidade.
Contrato de qualidade de uma skill iAmasters
- YAML frontmatter completo —
namekebab-case com prefixo,description50-500 chars com quando ativar - Progressive disclosure — SKILL.md não tem tudo;
references/guarda knowledge extenso - Passos numerados e testáveis — cada passo verificável
- Skill collaboration explícita — se invoca outras skills, nomeia quando e porquê
- Output verifier gate se gera conteúdo entregável
- Learnings hook — no fim regista em
context/learnings.md - Idioma — SKILL.md em português, code/JSON em inglês
SKILL.md de referência (skeleton)
--- name: marketing-cold-email description: Gera secuência de cold email para B2B SaaS com brand voice carregada, subject lines testadas, e gate de output-verifier. Ativar quando user pede "email frio para X" ou "secuência outbound". --- # marketing-cold-email ## Quando se invoca - Quando pedes: "email frio para...", "secuência outbound...", "cold sequence" - Quando outra skill (marketing-content-repurposing) precisa de email ## Process 1. Carrega brand-context/voice/voice-profile.md 2. Determina registo (B por defeito, A se prospect formal) 3. Gera 3 emails: F-up 1, F-up 2, breakup 4. Cada email com: subject A/B, body <120 palavras, CTA único 5. Invoca tool-output-verifier antes de entregar 6. Append em context/learnings.md se descobre padrão novo ## Edge cases - Sem brand-context → pede setup antes - ICP B2C → recusa (skill é B2B-only) - ...
💡 Estrutura de pastas gerada
.claude/skills/<categoria>/<nome>/
├── SKILL.md # Processo principal
├── references/ # (opcional) Knowledge separado
│ ├── examples.md # 2-3 exemplos reais
│ ├── checklist.md # (opcional) QA
│ └── <outros>.md
└── scripts/ # (opcional) Executáveis
└── <nome>.py # ou .sh
🤔 Quando criar skill (vs prompt simples)
Inflar skills é o erro mais comum. Skills devem capturar padrões validados, não experiências one-off. Critérios objetivos abaixo.
✓ Criar skill se
- ✓Vais repetir o padrão 3+ vezes nas próximas semanas
- ✓Tem knowledge separável da execução (templates, checklists, exemplos)
- ✓Beneficia de colaboração com outras skills (voice, verifier)
- ✓Tem edge cases recorrentes que vale a pena documentar
- ✓Output requer gate de qualidade (humanizer, output-verifier)
✗ Prompt simples (ou slash command) se
- ✗Vais usar 1-2 vezes só (experimentação)
- ✗Não há knowledge separável — só "faz X"
- ✗Fluxo curto (1-2 passos) — slash command em
.claude/commands/ - ✗Específico demais (só serve a um cliente) — mete em
clients/<X>/.claude/skills/ - ✗Ainda não validaste o padrão funciona consistentemente
📊 Sintoma claro de "graduar para skill"
Quando estás a copiar-colar o mesmo prompt longo de uma sessão para outra, com pequenas adaptações, é momento. A skill captura o padrão estável, tu adaptas só o input específico.
💡 Filosofia "max 30 skills"
Com 1000 skills, Claude não sabe qual escolher. Com 30 bem feitas, cada prompt aciona a certa. Cria conscientemente, despromove se não usas em 1 mês.
📁 Estrutura references/ (knowledge separado)
Progressive disclosure: SKILL.md fica curto e Claude lê sempre que avalia ativar. References/ só quando precisa executar.
| Ficheiro | Conteúdo | Obrigatório? |
|---|---|---|
SKILL.md | YAML + Quando se invoca + Process numerado + Edge cases | Sim |
references/examples.md | 2-3 exemplos reais de uso com input/output | Recomendado |
references/checklist.md | Validações QA antes de entregar | Opcional |
references/<domain>.md | Knowledge extenso (taxonomias, templates, regras) | Se aplicável |
scripts/<name>.sh | Executáveis (validações, conversões) | Se precisa código |
⚠️ Regra: references/ se SKILL.md >2500 chars
SKILL.md grande pesa no descobrimento (Claude lê todas em cada sessão). Se cresce além de 2500 chars, move secções longas (exemplos, knowledge, listas) para references/. Mantém SKILL.md como "menu" que aponta lá quando precisa.
💡 Por que examples.md ajuda muito
Claude usa os exemplos para calibrar ativação. 2-3 exemplos reais com input típico → output esperado tornam o matching muito mais preciso. Especialmente útil para skills cujo nome/descrição poderia ser ambíguo.
🔗 Skill collaboration (uma skill chama outra)
Em vez de criar "skill mamute" que faz tudo, compõe skills pequenas que se invocam explicitamente. Cada uma faz uma coisa bem.
Exemplo: cadeia de marketing-copywriting
user → marketing-copywriting
├→ marketing-brand-voice (carrega voice + 3 registos)
├→ marketing-icp (carrega ICP target)
├→ <executa o copy>
├→ tool-humanizer (remove AI-tells)
└→ tool-output-verifier (gate final)
↓
output entregue ao user
📊 Como nomear skills chamadas
Na secção "Process" ou "Quando se invoca" da SKILL.md, lista explicitamente:
## Process 1. Carrega contexto via marketing-brand-voice 2. Se ICP > B2C → invoca marketing-icp para refinar 3. Gera o copy 4. Antes de entregar: invoca tool-output-verifier 5. Se verifier acende vermelho: itera + reinvoca
⚠️ Dependências circulares
Skill A chama B, B chama A → loop. O validate-skill.sh deteta o caso simples, mas casos transitivos (A → B → C → A) podem passar. Mantém o grafo acíclico.
💡 Output-verifier como gate final
Skills que entregam conteúdo ao user devem invocar tool-output-verifier como último passo. Skills internas (que só preparam dados) não precisam.
✅ Quality gate: tool-output-verifier obrigatório
tool-output-verifier é o último filtro de qualidade. Sem ele, entregáveis saem "ok-mas-IA-óbvio" ou desalinhados com a voice. Com ele, pedem revisão menos vezes.
O que o verifier checa
- •Brand voice alignment — confere contra voice-profile.md (formality, directness, warmth, humor)
- •Vocabulário proibido — palavras na lista de "nunca usar" (leverage, sinergia, etc.)
- •Registo certo — A/B/C correto para a plataforma
- •AI-tells — frases robóticas ("Espero que esteja bem", "Sem mais delongas")
- •Factualidade — números, datas, nomes coerentes com contexto
- •Formato — respeitado o pedido (tamanho, headers, CTAs)
📊 3 estados do verifier
- 🟢Pass: entrega ao user com 1-line de confirmação
- 🟡Warn: entrega mas avisa o operador dos avisos (decidir se itera)
- 🔴Fail: NÃO entrega; volta à skill chamadora para iterar (max 2 retries)
💡 Combinar com tool-humanizer
tool-humanizer remove AI-tells antes do verifier. Ordem típica: gera → humanizer → verifier → entrega. Para conteúdo curto (subject line, CTA), pode saltar humanizer.
🤝 Contribuir ao catálogo
As skills mais úteis que criares para ti podem servir 100 outros operadores. O catálogo iAmasters aceita PRs com critérios objetivos e revisão trimestral.
Critérios para uma skill entrar no catálogo
- ✓Validada em produção ≥2 semanas — não "instalei e parece OK"
- ✓Serve a ≥3 avatares iAmasters (freelance-ia, agencia-marketing, formador-online, consultoria-b2b)
- ✓Output útil sem contexto prévio do operador específico
- ✓Não depende de integrações privadas (Skool, ferramentas fechadas)
- ✓Não contém informação confidencial (clientes, decisões internas)
- ✓Passa validate-skill.sh sem bloqueantes
📊 Processo de PR
- Abre issue ou PR em inematds/iamasters-os
- Inclui: link à skill, 1-2 exemplos de uso real, categoria sugerida, porque encaixa na Camada 2
- Maintainer revê — pode pedir ajustes (description, examples, edge cases)
- As que passam adicionam-se ao catálogo na próxima release trimestral
- Skills obsoletas saem na mesma revisão — catálogo vive, não cresce indefinidamente
✓ Devolver é a melhor forma de aprender
Escrever uma skill para "ti" é diferente de a escrever para "outros operadores". Quando submetes, és forçado a generalizar, documentar bem, pensar em edge cases que não tinhas no teu setup. O catálogo melhora-te a ti, não só o ecossistema.
💡 Antes de PR, instala-a "como externa"
Publica a tua skill no teu GitHub público. Pede a 2-3 colegas para a instalarem com /install-skill <url>. Vê se a description ativa nos casos certos, se os passos correm, se a documentação chega. Esse feedback vale mais que o PR direto.
🎉 Resumo do Módulo · e do Curso
Completaste o curso iAmasters OS. Sabes o que é o sistema, como o instalar de forma à prova de falhas, como configurá-lo com a tua voz e brand, que skills tens disponíveis, como operar com multi-cliente, e como esticar tudo isto com skills externas, MCPs, e skills tuas próprias.
Deste módulo levas
Do curso completo levas
🧠 T1 — Conceitos · Arquitetura 3 camadas, problema do Claude vanilla, custo real
⚙️ T2 — Instalação · Install gate, state machine, validação profunda
🎯 T3 — Brand · Voice profile, 3 registos, ICP, positioning
🛠️ T4 — Skills · As 23 skills core e como cada uma se ativa
👥 T5 — Multi-cliente · 4 templates verticais, workflow diário, separação segura
🧩 T6 — Estender · install-skill, install-mcp, criar skills, contribuir
Próximos passos reais
- Se ainda não instalaste:
bash scripts/install.shno teu repo - Se ainda não fizeste deep-dive:
/deep-dive(25-30 min) - Cria o teu primeiro cliente real:
bash scripts/add-client.sh <nome> <vertical> - Instala os 5 MCPs top + plugin Anthropic skills
- Detecta um padrão repetido nas próximas 3 sessões e cria a tua primeira skill custom
- Se a skill funcionar, considera contribuir ao catálogo iAmasters
🦎 Comunidade
Issues, propostas, partilha de skills: github.com/inematds/iamasters-os
Sinapsis upstream (engine de memória): github.com/Luispitik/sinapsis · Comunidade AutomationsAI: automationsai.net