Anatomia da Pasta .claude

Existe um gênero literário próprio da internet técnica: o tutorial confiante sobre uma ferramenta que o autor usa há três horas. É um gênero simpático, cheio de boa vontade, e quase sempre errado em pelo menos um detalhe que depois vira lenda. A pasta .claude tem sido vítima recorrente desse gênero.

Minha vez. Eu também sou da família, eu também posso errar. Se você chegou aqui achando que ia encontrar uma receita de prompt matador, que resolve qualquer problema, economiza dinheiro e faz de você o novo guru da empresa. Está no lugar errado. Conselho de amigo: continue procurando.

A causa dos erros que vemos por aí é sempre a mesma. Alguém abre a pasta, olha os arquivos, monta um modelo mental plausível e publica. O modelo mental plausível tem a inconveniente propriedade de ser plausível, e não de ser verdadeiro. Para todo problema complexo existe uma solução, clara, simples, direta e errada.

Neste ponto da história a frase “esses arquivos são automaticamente ignorados pelo git” vira mandamento, e uma legião de desenvolvedores comita a senha do banco de dados de homologação achando que o Claude cuidou disso.

Tentando não errar catastroficamente, este texto nasceu de uma leitura crítica do artigo de Akshay Pachaar sobre a anatomia da pasta .claude [1]. O texto de Akshay oferece um bom mapa inicial. Eu uso seu artigo como pauta e como ponto de partida, mas reorganizo a explicação, aperfeiçoo pontos que merecem mais cuidado, acrescento camadas omitidas e confronto as afirmações com a documentação oficial do Claude Code. Em outras palavras: a inspiração está creditada, e a responsabilidade pelos acertos e teimosias daqui é minha. Pobre de mim, pobre de mim.

A tese deste humilde artigo é simples: a pasta .claude não é uma gaveta de truques. Ela é um pequeno sistema de governança. Parte dela orienta o modelo. Parte dela configura permissões. Parte dela empacota procedimentos. Parte dela conecta o Claude ao mundo ao redor do código. Misturar essas funções é o caminho mais curto para um repositório cheio de superstição automatizada.

A primeira pergunta: quem tem autoridade?

Antes de listar arquivos, convém perguntar quem manda em quem. Isso evita uma quantidade surpreendente de confusão e mal-entendidos.

Os caras da Anthropic não são amadores despreparados. Existem pelo menos quatro níveis relevantes:

1. política gerenciada;
2. configuração do usuário;
3. configuração do projeto;
4. configuração local da máquina.

A política gerenciada é a camada corporativa. Ela vem de MDM, Group Policy, Ansible ou mecanismo equivalente. É o lugar onde a organização deve dizer: “neste ambiente, certas instruções valem sempre”. Não é uma preferência do desenvolvedor. Não é uma convenção do time. É política.

Os arquivos de política ficam em locais fixos do sistema:

macOS:        /Library/Application Support/ClaudeCode/CLAUDE.md
Linux e WSL:  /etc/claude-code/CLAUDE.md
Windows:      C:\Program Files\ClaudeCode\CLAUDE.md

Abaixo disso vem o nível do usuário, em ~/.claude/. Ali moram as suas preferências pessoais, comandos globais, skills pessoais, agentes pessoais, histórico e memória automática. Depois vem o projeto, normalmente com CLAUDE.md, .claude/settings.json, .claude/rules/, .claude/hooks/, .claude/skills/ e .claude/agents/. Por fim, vêm os arquivos locais, como CLAUDE.local.md e .claude/settings.local.json.

Figura 1: Os quatro escopos principais da configuração do Claude Code. O ponto importante é separar aquilo que orienta o modelo daquilo que a ferramenta realmente impõe.

A ordem de carregamento das instruções vai do mais amplo ao mais específico. A consequência prática é bonita: você consegue ter princípios globais, regras do time e preferências locais sem colocar tudo no mesmo arquivo. A consequência política também é importante: instruções gerenciadas pela organização não são algo que o usuário desliga quando fica inconveniente. A vida adulta chega para todos, inclusive para o prompt engineering.

A segunda pergunta: isto orienta ou executa?

O erro mais comum ao usar Claude Code é tratar todos os arquivos da pasta como se fossem leis. Não são. Nenhum deles é.

