A tua caixa de ferramentas: comandos slash e a pasta .claude/ de A a Z

O teu projeto cresceu: precisas de um mapa

Em oito capítulos, o projeto da Lea acumulou skills, hooks, subagents, ficheiros de configurações e uma memória de projeto. Tudo funciona — mas se te pedissem para desenhar onde vive cada peça, saberias fazê-lo? Este capítulo dá-te o mapa completo. Não é arrumação por prazer: saber precisamente onde vive cada mecanismo é saber onde procurar quando algo não funciona, e onde adicionar o próximo tijolo sem partir os outros.

Há uma segunda razão, mais estratégica. Se a Lea contratar um dia uma assistente, ou se confiar o seu site a um freelancer, tudo o que está bem arrumado em .claude/ e versionado no Git transmite-se: a pessoa clona o repositório e herda instantaneamente as convenções, os skills e as salvaguardas. A pasta .claude/ não é um detalhe técnico — é o capital operacional da marca, sob a forma de ficheiros.

A anatomia completa da pasta .claude/

Eis a vista geral: dois ficheiros de memória na raiz do projeto, e uma pasta .claude/ que serve de centro de controlo. A lógica transversal, já a conheces dos capítulos 2 e 8: cada peça existe em versão partilhada (commitada no Git, para a equipa) e em versão local (gitignorada, só para ti).

flowchart TD
  P["Raiz do projeto"] --> M1["CLAUDE.md: instruções de equipa, commitado"]
  P --> M2["CLAUDE.local.md: overrides pessoais, gitignorado"]
  P --> R[".claude/: o centro de controlo"]
  R --> S1["settings.json: permissões + config, commitado"]
  R --> S2["settings.local.json: configurações pessoais, gitignorado"]
  R --> CMD["commands/: comandos slash custom"]
  CMD --> C1["10x.md → /project:10x"]
  R --> RU["rules/: instruções modulares"]
  RU --> R1["code-style.md, api-conventions.md"]
  R --> SK["skills/: workflows auto-invocados"]
  SK --> K1["post/SKILL.md"]
  R --> AG["agents/: personas de subagents"]
  AG --> A1["code-reviewer.md, security-auditor.md"]

• CLAUDE.md (raiz) — as instruções do projeto, commitadas: toda a gente as herda (capítulo 8).
• CLAUDE.local.md (raiz) — os teus overrides pessoais, gitignorados: os teus atalhos, as tuas preferências, os teus caminhos locais.
• .claude/settings.json — permissões e configuração partilhadas com a equipa (capítulo 2).
• .claude/settings.local.json — as tuas permissões locais, gitignoradas.
• .claude/commands/ — os teus comandos slash personalizados: um ficheiro nome.md torna-se /project:nome.
• .claude/rules/ — ficheiros de instruções modulares (estilo de código, convenções de API…) referenciados a partir do CLAUDE.md.
• .claude/skills/ — os workflows auto-invocados com o seu SKILL.md (capítulo 3).
• .claude/agents/ — as personas de subagents especializados (capítulo 6).

O par CLAUDE.md / CLAUDE.local.md merece uma precisão, porque resolve um problema real de equipa. O primeiro carrega a lei comum: convenções, estrutura, salvaguardas. O segundo carrega as tuas particularidades: «as minhas capturas de ecrã estão em ~/Desktop/capturas», «responde-me em português», «uso este alias». Sem esta separação, cada membro da equipa poluiria a memória comum com os seus detalhes pessoais — ou pior, esmagaria os dos outros a cada commit.

As rules: dividir a lei em módulos

No capítulo 8, dissemos-te para manter o CLAUDE.md curto. Mas que fazer quando as convenções se acumulam — estilo de escrita, convenções de nomenclatura dos ficheiros, regras de API? A resposta: a pasta .claude/rules/. Cada tema torna-se um ficheiro dedicado (code-style.md, api-conventions.md, testing.md), e o CLAUDE.md limita-se a referenciá-los. O Claude carrega a regra pertinente quando o assunto o justifica.

Para a Lea, isto dá por exemplo um rules/redacao.md (as regras de escrita detalhadas que transbordavam do brand-voice.md) e um rules/publicacao.md (horários, formatos de imagens por plataforma, política de hashtags). O benefício é o mesmo de qualquer código: módulos curtos e focados são mais fáceis de manter do que um ficheiro monolítico — e podes adicionar mais sem inchar o contexto de cada sessão.

SKILL.md: conteúdo de referência ou conteúdo de tarefa?

