Um repositório pode dizer ao agente de programação que nunca implante em produção e ainda deixar disponíveis o comando e as credenciais de produção. A frase comunica intenção, mas não retira a capacidade. A estrutura de quatro partes da Tessl é útil porque separa esse papel consultivo de procedimentos e controles com comportamentos diferentes de carregamento e aplicação.
Ela organiza arquivos da equipe em contexto persistente, regras por caminho, skills reutilizáveis e hooks de ciclo de vida. Os exemplos concretos usam Claude Code, não um formato universal de configuração. A questão arquitetural é qual conhecimento deve estar sempre presente, qual procedimento carregar só quando necessário e qual operação perigosa bloquear fora do julgamento do modelo.
Quatro camadas são contratos diferentes, não quatro cópias da política
CLAUDE.md fornece contexto comum às tarefas: comandos de compilação, convenções de diretórios, limites de arquitetura e expectativas de testes. O gerenciador de pacotes de um serviço ou a convenção de migrações somente por acréscimo podem ficar ali. O arquivo raiz funciona melhor como panorama ou índice do que como manual completo de todas as exceções.
Regras específicas em .claude/rules/ podem carregar instruções por padrões de caminho. Uma regra de validação de API não precisa disputar atenção durante uma mudança de documentação. Uma regra transversal pode cobrir handlers ou migrações em vários pacotes sem reproduzir o mesmo parágrafo em cada diretório.
Capacidades reutilizáveis empacotam um procedimento mais longo numa pasta com SKILL.md, metadados, instruções e scripts ou referências de apoio. O panorama pode apontar para o processo de release, enquanto a skill correspondente mantém as verificações ordenadas. Claude Code carrega inicialmente nome e descrição; as instruções completas entram no contexto quando relevantes ou explicitamente invocadas.
Hooks associam comportamento a eventos do ciclo de vida por configurações ou mecanismos relacionados. Uma verificação anterior à ferramenta pode inspecionar a operação proposta; outra após edição pode formatar ou validar; uma de conclusão pode exigir evidências antes de encerrar. Isso é diferente de acrescentar outra instrução que o modelo precisa lembrar.
O argumento de propriedade da Tessl é transformar esse conhecimento num ativo versionado do repositório. Engenheiros podem inspecionar diferenças, atribuir responsáveis, revisar alterações, reverter uma regra ruim e oferecer o mesmo contexto a novas sessões. O provedor continua responsável pelo modelo hospedado e pelo runtime. Possuir arquivos não significa controlar todo mecanismo de aplicação.
O contexto fica caro quando vira banco de políticas
As equipes costumam começar com um arquivo porque ele melhora imediatamente a escolha de comandos e nomes. Depois acumulam segurança, releases, convenções de frontend e exceções pessoais até toda sessão carregar tudo. O material permanente compete com detalhes da tarefa, código, resultados das ferramentas e histórico da conversa. Mais texto não significa adesão mais forte.
A orientação citada da Anthropic recomenda manter CLAUDE.md abaixo de 200 linhas, atribuir um responsável e revisá-lo como código. O ponto é atenção e manutenção, não uma garantia vinculada à contagem. Uma instrução curta pode ser mal interpretada; mover uma restrição importante para cima não a torna obrigatória.
Arquivos de instrução aninhados podem carregar quando o agente acessa a parte pertinente da árvore. Regras por caminho tratam outro caso: uma preocupação abrange vários diretórios. Ambos reduzem contexto irrelevante, mas exigem compreender carregamento, correspondência e precedência no runtime utilizado.
A classificação é funcional. Fatos do projeto e convenções que exigem julgamento pertencem ao contexto; operações repetíveis com várias etapas, a skills; ações proibidas, a permissões, verificações bloqueadoras ou isolamento mais forte. Sessões longas, conflitos e texto hostil podem afetar a adesão. Ver uma frase de política prova sua existência, não sua taxa de aplicação.
O hook pode sempre disparar sem decidir de forma determinística
O modelo interpreta instruções persistentes, regras por escopo e procedimentos de skills. Um hook difere porque o runtime o inicia no evento configurado, sem esperar que o modelo recorde uma lista. Uma verificação PreToolUse pode inspecionar a chamada antes da execução e devolver um bloqueio quando o comando viola a política.
Entretanto, o handler determina como a decisão ocorre. Handlers de comando executam scripts; handlers de prompt e agente podem usar julgamento de modelo. Um hook iniciado de modo confiável ainda pode chegar a uma conclusão probabilística. Condições diretamente avaliáveis por software são candidatas melhores a verificações por comando do que à opinião de outro modelo.
Para arquivos gerados, a orientação explica por que a edição é desencorajada, enquanto uma verificação prévia consciente do alvo rejeita a escrita proibida. Para implantação, a skill descreve a rota aprovada e permissões ou hooks impedem o atalho direto. Explicação e barreira se reforçam porque resolvem problemas diferentes.
Permissões definem regras de autorização e negação para ferramentas e comandos; nos controles citados do Claude Code, negações correspondentes prevalecem sobre autorizações. Hooks podem avaliar condições mais complexas, mas ferramenta permitida ou verificação aprovada não significam acesso irrestrito ao sistema operacional. Credenciais limitadas, contêineres, branches protegidas e montagens somente de leitura continuam relevantes para consequências graves.
A automação pós-edição também precisa de proporcionalidade. Formatar ou validar de modo direcionado pode ser barato a cada edição; executar a suíte inteira sempre pode obstruir o trabalho. Verificações maiores podem ocorrer no commit ou na conclusão. Um hook de parada deve evitar exigir continuação repetida sem caminho útil, transformando a barreira numa repetição dispendiosa.
Trate o plano de controle como código que também pode causar dano
Hooks são infraestrutura executável. Um script defeituoso pode vazar dados, bloquear trabalho legítimo ou adicionar latência a cada evento. A propriedade do repositório dá responsabilidade pela manutenção, não torna confiável uma configuração desconhecida. Confiança no workspace, revisão e execução isolada continuam necessárias.
A possibilidade de alteração cria outra fronteira. Se o agente pode editar os próprios arquivos que o restringem, uma mudança rotineira pode enfraquecer uma regra vizinha ou desativar a verificação. Configurações críticas precisam de propriedade e revisão mais fortes, branches protegidas ou execução somente de leitura, não da disposição do agente de preservar as próprias restrições.
Um bloqueio por padrão de comando pode ignorar uma tarefa de pacote equivalente, script indireto ou outra ferramenta com o mesmo efeito. Os testes devem tentar ações proibidas por rotas alternativas, não apenas repetir o exemplo para o qual a regra foi criada. Trabalho legítimo também precisa de testes: negações amplas incentivam exceções, desvios ou desativação completa.
Texto não confiável de issues, documentação, dependências e artefatos gerados pode conter prompt injection. O modelo pode interpretar essas instruções junto com a orientação do repositório. Permissões determinísticas e execução isolada limitam as capacidades resultantes; só a prosa não cria essa barreira de segurança.
Skills preservam procedimentos quando são mantidas e ativadas
Skills tornam conhecimento de releases, migrações, atualização de dependências e incidentes inspecionável além da conversa de um engenheiro. Um validador do repositório pode cuidar de uma subtarefa determinística enquanto o agente exerce julgamento. Uma base técnica pesquisável preserva decisões e documentos de apoio; a skill define como o conhecimento escolhido se torna procedimento.
Presença não é ativação. As descrições devem explicar quando a skill se aplica, e avaliações precisam verificar que o procedimento correto realmente carregou. A invocação explícita reduz ambiguidade em trabalhos sensíveis. Como comandos e arquitetura mudam, responsáveis, exemplos e ciclos de revisão são requisitos de manutenção, não acabamento opcional.
Duplicar uma regra na raiz, em vários arquivos por escopo e em múltiplas skills cria versões concorrentes de autoridade. Um local principal para cada fato, com links ou índices curtos nos demais, facilita revisar mudanças. Configurações pessoais e organizacionais gerenciadas ainda podem conflitar com o repositório. É preciso enxergar quais arquivos carregaram e quais regras ou permissões influenciaram a ação.
Portabilidade e governança precisam ser demonstradas pelo comportamento
Outros agentes de programação oferecem conceitos semelhantes de instrução, workflow e controle de eventos, mas os diretórios e a semântica diferem. O interesse comercial da Tessl em contexto reutilizável não torna seus caminhos concretos do Claude Code um padrão portátil. Até um formato Markdown comum deve preservar disparo, escopo, precedência e bloqueio para oferecer portabilidade significativa.
Avaliações repetíveis devem começar em ambientes limpos, apresentar as mesmas tarefas em vários ensaios e registrar configurações carregadas, decisões de ferramentas e resultados. Devem verificar adesão, ativação correta de skills, operações bloqueadas e trabalho normal bem-sucedido. Repetição independente vale mais que uma demonstração convincente.
Três avanços fortaleceriam a estrutura: avaliações práticas de instruções, formatos de capacidades com semântica precisa entre runtimes e interfaces que distingam conselho, disparo garantido e negação real. Logs devem tornar compreensível por que uma operação foi permitida ou rejeitada. Quantidade de arquivos e volume de documentação não substituem esses resultados.
O produto útil é um mapa de controle explicável. Outro engenheiro deve identificar o contexto que orienta a decisão, o procedimento que aparece sob demanda e o limite externo capaz de impedir um erro importante. Arquivos da equipe tornam o mapa revisável e recuperável. Autonomia segura ainda depende de aplicação testada e da infraestrutura ao redor.
Fontes e leitura relacionada
Estrutura de quatro camadas da Tessl · Orientação da Anthropic · Memória e carregamento do projeto · Handlers de hooks · Permissões de ferramentas · Empacotamento e invocação de skills · Leitura relacionada: bases técnicas pesquisáveis