CLAUDE.md, regras e imports orientam o modelo. Eles dizem ao Claude como pensar sobre o projeto. Já settings.json, permissões e hooks configuram comportamento da ferramenta. Eles dizem ao sistema o que pode rodar, o que deve pedir confirmação e o que deve ser bloqueado.

Essa diferença parece pedante até você precisar dela. Escrever “sempre rode os testes antes de terminar” em CLAUDE.md é uma instrução. Criar um hook de Stop que roda os testes e bloqueia a finalização com código de saída 2 é controle operacional. Um depende de aderência do modelo. O outro depende do sistema operacional.

Regra simples:

CLAUDE.md e rules/   -> orientam o modelo
settings.json        -> configura permissões e comportamento
hooks/               -> executa controles determinísticos
skills/ e commands/  -> empacotam procedimentos reutilizáveis
agents/              -> delegam trabalho a contextos especializados
.mcp.json            -> conecta ferramentas externas ao projeto

Guarde essa tabela. Escreva em um pedaço de papel, se for necessário. Ela será mais útil que decorar a árvore de pastas.

CLAUDE.md: o manual de convivência

O CLAUDE.md é o arquivo de maior alavancagem do projeto. Quando uma sessão começa, o Claude Code lê as instruções relevantes e passa a usá-las como contexto de trabalho. Ele não transforma o arquivo em firmware do universo. Ainda. Ele lê, tenta obedecer e geralmente é mais eficiente e efetivo quando as instruções são concretas.

O que colocar ali?

Coloque comandos de build, teste e lint. Coloque decisões de arquitetura que não aparecem olhando para três arquivos aleatórios. Coloque convenções de importação, tratamento de erro, nomenclatura e estrutura dos módulos principais. Coloque armadilhas reais, como “os testes usam banco local verdadeiro” ou “nunca importe nada que não esteja nas pastas seguras”.

O que não colocar?

Não coloque aquilo que já pertence a um linter, formatador ou compilador. Não copie documentação inteira. Não escreva um manifesto filosófico da arquitetura só porque você acordou tocado pelas musas da abstração. O Claude precisa de instrução operacional, não de uma tese de livre-docência escondida no repositório.

Isso mesmo, eu estou falando com você! Sim, eu li seu CLAUDE.MD!

A recomendação prática é manter cada CLAUDE.md abaixo de duzentas linhas. Arquivos grandes demais consomem contexto e, pior, tornam difícil distinguir o essencial do decorativo. Um exemplo enxuto:

# Projeto: Atlas API

## Comandos
pnpm dev             # servidor de desenvolvimento
pnpm test            # testes unitarios e integracao leve
pnpm lint            # ESLint + Prettier
pnpm build           # build de producao

## Arquitetura
- API REST em Fastify, Node 20
- PostgreSQL via Prisma
- Rotas ficam em src/routes/
- Casos de uso ficam em src/use-cases/

## Convenções
- Validação de entrada com zod
- Retorno HTTP no formato { data, error }
- Logs sempre pelo modulo src/logger
- Nunca exponha stack trace ao cliente

## Cuidado
- Testes de integração usam banco local real
- Rode pnpm db:test:reset antes de depurar falhas estranhas

Novamente, sim. Você pensou correto. Eu estou trabalhando em um projeto com TypeScript, Node, etc. Ninguém é perfeito.

A atenta leitora deve memorizar: vinte linhas boas valem mais que duzentas linhas aspiracionais. A engenharia tem dessas crueldades. Nem o Claude liga para os seus sentimentos.

CLAUDE.local.md: preferência pessoal não é norma do time

CLAUDE.local.md serve para o que é seu, não do repositório. Um runner de teste diferente. Uma URL de sandbox. Um padrão local para abrir arquivos. Uma observação que só faz sentido na sua máquina ou na sua parte do projeto.

Aqui mora uma imprecisão popular importante. Dizer que CLAUDE.local.md e .claude/settings.local.json são “automaticamente ignorados pelo git” é confortável demais. O comportamento seguro é mais cuidadoso: quando o próprio Claude Code cria esses arquivos, ele pode configurar o git para ignorá-los. Quando você cria na mão, o git não recebe a iluminação espiritual. Adicione explicitamente ao .gitignore.