Agora que escreveste vários skills, vamos ganhar altura. Um ficheiro SKILL.md pode conter quaisquer instruções, mas na prática existem dois grandes tipos — e distingui-los ajudar-te-á a escrever skills mais nítidos. O conteúdo de referência acrescenta conhecimentos que o Claude aplica ao teu trabalho em curso: contexto de negócio, histórico da empresa, nuances da tua base de dados, guias de estilo. O conteúdo de tarefa dá instruções passo a passo para uma ação precisa: gerar código, criar slides, redigir um documento.

Um skill de referência parece uma ficha que o Claude mantém debaixo dos olhos enquanto trabalha:

---
name: contexto-marca
description: Conhecimentos sobre a marca da Lea (posicionamento, gamas, clientela). Usar para qualquer redação ou decisão de produto.
---

# A marca
- Cosméticos biológicos, fabrico francês, certificada Ecocert.
- Posicionamento: acessível e pedagógica, nunca culpabilizante.

# As gamas
- Hidratação (best-seller: creme de carité), Solar (novo), Essenciais.

# A clientela
- Mulheres 25-45 anos, sensíveis à composição, compram primeiro online.

# Nuances importantes
- Nunca prometer resultados dermatológicos (restrição legal).
- «Natural» está banido: demasiado vago, preferir «certificado biológico».

Um skill de tarefa, por sua vez, é um procedimento: etapas ordenadas, critérios de saída, formatos impostos. O teu /post do capítulo 3 é um deles. Eis outro, mais curto, para veres bem o contraste:

---
name: newsletter
description: Redige a newsletter semanal no formato da casa. Usar quando o utilizador pede a newsletter.
---

# Etapas
1. Lê o registo dos posts da semana (logs/posts.md).
2. Seleciona os 3 posts com mais engagement.
3. Redige: uma introdução de 2 frases, os 3 posts resumidos, um CTA para a loja.
4. Aplica o brand-voice.md.
5. Escreve o resultado em newsletters/AAAA-MM-DD.md e pede validação.

# Critérios de saída
- Menos de 300 palavras. Um único CTA. Nenhuma palavra proibida.

Muitos bons skills misturam os dois — um procedimento que se apoia em conhecimentos — mas sabe sempre qual domina. Se não conseguires escrever as «Etapas», é provavelmente um skill de referência disfarçado: separa o conhecimento (referência) da ação (tarefa), e faz com que um referencie o outro. É exatamente o que fizemos no capítulo 4 com o brand-voice.md.

Os «comandos secretos»: a verdade por trás do mito

Talvez te tenhas cruzado com aqueles visuais virais: «os códigos secretos do Claude — /godmode, /10x, /devil…». Vamos pôr as coisas em pratos limpos: não são comandos nativos. Escreve /devil numa instalação virgem, não acontecerá nada. Mas a ideia por trás do mito é excelente, e tens agora toda a bagagem para a compreender: são comandos slash personalizados que qualquer pessoa pode criar em .claude/commands/ — prompts reutilizáveis a que se dá um nome.

O mecanismo é de uma simplicidade desarmante: um ficheiro Markdown .claude/commands/10x.md torna-se o comando /project:10x. O conteúdo do ficheiro é o prompt enviado ao Claude, e a palavra-chave $ARGUMENTS é substituída pelo que escreves a seguir ao comando. Sem YAML obrigatório, sem estrutura imposta: é o mais leve dos mecanismos de extensão.

# Criar a pasta dos comandos do projeto
mkdir -p .claude/commands

# Cada ficheiro torna-se um comando:
#   .claude/commands/10x.md      -->  /project:10x
#   .claude/commands/devil.md    -->  /project:devil

# Os comandos pessoais vivem na tua pasta de utilizador:
#   ~/.claude/commands/brief.md  -->  /user:brief

Constrói a tua biblioteca: os 9 comandos da Lea

Eis a biblioteca que a Lea construiu, ficheiro a ficheiro. Não os copies cegamente: lê cada prompt, compreende o que ele restringe, e adapta-o à tua prática. /10x — o seu preferido para musculação dos ganchos do Twitter antes da publicação:

---
description: Reescreve um texto para o tornar 10x mais impactante
---

Reescreve este texto para o tornar 10x mais impactante:
- corta cada palavra que não carrega sentido
- começa pela ideia mais forte, não pelo contexto
- uma ideia por frase, voz ativa
- mantém o meu tom (brand-voice.md), não inventes nenhum facto
- propõe 3 variantes, da mais sóbria à mais audaciosa

Texto: $ARGUMENTS

/brief — a resposta mais curta possível, zero enchimento. A Lea usa-o quando quer um facto, não uma exposição:

Responde à pergunta seguinte da forma mais curta possível.
Sem introdução, sem advertências, sem resumo final.
Se a resposta couber numa palavra ou num número, dá uma palavra ou um número.

Pergunta: $ARGUMENTS

/explainlikeim5 — a explicação ultra simples. Precioso quando um prestador lhe envia jargão técnico:

