1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Claude Code 2.1.87 tem muitas configurações não documentadas, e é possível separar e aplicar Hooks, Skills e Agents por usuário e por projeto com arquivos em .claude/
  • Hooks fazem mais do que receber JSON via stdin e usar exit code: com campos JSON por evento no stdout, eles podem modificar comandos, decidir permissões, injetar contexto e até monitorar arquivos
  • Com os campos de Hook não documentados once, async e asyncRewake, dá para criar execuções únicas, logs de auditoria em segundo plano e fluxos assíncronos de bloqueio de segurança
  • Skills e Agents controlam modelo, effort, Hook por escopo, delegação para Agent, memória persistente, omissão de CLAUDE.md e dependências MCP por meio de frontmatter oculto
  • Auto Mode, memória automática, Dream, Magic Docs, glob de permissões e context: fork deixam o Claude Code mais próximo de um ambiente de desenvolvimento que aprende

Versão de referência e localização dos arquivos

  • O conteúdo tem como base o @anthropic-ai/claude-code@2.1.87, e recursos não documentados podem mudar entre releases
  • Campos com EXPERIMENTAL no nome foram marcados por engenheiros da Anthropic como instáveis, podendo ser removidos ou renomeados
  • Localização dos arquivos de configuração
    • Configuração pessoal: ~/.claude/settings.json
    • Configuração do projeto: .claude/settings.json
  • Localização dos Skills
    • Pessoal: ~/.claude/skills/<name>/SKILL.md
    • Projeto: .claude/skills/<name>/SKILL.md
  • Localização dos Agents
    • Pessoal: ~/.claude/agents/<name>.md
    • Projeto: .claude/agents/<name>.md
  • O costume mais adequado é colocar scripts de Hook em ~/.claude/hooks/, e para executá-los é necessário chmod +x
  • Arquivos .claude/ no nível do projeto podem ser commitados no Git e compartilhados com a equipe, enquanto arquivos pessoais em ~/.claude/ se aplicam apenas ao usuário

Hooks podem alterar o comportamento do Claude Code com JSON no stdout

  • A documentação oficial trata apenas do fluxo em que Hooks recebem JSON via stdin e bloqueiam ações com exit code 2, mas na prática também é possível alterar o comportamento do Claude Code em tempo real com campos JSON por evento no stdout
  • Campos que podem ser retornados em PreToolUse

    • updatedInput: permite reescrever a entrada antes da execução da ferramenta e mudar o comando
    • permissionDecision: permite forçar allow ou deny sem perguntar ao usuário
    • permissionDecisionReason: permite exibir na interface o motivo da decisão
    • additionalContext: permite injetar texto no contexto da conversa
  • Campos que podem ser retornados em SessionStart

    • watchPaths: configura monitoramento automático de arquivos para disparar eventos FileChanged
    • initialUserMessage: permite acrescentar conteúdo antes da primeira mensagem do usuário na sessão
    • additionalContext: permite injetar contexto que permanece durante toda a sessão
  • Campos que podem ser retornados em PostToolUse

    • updatedMCPToolOutput: permite modificar a resposta de ferramenta MCP que o Claude vê
    • additionalContext: permite injetar contexto após a execução da ferramenta
  • Campos que podem ser retornados em PermissionRequest

    • decision: permite aprovar ou negar de forma programática junto com updatedInput ou updatedPermissions
  • Hook que troca automaticamente git push por --dry-run

    • Em um Hook PreToolUse, é possível inspecionar comandos Bash e, se houver git push, usar updatedInput para adicionar --dry-run ao fim do comando
    • O Claude acha que está executando git push origin main, mas o Hook altera isso para git push origin main --dry-run antes da execução real
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/dry-run-pushes.sh"
      }]
    }]
  }
}
#!/bin/bash
INPUT=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$INPUT" | grep -q 'git push'; then
  jq -n --arg cmd "$INPUT --dry-run" '{"updatedInput": {"command": $cmd}}'
fi
  • Hook que injeta monitoramento de arquivos e contexto do Git no início da sessão

    • Um Hook SessionStart pode definir package.json, .env e tsconfig.json como arquivos monitorados e incluir o branch atual e a quantidade de arquivos sem commit no contexto da sessão
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }]
  }
}
#!/bin/bash
BRANCH=$(git branch --show-current 2>/dev/null)
CHANGES=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')