CLAUDE.local.md
.claude/settings.local.json

A mágica que depende de quem digitou o arquivo primeiro não é confiável. É incidente esperando liberação de agenda.

Imports e rules/: contexto permanente contra contexto condicional

O CLAUDE.md pode importar outros arquivos com @caminho/para/arquivo. Isso é ótimo para organização. Não é ótimo para economia de contexto.

Se você escreve:

@docs/padroes-de-api.md
@docs/testes.md

esses arquivos entram junto com o arquivo que os referencia. Você espalhou o peso em mais lugares. Às vezes isso é exatamente o que você quer, porque a modularidade também tem o seu valor. Mas não confunda modularidade com carregamento preguiçoso.

Um uso culturalmente útil dos imports aparece quando o repositório já mantém um AGENTS.md para outros agentes. O Claude Code lê CLAUDE.md, não AGENTS.md. Em vez de manter duas verdades divergentes, crie um CLAUDE.md pequeno com @AGENTS.md e trate o arquivo importado como fonte compartilhada. Viu como o sentido nasce do contexto?

Para economizar contexto, o instrumento mais interessante é a pasta .claude/rules/, principalmente quando usada com escopo de caminho. Regras sem paths carregam sempre. Regras com paths carregam quando o Claude trabalha com arquivos que casam com o padrão.

---
paths:
  - "src/routes/**/*.ts"
  - "src/use-cases/**/*.ts"
---
# Regras de API

- Todo handler retorna { data, error }
- Validação de corpo de request com zod
- Nunca exponha detalhes internos de erro ao cliente
- Sempre registre erros internos no logger antes de responder ao cliente

Agora a regra de API não precisa poluir o contexto quando a tarefa é ajustar um componente React, escrever documentação ou mexer no CSS. Isso parece pequeno até você trabalhar num monorepo grande, onde cada pasta tem uma teologia própria.

Figura 2: Imports, regras com paths e skills resolvem problemas diferentes. Só as regras com escopo e as skills realmente evitam carregar tudo no contexto inicial.

A pasta .claude/rules/ aceita glob, padrões como src/**/*.{ts,tsx} e organização recursiva. Também aceita symlinks, o que permite manter um conjunto comum de regras em um lugar só e reaproveitá-lo em vários projetos. Existe ainda ~/.claude/rules/ para preferências pessoais carregadas antes das regras do projeto, com prioridade menor. Regra do projeto ganha de regra pessoal. Como deve ser, porque o repositório não é seu diário pessoal.

settings.json: permissões são engenharia, não conselho

O .claude/settings.json controla permissões, hooks e parte importante da configuração do projeto. É onde você define o que Claude pode executar sem perguntar, o que ele nunca deve executar e o que fica no meio-termo.

Um exemplo razoável:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(pnpm *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Read",
      "Write",
      "Edit"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

A linha $schema dá autocomplete e validação em editores como VS Code e Cursor. A lista allow deve ser econômica: comandos de execução do projeto, git de leitura e ferramentas de arquivo que fazem sentido no seu fluxo. A lista deny deve bloquear ações que você não quer discutir no calor da tarefa: comandos destrutivos, rede direta quando não for necessária, .env, segredos e equivalentes.

O que não está em allow nem em deny cai no território saudável da pergunta. Esse intervalo é valioso. Ele evita a fantasia de que você consegue prever todo comando possível sem transformar o arquivo em um romance policial.

Um detalhe de segurança: permissões comitadas no .claude/settings.json não deveriam conceder poder silenciosamente a um repositório recém-clonado. O fluxo de confiança do workspace existe justamente para impedir que um projeto baixado da internet diga “pode rodar tudo, confia”. Já .claude/settings.local.json é seu, local, e por isso serve para exceções pessoais.

Hooks: quando você quer garantia, use shell

Hooks são manipuladores de evento. Eles disparam em pontos específicos do fluxo do Claude Code e executam comandos. Essa frase deveria bastar para despertar respeito, porque “executa comandos” é o tipo de expressão que merece café forte e revisão cuidadosa e oração.

Os eventos mais importantes são:

• PreToolUse: antes de uma ferramenta rodar;
• PostToolUse: depois que uma ferramenta teve sucesso;
• Stop: quando o Claude acha que terminou;
• UserPromptSubmit: quando o usuário envia uma mensagem;
• Notification: para alertas;
• SessionStart e SessionEnd: para preparar ou limpar contexto.

Para eventos de ferramenta, matcher restringe o gatilho. Bash mira comandos de shell. Write|Edit|MultiEdit mira alterações de arquivo. Sem matcher, casa com tudo.

O detalhe que separa segurança de teatro é o código de saída:

0 -> sucesso
1 -> erro registrado, mas nao bloqueante
2 -> bloqueia e devolve stderr ao Claude

Usar saída 1 em hook de segurança é uma pequena tragédia. O script parece bravo, faz cara de fortão, registra um erro e deixa a ação passar. Para bloquear, é saída 2.

Uma configuração típica:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/bash-guard.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/format-touched-file.sh"
          }
        ]
      }
    ]
  }
}