Explica o conceito seguinte como a uma criança de 5 anos:
- uma analogia da vida quotidiana
- frases curtas, nenhum jargão
- termina com «numa frase: ...»
- depois acrescenta o nível acima: a mesma explicação para um adulto curioso, em 3 frases

Conceito: $ARGUMENTS

/devil — o advogado do diabo versão séria: um «steelman», ou seja, a melhor defesa possível da posição oposta, não uma caricatura. A Lea lança-o sistematicamente antes de publicar um post comprometido sobre ecologia — mais vale descobrir a objeção no seu terminal do que nos comentários:

---
description: Steelman da posição oposta, para testar um argumento antes da publicação
---

Faz de advogado do diabo sobre a posição seguinte.
Constrói o STEELMAN da posição oposta: a sua versão mais forte,
mais honesta, defendida por alguém inteligente e de boa-fé.
- 3 contra-argumentos sólidos, ordenados do mais forte ao mais fraco
- para cada um: como eu poderia responder-lhe honestamente
- termina com: o que eu deveria matizar na minha posição inicial

A minha posição: $ARGUMENTS

/critique — encontra as falhas e propõe melhorias concretas, sem complacência:

Critica o trabalho seguinte sem nenhuma complacência:
- 5 falhas precisas, ordenadas por gravidade (bloqueante / importante / detalhe)
- para cada falha: uma correção concreta, não um conselho vago
- o que está bom e deve ser mantido (2 pontos no máximo)
- veredicto final: publicável tal como está, sim ou não, e porquê

Trabalho a criticar: $ARGUMENTS

/pitch — o pitch de 30 segundos, cliente ou investidor. A Lea usa-o para preparar as suas reuniões com lojas e os seus pedidos de financiamento:

Transforma o que se segue num pitch de 30 segundos (75 palavras no máximo):
- estrutura: problema vivido, solução, prova, apelo à ação
- nenhum superlativo vazio (líder, único, revolucionário)
- uma frase de gancho que cria curiosidade desde o primeiro segundo
- dá 2 versões: uma para um cliente, uma para um investidor

Tema: $ARGUMENTS

/compare — a análise lado a lado em tabela, para decidir depressa entre duas opções (duas ferramentas de agendamento de posts, dois fornecedores de embalagens…):

Compara as opções seguintes lado a lado:
- tabela: critérios em linhas, opções em colunas
- critérios impostos: custo, tempo de implementação, riscos, reversibilidade
- acrescenta os critérios específicos do tema
- por baixo da tabela: a tua recomendação em 2 frases, com a condição
  que a faria pender para a outra opção

Opções: $ARGUMENTS

/scout — o batedor: riscos e ângulos mortos de um plano, antes de te comprometeres:

---
description: Deteta os riscos e ângulos mortos de um plano antes do compromisso
---

Analisa este plano como um batedor prudente:
- 5 riscos concretos, com para cada um: probabilidade (baixa/média/alta),
  impacto, e sinal de alerta precoce a vigiar
- 3 ângulos mortos: as perguntas que não estou a fazer e que deveria
- o cenário de falha mais provável, contado em 3 frases
- as 2 proteções mais baratas a implementar desde já

Plano: $ARGUMENTS

/teacher — o modo mentor: o Claude não executa, ensina, questiona e debate. A Lea usa-o para subir de nível em vez de apenas delegar:

Passa para modo mentor sobre o tema seguinte.
NÃO faças o trabalho por mim:
- explica o conceito-chave partindo do que eu provavelmente já sei
- faz-me uma pergunta de cada vez para verificar a minha compreensão
- quando eu me enganar, não dês a resposta: guia-me até ela
- termina a sessão com 3 pontos a reter e um exercício para fazer sozinha

Tema: $ARGUMENTS

Comando slash ou skill: como escolher?

A pergunta a fazer: «é um carimbo ou um processo?» Um carimbo — uma transformação aplicada a um texto que forneces — dá um comando slash perfeito. Um processo — várias etapas, ficheiros a ler e a escrever, validações — merece um skill. E os dois combinam-se: a Lea lança /project:devil sobre um rascunho produzido pelo /post, depois /project:10x sobre o gancho escolhido. A caixa de ferramentas não substitui a fábrica; equipa-a.

A rotina da Lea, versão equipada

Concretamente, eis o aspeto atual de uma publicação comprometida na casa da Lea: o /post gera o rascunho na sua voz; o /project:devil testa o argumento e revela a objeção mais forte; ela matiza uma frase; o /project:10x propõe três ganchos mais impactantes; ela escolhe um; o quality gate verifica tudo; publicação. Quatro comandos, cinco minutos, e um post mais sólido do que o que ela escrevia numa hora — porque cada elo codifica uma expertise que ela já não tem de mobilizar de cabeça.