jq -n \
  --arg branch "$BRANCH" \
  --arg changes "$CHANGES" \
  '{
    "watchPaths": ["package.json", ".env", "tsconfig.json"],
    "additionalContext": "Current branch: \($branch). Uncommitted changes: \($changes) files."
  }'
  • Hook que aprova automaticamente comandos Bash somente leitura

    • Comandos como ls, cat, echo, pwd, whoami, date, git status, git log e git diff podem passar sem confirmação do usuário com permissionDecision: "allow"
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }]
    }]
  }
}
#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -qE '^(ls|cat|echo|pwd|whoami|date|git status|git log|git diff)'; then
  echo '{"permissionDecision": "allow", "permissionDecisionReason": "Safe read-only command"}'
fi

3 campos de configuração de Hook que não aparecem na documentação

  • Os campos de Hook documentados são type, command, matcher, timeout, if, statusMessage, mas o parser do código-fonte também aceita once, async, asyncRewake
  • once: true

    • Executa o Hook exatamente uma vez e depois o remove automaticamente, então é ideal para a configuração da primeira sessão
    • Dá para criar um fluxo que copia .env.example para .env se .env não existir e, depois disso, não executa de novo
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "[ -f .env ] || cp .env.example .env && echo 'Created .env from template'",
        "once": true,
        "statusMessage": "First-time setup..."
      }]
    }]
  }
}
  • async: true

    • Executa o Hook em segundo plano sem bloquear o progresso do Claude
    • Pode ser usado para registrar todos os comandos Bash em ~/.claude/audit.jsonl sem adicionar atraso à sessão
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "jq '{timestamp: now, command: .tool_input.command, session: .session_id}' < /dev/stdin >> ~/.claude/audit.jsonl",
        "async": true
      }]
    }]
  }
}
  • asyncRewake: true

    • No fluxo normal, executa em segundo plano como async, mas se terminar com exit code 2, desperta o modelo novamente e bloqueia a tarefa
    • Permite inspecionar cada arquivo escrito pelo Claude em busca de padrões hardcoded como password, secret, api_key e bloquear se forem encontrados
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/scan-secrets.sh",
        "asyncRewake": true,
        "statusMessage": "Scanning for secrets..."
      }]
    }]
  }
}
#!/bin/bash
FILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)
if grep -qE '(password|secret|api_key)\s*=' "$FILE" 2>/dev/null; then
  exit 2
fi
exit 0

Campos ocultos no frontmatter de Skill

  • A documentação cobre name, description, allowed-tools, argument-hint, when_to_use, context, mas o parser real aceita mais 6 campos adicionais
  • model

    • Dá para trocar o modelo de execução da Skill; para tarefas rápidas e baratas, use haiku, e para análises complexas, opus
---
name: quick-lint
description: Fast lint check using the cheapest model
model: haiku
effort: low
allowed-tools: Bash, Read
argument-hint: "[file]"
---
Run the project linter on: $ARGUMENTS
Detect the linter from config (eslint, ruff, clippy) and run it. Report only errors, not warnings.
  • effort

    • Controla o quanto o modelo deve pensar profundamente, com valores low, medium, high, max
    • Internamente, isso é mapeado para o sistema de effort que controla a profundidade de raciocínio por resposta
  • hooks

    • Permite definir Hooks com escopo que só são registrados quando a Skill é ativada e são removidos quando ela termina
    • Dá para usar isso para fazer verificação de tipos de forma síncrona sempre que um arquivo TypeScript for escrito, e rodar lint em segundo plano
---
name: strict-typescript
description: Write TypeScript with type checking on every save
allowed-tools: Bash, Read, Write, Edit, Grep, Glob
hooks:
  PostToolUse:
    - matcher: "Write|Edit"
      hooks:
        - type: command
          command: "~/.claude/hooks/typecheck-on-save.sh"
          statusMessage: "Type checking..."
        - type: command
          command: "~/.claude/hooks/lint-on-save.sh"
          async: true
---
Write TypeScript with strict enforcement. Every file you touch gets type-checked and linted automatically.
$ARGUMENTS
  • agent

    • Permite delegar a execução da Skill para um Agent personalizado
---
name: deep-review
description: Thorough security review delegated to the review agent
agent: security-review
---
Review the following: $ARGUMENTS
  • disable-model-invocation: true

    • Impede a invocação automática e faz com que a Skill só seja executada por chamada explícita com /skill-name, então é adequado para Skills destrutivas
  • shell: bash

    • Especifica o shell a ser usado na execução