O bash-guard.sh pode ler o JSON pelo stdin, examinar o comando e bloquear padrões como rm -rf /, git push --force main ou DROP TABLE. O formatador pode rodar depois de edições. O Stop pode rodar testes e impedir que o Claude declare vitória com a suíte vermelha.

Figura 3: Hooks colocam pontos de controle fora da boa vontade do modelo. Para bloquear de verdade, o script precisa sair com código 2.

Há uma armadilha especial no Stop: confira stop_hook_active no payload. Sem isso, o hook pode bloquear, o Claude tenta corrigir, o hook bloqueia de novo, e você inventa uma máquina de movimento perpétuo movida a frustração. Na segunda tentativa, deixe parar.

Hooks não recarregam no meio da sessão. PostToolUse não desfaz nada, porque a ferramenta já rodou. Hooks também disparam para ações de subagentes. E, principalmente, executam com suas permissões de usuário, sem sandbox mágico. Valide JSON, use caminhos absolutos e coloque aspas nas variáveis de shell. Um hook mal escrito é automação com dentes.

Para depurar carregamento de instruções, existe ainda o evento InstructionsLoaded. Ele é útil quando uma regra com paths não aparece no momento em que você esperava, ou quando o projeto tem camadas demais e você já não sabe qual arquivo está sussurrando no ouvido do modelo.

Cuidado com os Hooks. Esta semana, atendi uma empresa com um problema inusitado: havia uma linha com git restore . em um arquivo shell que rodava apenas quando um hook específico rodava. Demorei horas para entender o que estava errado. Imagine o que mais há por aí.

Capacidades reutilizáveis: commands, skills e agents

Depois de instruir e controlar, vem o terceiro problema: reutilizar procedimentos. Aqui entram comandos, skills e agentes.

Comandos personalizados são atalhos explícitos. Arquivos markdown em .claude/commands/ viram comandos de barra. Um arquivo .claude/commands/revisar-issue.md pode virar /revisar-issue. É um bom lugar para prompts recorrentes e pequenos rituais de trabalho.

Skills são mais fortes. Cada skill vive em uma pasta própria, com SKILL.md e, se necessário, arquivos auxiliares:

.claude/skills/
├── auditoria-seguranca/
│   ├── SKILL.md
│   └── checklist.md
└── release/
    ├── SKILL.md
    └── templates/
        └── notas.md

Um SKILL.md tem frontmatter que descreve quando usar aquela capacidade:

---
name: auditoria-seguranca
description: Auditoria de segurança em código, permissões e configuração.
allowed-tools: Read, Grep, Glob
---
Revise a base de código procurando:

1. credenciais expostas;
2. falhas de autenticação e autorização;
3. riscos de SQL injection e XSS;
4. configurações inseguras.

Use @checklist.md como referência interna.

A diferença útil não é “comando contra skill”, como se fossem religiões rivais. É arquivo único contra pacote. O comando resolve um atalho. A skill empacota procedimento, anexos e critérios de acionamento. Skills pessoais ficam em ~/.claude/skills/.

Agentes são outra coisa. Um agente em .claude/agents/ define uma persona especializada, com prompt próprio, ferramentas permitidas e preferência de modelo:

---
name: revisor-codigo
description: Revisor sênior focado em bugs, casos de borda e manutenibilidade.
model: sonnet
tools: Read, Grep, Glob
---
Você revisa código com foco em correção.

Ao revisar:
- aponte bugs antes de estilo;
- cite casos de borda;
- sugira correções concretas;
- só fale de performance quando importar em escala.

Quando acionado, o agente trabalha em contexto próprio e retorna um resumo. Isso evita poluir a conversa principal com milhares de tokens de exploração. O campo tools importa: um auditor que só precisa ler não deve escrever. Um agente com menos poder é mais fácil de confiar. Eis uma frase que vale também fora da computação.

MCP: a pasta .claude não termina na pasta .claude

Guias sobre .claude costumam esquecer o MCP. É uma omissão grande, porque o Model Context Protocol é a forma oficial de conectar Claude Code a ferramentas externas: GitHub, bancos de dados, navegadores, documentação interna, sistemas de tarefa e o que mais fizer sentido.

A configuração de projeto normalmente fica em .mcp.json, na raiz:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {}
    }
  }
}

Esse arquivo é parte do contrato do projeto. Sem MCP, você está ensinando Claude a trabalhar melhor dentro do repositório. Com MCP, você está dizendo a quais sistemas externos ele pode se conectar. É outra classe de poder, e portanto outra classe de responsabilidade.

Com grandes poderes vêm…

Memória automática e o comando /memory

Além do que você escreve, o Claude também pode acumular memória de projeto. Ele registra comandos descobertos, padrões observados, decisões recorrentes e outras notas que parecem úteis para sessões futuras.

O lugar importante fica em ~/.claude/projects/<projeto>/memory/:

~/.claude/projects/<projeto>/memory/
├── MEMORY.md
├── debugging.md
├── api-conventions.md
└── ...

MEMORY.md funciona como índice compacto. Arquivos de tópico podem ser lidos sob demanda. O diretório é local à máquina e derivado do projeto. Isso explica aquele momento curioso em que Claude parece lembrar algo que você não disse na conversa atual.

O comando /memory é a lanterna para esse porão. Ele ajuda a listar arquivos de instrução carregados, abrir memória, editar notas e entender de onde certas lembranças vieram. Quando a ferramenta parece assombrada, muitas vezes ela só está documentada em algum lugar que você esqueceu de olhar.

Monorepos: quando a raiz não basta

Em monorepo, a raiz raramente é a verdade inteira. Um pacote de frontend, um serviço de backend e uma biblioteca compartilhada podem ter regras muito diferentes.

Você pode usar CLAUDE.md e .claude/rules/ em subdiretórios para carregar instruções específicas quando Claude trabalha naquela área específica do projeto. Isso mantém o contexto mais limpo e evita que a convenção do pacote de pagamentos contamine a edição de um componente visual.

Também existe claudeMdExcludes, útil quando você quer impedir que certos CLAUDE.md acima do diretório atual sejam carregados. Em geral, coloque isso no seu .claude/settings.local.json, porque exclusão de contexto costuma ser preferência local:

{
  "claudeMdExcludes": [
    "**/monorepo/CLAUDE.md",
    "/home/user/monorepo/outro-time/.claude/rules/**"
  ]
}

A ressalva é importante: política gerenciada não entra nessa brincadeira. O que a organização impõe continua imposto.

O mapa completo

Juntando as peças:

seu-projeto/
├── CLAUDE.md                  # instruções do time
├── CLAUDE.local.md            # preferências pessoais
├── .mcp.json                  # servidores MCP do projeto
│
└── .claude/
    ├── settings.json          # permissões, hooks, configuração
    ├── settings.local.json    # overrides pessoais
    │
    ├── rules/                 # instruções modulares
    │   ├── code-style.md
    │   ├── testing.md
    │   └── api-conventions.md
    │
    ├── hooks/                 # scripts referenciados por settings.json
    │   ├── bash-guard.sh
    │   ├── format-touched-file.sh
    │   └── enforce-tests.sh
    │
    ├── commands/              # comandos de barra
    │   └── revisar-issue.md
    │
    ├── skills/                # procedimentos empacotados
    │   └── auditoria-seguranca/
    │       └── SKILL.md
    │
    └── agents/                # subagentes especializados
        ├── revisor-codigo.md
        └── auditor-seguranca.md