Campos ocultos no frontmatter de Agent

  • Agents personalizados em .claude/agents/ também aceitam campos de frontmatter que não aparecem na documentação
  • color

    • É possível definir a cor da interface como uma entre red, orange, yellow, green, blue, purple, pink e gray
    • Isso ajuda a distinguir visualmente quando vários Agents estão em execução
  • memory

    • Dá ao Agent uma memória persistente entre chamadas
    • user: é mantida globalmente em todos os projetos
    • project: é mantida por projeto
    • local: é uma memória privada por projeto, excluída do Git
    • Um revisor de segurança pode acompanhar descobertas anteriores, e um revisor de código pode lembrar os padrões do usuário além de uma única sessão
---
name: codebase-guide
description: Answer questions about the codebase, learning more with each session
tools: [Read, Grep, Glob, Bash]
color: green
memory: project
---
You are a codebase guide with persistent memory. Check your memory first before exploring the code.
  • omitClaudeMd: true

    • Pula o carregamento da hierarquia de instruções de CLAUDE.md, sendo adequado para revisores de “fresh eyes” que analisam com base em padrões da indústria em vez de convenções do projeto
---
name: fresh-eyes
description: Review code without project-specific biases
tools: [Read, Grep, Glob]
omitClaudeMd: true
effort: high
color: blue
---
Review this code purely from first principles. You have no project context. Focus on correctness, security, performance, and readability by industry standards.
  • criticalSystemReminder_EXPERIMENTAL

    • Reinjeta uma mensagem curta como lembrete de sistema a cada turno, permanecendo no contexto mesmo após a compressão da conversa
    • O próprio nome do campo inclui EXPERIMENTAL, então ele é instável e é mais apropriado para lembretes auxiliares de segurança do que para infraestrutura crítica
---
name: prod-deployer
description: Manages production deployments with strict safety checks
tools: [Bash, Read, Grep]
color: red
criticalSystemReminder_EXPERIMENTAL: "Always run migrations with --dry-run first. Never skip the staging verification step."
---
  • requiredMcpServers

    • Lista padrões de nomes de servidores MCP necessários; se esses servidores não existirem, o Agent não aparece
    • Isso pode evitar que Agents com dependências não preparadas sejam carregados

O classificador do Auto Mode recebe descrições do ambiente em linguagem natural

  • O campo autoMode em settings.json configura o classificador de aprovação automática que a Anthropic chama internamente de “YOLO Classifier”
  • Padrões em allow são aprovados automaticamente, e padrões em soft_deny sempre exigem confirmação
  • O array environment não é um conjunto de padrões, mas sim um contexto em linguagem natural lido pelo classificador, que pode refletir a descrição do ambiente do projeto ao avaliar a segurança de comandos ambíguos
{
  "autoMode": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Read",
      "Grep",
      "Glob"
    ],
    "soft_deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Write(.env*)"
    ],
    "environment": [
      "NODE_ENV=development",
      "This is a local dev machine with no production database access",
      "All Docker containers use isolated networks",
      "The test suite is safe to run repeatedly, it uses a dedicated test database"
    ]
  }
}
  • Frases como This project uses Docker, all commands run in containers são usadas para ajudar o classificador a entender o ambiente
  • No production access faz com que ele reaja de forma menos conservadora a operações destrutivas, e Test database is isolated funciona como um sinal de que rodar testes é sempre seguro

Loop de integração entre memória automática e Dream

  • Ao ativar autoMemoryEnabled e autoDreamEnabled em settings.json, o sistema de autoaperfeiçoamento do Claude Code é habilitado
{
  "autoMemoryEnabled": true,
  "autoDreamEnabled": true
}
  • autoMemoryEnabled

    • Após cada conversa, um Agent em segundo plano extrai da sessão informações que valem a pena manter por mais tempo
    • Preferências do usuário, padrões da codebase e decisões tomadas são registrados em ~/.claude/projects/<path>/memory/ no formato padrão de frontmatter de memória
  • autoDreamEnabled

    • A cada 24 horas, se houver 5 ou mais sessões acumuladas, um Agent em segundo plano revisa os transcripts de sessões passadas para consolidar a memória
    • Ele faz fusão de duplicatas, resolve contradições, converte datas relativas em datas absolutas e remove itens desatualizados
    • Quando as duas configurações são ativadas juntas, forma-se um loop de aprendizado em que as sessões criam memórias, o Dream consolida essas memórias, e as memórias consolidadas passam a influenciar sessões futuras
    • Depois de algumas semanas, o Claude Code pode passar a lembrar preferências, convenções e padrões recorrentes do usuário sem necessidade de retreinamento do modelo