~/.claude/
├── CLAUDE.md                  # instruções pessoais globais
├── settings.json              # configurações globais
├── commands/                  # comandos pessoais
├── skills/                    # skills pessoais
├── agents/                    # agentes pessoais
└── projects/                  # histórico e memória automática

Esse mapa não deve virar checklist de ansiedade. Já comentei sobre o seu TDAH? Também pode deixar a TOC em casa. Nem todo projeto precisa de tudo. Na verdade, a maioria não precisa.

Uma sequência prática para começar

Se a curiosa leitora está começando do zero, pode tentar o seguinte:

Primeiro, rode /init e deixe Claude gerar um CLAUDE.md inicial. Depois, corte sem piedade. O objetivo não é preservar tudo que a ferramenta escreveu; é chegar ao essencial.

Segundo, crie .claude/settings.json com permissões mínimas. Libere comandos de build, teste e lint. Negue .env, segredos e comandos destrutivos. Deixe o resto pedir confirmação.

Terceiro, acrescente um hook pequeno e útil. O melhor candidato costuma ser um PostToolUse que formata arquivos tocados ou um Stop que roda testes. Comece simples. Segurança performática demais no primeiro dia vira decoração.

Quarto, quando CLAUDE.md começar a engordar, mova regras específicas para .claude/rules/ com paths. Esse é o momento em que você deixa de pagar contexto permanente por instrução que só vale em uma parte do código.

Quinto, só crie skills e agentes quando houver repetição real. Se você revisa segurança toda semana, empacote. Se fez uma vez para testar, respire e vá tomar água.

Sexto, use MCP quando houver ferramenta externa que realmente faça parte do trabalho. Não conecte o universo inteiro só porque a sigla é bonita.

O que fica

A pasta .claude é um protocolo de trabalho entre pessoas, repositório e agente. Ela diz ao Claude quem é o projeto, quais regras importam, quais ações são permitidas e quais capacidades estão disponíveis. Quando bem configurada, reduz conversa repetida. Quando mal configurada, automatiza confusão com uma confiança admirável.

Duas ideias merecem sobreviver. A primeira: CLAUDE.md é o começo, não o fim. Ele orienta, mas não garante. A segunda: segurança e qualidade precisam sair da prosa e entrar em configuração executável quando o risco justificar. Instruções são úteis. Hooks e permissões são outro jogo.

Comece pequeno, refine no caminho e trate a pasta como infraestrutura. Não como fetiche de ferramenta. A diferença entre esses dois estados é a diferença entre um time que usa Claude Code com clareza e um time que apenas acumulou arquivos místicos em YAML e Markdown.

Idioma

Eu fiz este texto e todos os exemplos em português. Não use português. Existem algumas dezenas de artigos indicando que os assistentes de IA usam até 70% mais tokens em português.

Se isso for verdade é um imposto que estamos pagando pelo idioma de Rubem Braga e Fernando Pessoa. Não sei se é verdade. Euzinho, de pé descalço, não fiz qualquer benchmark.

Mas, pelo sim, pelo não, prefiro escrever inglês macarrônico que pagar mais caro.

Referências

1. PACHAAR, Akshay. Anatomy of the .claude/ folder. X Articles, 2026. Disponível em: https://x.com/akshay_pachaar/status/2035341800739877091. Acesso em: 4 jul. 2026.

2. ANTHROPIC. Explore the .claude directory. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/claude-directory. Acesso em: 4 jul. 2026.

3. ANTHROPIC. How Claude remembers your project. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/memory. Acesso em: 4 jul. 2026.

4. ANTHROPIC. Claude Code settings. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/settings. Acesso em: 4 jul. 2026.

5. ANTHROPIC. Hooks reference. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/hooks. Acesso em: 4 jul. 2026.

6. ANTHROPIC. Extend Claude with skills. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/skills. Acesso em: 4 jul. 2026.

7. ANTHROPIC. Create custom subagents. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/sub-agents. Acesso em: 4 jul. 2026.

8. ANTHROPIC. Connect Claude Code to tools via MCP. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/mcp. Acesso em: 4 jul. 2026.

9. ANTHROPIC. Commands. Claude Code Docs. Disponível em: https://code.claude.com/docs/en/commands. Acesso em: 4 jul. 2026.