Formato do Magic Docs

  • O Magic Docs é detectado pela expressão regular /^#\s*MAGIC\s+DOC:\s*(.+)$/im
  • Ele precisa obrigatoriamente ser um título H1, e não diferencia maiúsculas de minúsculas
  • Na linha seguinte, é possível adicionar uma instrução em itálico envolvida por _underscores_ ou *asterisks*, que limita o escopo em que o Agent de atualização deve se concentrar
# MAGIC DOC: API Endpoint Reference
_Only document public REST endpoints. Include method, path, request body, response schema, and auth requirements._

## Endpoints

(content auto-maintained by Claude Code)
  • Se não houver instrução, o Agent tenta atualizar todo o conteúdo
  • Se houver instrução, ele segue um escopo como only track public endpoints ou focus on breaking changes
  • O Agent de atualização roda em segundo plano e é restringido a editar apenas aquele arquivo
  • Se o cabeçalho for removido, o rastreamento é interrompido automaticamente

Sintaxe completa das regras de permissão

  • A documentação mostra exemplos básicos como Bash(git *), mas na prática a linguagem de padrões cobre amplamente Bash, caminhos de arquivos e ferramentas MCP
Bash(npm *)              # wildcard depois de "npm "
Bash(git commit *)       # subcomando específico
Read(*.ts)               # extensão de arquivo
Read(src/**/*.ts)        # diretório recursivo com extensão
Write(src/**)            # recursivo, todos os arquivos
mcp__slack               # todas as ferramentas no servidor slack
mcp__slack__*            # wildcard explícito (mesmo efeito)
mcp__slack__post_message # ferramenta específica
Bash(npm:*)              # prefixo legado com dois-pontos (limite de palavra)
  • * faz correspondência dentro de limites, como no glob do shell, e ** faz correspondência recursiva em diretórios
  • As permissões de ferramentas MCP usam o formato de sublinhado duplo: mcp__<server>__<tool>
  • O campo if de Hook também usa a mesma sintaxe; é glob, não regex
{
  "permissions": {
    "allow": [
      "Bash(npm *)", "Bash(git status)", "Bash(git diff *)",
      "Read(src/**)", "Read(tests/**)", "Grep", "Glob",
      "mcp__database__query"
    ],
    "deny": [
      "Bash(rm -rf *)", "Write(/etc/**)", "Write(.env*)",
      "mcp__slack__delete_*"
    ],
    "ask": [
      "Bash(git push *)", "Write(*.json)", "Write(*.lock)",
      "mcp__slack__post_message"
    ]
  }
}

context: fork e o impacto do cache na seleção de modelo

  • Ao definir context: fork em uma Skill, ela é executada como um subagente em background com fork
  • O fork compartilha o prompt cache do pai por meio de um contrato tipado chamado CacheSafeParams e gera um prefixo de requisição de API byte a byte idêntico para aumentar a taxa de acerto do cache
  • Se você especificar um modelo diferente para a Skill com fork, o prefixo muda e o cache pode ser invalidado
  • Se a conversa pai usa Opus e o fork usa Haiku, o prefixo muda, ocorre cache miss e o custo total é cobrado
  • Em Skills com fork, é preciso omitir o campo model ou usar model: inherit para manter o cache
  • context: fork é adequado para tarefas pesadas como varredura de segurança, análise de dependências, geração de documentação e execução de suíte de testes, enquanto a conversa principal mantém a responsividade
---
name: full-audit
description: Comprehensive codebase audit running in the background
context: fork
allowed-tools: Bash, Read, Grep, Glob, WebSearch
effort: high
---
Run a comprehensive audit:
- Security scan (grep for dangerous patterns, check dependencies for CVEs)
- Code quality (duplicated logic, dead code, missing error handling)
- Test coverage (untested critical paths)
- Dependency health (outdated packages, unused deps, license issues)

Write a detailed report to /tmp/audit-report.md when complete.

Exemplos de combinação de recursos

  • Revisor de código com memória persistente e hook de escopo

    • O Agent lê a memória por codebase, revisa junto os padrões encontrados no passado e os novos problemas, e depois salva novamente as descobertas na memória
    • Após várias revisões, isso ajuda a detectar problemas recorrentes específicos do projeto que um revisor comum pode deixar passar
---
name: reviewer
description: Code reviewer that learns your codebase patterns over time
tools: [Read, Grep, Glob, Bash]
effort: high
color: yellow
memory: project
hooks:
  PostToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "~/.claude/hooks/log-review.sh"
          async: true
---
Before reviewing, read your memory for past findings on this codebase.

Review git diff HEAD~1 for:
- Patterns you've flagged before (check memory)
- New issues worth flagging
- Resolved issues from past reviews

After review, save to memory:
- New patterns found (type: feedback)
- Recurring issues (type: project)

End with VERDICT: PASS, FAIL, or NEEDS_REVIEW.
  • Configuração de sessão que combina monitoramento de arquivos e a rede de segurança asyncRewake

    • No início da sessão, carrega o contexto do projeto, aprova automaticamente de imediato comandos Bash somente leitura e bloqueia comandos perigosos com uma verificação de segurança assíncrona
    • Comandos somente leitura passam rapidamente, comandos perigosos são bloqueados, e os demais seguem o fluxo normal de permissões
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }, {
        "type": "command",
        "command": "~/.claude/hooks/block-dangerous.sh",
        "asyncRewake": true,
        "statusMessage": "Safety check..."
      }]
    }]
  }
}
#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
echo "$CMD" | grep -qE '(rm -rf /|sudo rm|chmod 777|> /dev/)' && exit 2 || exit 0
  • Revisão de arquitetura que combina override de modelo, controle de effort e delegação para Agent

    • Define uma análise profunda com effort: max, delega para um Agent específico e reduz a influência dos costumes existentes do projeto com omitClaudeMd: true nesse Agent
---
name: architecture-review
description: Deep architecture review using max effort, delegated to fresh-eyes agent
agent: fresh-eyes
effort: max
---
Review the architecture of this project. Ignore existing conventions (the agent has omitClaudeMd: true).
Focus on: $ARGUMENTS

Evaluate structural decisions, dependency graph health, separation of concerns, and scalability characteristics.

Significado e limitações

  • O sistema de Hook com campos de resposta por evento funciona como uma camada de middleware programável para o uso de ferramentas de IA
  • A memória persistente de Agent permite criar especialistas de IA que acumulam experiência entre sessões
  • O sistema de integração Dream fornece uma estrutura que aprende com a experiência da sessão sem retreinar o modelo
  • O classificador do Auto Mode recebe descrições do ambiente em linguagem natural e as incorpora na avaliação de segurança
  • Esses recursos, mais do que configurações ocultas ou easter eggs, são funcionalidades de base para um ambiente de desenvolvimento com IA persistente, que aprende e autônomo, e já estão incluídos no pacote npm atual

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News
  • Verificando com o Pangram, isso parece claramente um texto gerado por IA
    Fico surpreso que tenha recebido tantas recomendações, e me pergunto se as pessoas realmente leram o texto. Sei que o @dang criou uma regra para conteúdo gerado por IA nos comentários, mas ainda vinha evitando isso nos posts. Pessoalmente, seria bom se também houvesse uma flag de denúncia nos artigos, para não perdermos tempo com textos de baixa qualidade como este

  • Isso tudo já está documentado [1]. Once também está documentado [2], e async e asyncRewake também estão documentados [3]. O frontmatter de Skills está completamente documentado [4], e as strings de ambiente do Automode também estão nos docs [5]
    Este texto é puro clickbait escrito por IA, então me surpreende que esteja tendo uma recepção tão boa aqui
    [1] https://code.claude.com/docs/en/hooks#pretooluse-decision-co...
    [2] https://code.claude.com/docs/en/hooks#common-fields
    [3] https://code.claude.com/docs/en/hooks#command-hook-fields
    [4] https://code.claude.com/docs/en/skills#frontmatter-reference
    [5] https://code.claude.com/docs/en/auto-mode-config#define-trus...

  • Este texto é de 2 meses atrás, então parte dele já está desatualizada, e alguns recursos já foram documentados
    Por exemplo, a documentação do auto mode está aqui: https://code.claude.com/docs/en/auto-mode-config#define-trus...

  • O pacote claude recebe 10 novas versões por semana, e novos modelos saem a cada poucos meses, então não dá para depender de gambiarras não documentadas em volta dele
    Vai mudar, quebrar e provavelmente bagunçar configurações detalhadas demais

    • Pela minha experiência, gambiarras não documentadas quebram com a mesma frequência que recursos documentados
      Como quando removeram a opção “clear context and execute plan” depois de lançar o 1M Opus, dizendo que “a janela de contexto não é mais um problema”
    • A cada nova versão, dá para criar automação para lidar de forma eficiente com configurações de usuário de baixo nível
    • É verdade, mas às vezes um hack temporário pode salvar ou arruinar um workflow de ponta
      Eu não redesenho as instruções do Claude a cada release, mas em algumas vale a pena verificar se as instruções existentes ainda combinam com o modelo atual, e isso de fato já fez diferença perceptível
  • A quantidade de recursos do Claude Code é sufocante. Nesse ritmo, o próximo papa vai ser da Anthropic

    • Brincadeiras à parte, a Anthropic está despejando coisas demais, a ponto de ficar difícil confiar
      Desse jeito, não parece fácil virar um produto suficientemente bem pensado e estável
  • Eles vêm com essa de “Honest status”, dizendo que não é 100% e que vão explicar honestamente por que é um caminho mais longo, https://github.com/user-attachments/assets/961eff6c-0060-45d...
    Eu só queria que o Claude Code não desistisse de concluir a tarefa. Isso é irritante demais. Mesmo usando /goal ou o novo ultracode, ele continua desistindo. Meu projeto é bem complexo (https://github.com/mohsen1/tsz), mas o Codex não tem problema em continuar insistindo sem parar desse jeito

    • Agora eu uso /loop e coloco um prompt para motivá-lo a continuar
      Goal também pode servir, mas para algumas tarefas um simples loop é melhor
    • Acabei de pedir ao Claude para preencher uma lista de tarefas, e ele ficou perguntando se devia continuar ou se bastava ter feito só uma parte antes de chegar ao fim da lista
  • Fico curioso se está surgindo algum tipo de arquitetura de aplicação de agente de codificação com IA mais ou menos universal entre os modelos LLM em geral
    Também queria saber se há alguém reunindo e organizando formas de entender esse estilo de arquitetura

    • Estamos mesmo falando do mesmo site? Hoje em dia alguém usa outra coisa além disso?
    • Os padrões em Claude Code, Codex e Cursor parecem estar convergindo: coleta de contexto, planejamento, execução e validação
      A parte menos padronizada é quanto controle é dado ao usuário entre cada etapa. Configurações como showClearContextOnPlanAccept ou disableAutoMode são interessantes porque mostram a fronteira entre “o agente decide” e “o humano revisa antes de executar”. E esse parece ser justamente o ponto em que os agentes de código vão continuar diferindo bastante na experiência de uso real
  • Estou curioso sobre o recurso “magic doc”. Não sei se isso vai no CLAUDE.md ou em um arquivo do projeto
    Também não sei se é preciso mencionar esse arquivo durante a sessão, ou se o Claude procura automaticamente em todo o projeto por lugares com o cabeçalho “magic doc” dentro

  • Será que dá para pedir ao Claude para criar a própria configuração? Algo como “pense que você é eu e crie o conjunto ideal de arquivos de configuração que você gostaria de ter”

    • Segundo a documentação, se você definir CLAUDE_CODE_NEW_INIT como 1, o /init roda em um fluxo de configuração interativo
      Esse fluxo explora a base de código e pergunta quais arquivos criar, como CLAUDE.md, skills e hooks, antes de escrever qualquer coisa. Sem essa variável, o /init gera CLAUDE.md automaticamente sem perguntar
    • Provavelmente dá. Parece haver uma ferramenta embutida para explorar a própria documentação, e também um modo especial para trabalhar no diretório .claude/
      Parece que foi pensado para que o usuário fizesse isso mesmo
    • Seria bom ter um projeto cookie cutter com todos os arquivos boilerplate trazendo as melhores práticas
    • Existe um comando de barra que vasculha o histórico da conversa e adiciona permissões permitidas
    • Dá, sim. O Claude é bem capaz de modificar a si mesmo
  • Você vai se divertir descobrindo que aquele recurso não documentado de que dependia parou de funcionar do nada

    • Se engenharia de software realmente é um problema resolvido, como a Anthropic afirma, então qualquer um deveria conseguir simplesmente recriar tudo com vibe coding
      Se eles não tivessem alergia à palavra “open”, já teriam lançado o Claude Code como open source; neste ponto, não há motivo prático real para não fazer isso