📐 O Briefing ICCA (Framework)
Intent, Constraints, Criteria, Arquivos — o esqueleto de todo prompt moderno.
Declaração curta do objetivo da tarefa e do motivo de negócio. Sem intenção, sem autonomia.
Define a fronteira entre "fazer certo" e "fazer o certo".
1–3 linhas. Evite verbos fracos como "melhorar".
Lista das invariantes — APIs públicas, testes, contratos, perfis de segurança que não podem mudar.
Evita refactor "por iniciativa própria" que quebra produção.
Imperativos claros, nunca vagos.
Critério objetivo de aceitação — testes passando, regex batendo, output com formato X.
Sem critério, o modelo para quando "sente" que terminou.
Mensurável, binário quando possível.
Caminhos absolutos dos arquivos a ler, modificar e testar.
Economiza ~5k tokens de busca inicial.
Liste sempre que souber; deixe pesquisar só no que não souber.
Intent → Arquivos → Constraints → Criteria tende a render melhor que outras permutações.
O contexto amarrado cedo reduz especulação.
Use headings claros.
Bug fix: 8–20 linhas. Feature: 20–60 linhas. Migração: 60–120 linhas.
Briefing curto demais drip-feed. Longo demais dilui intent.
Densidade > quantidade.
Verbos vagos, "use boas práticas", "melhore o código".
Convidam o modelo a over-engineering silencioso.
Troque por critério verificável.
📋 Templates ICCA Prontos
6 templates copy/paste — bug, feature, debug, refactor, migração, integração.
Estrutura: sintoma, reprodução, escopo, critério (teste passando).
Bugs são 40% das tarefas diárias.
Nunca peça "cleanup adjacente".
Intent de negócio, user story, arquivos tocados, teste esperado.
Feature bem briefada sai em 1 turno.
Escopo explícito evita mission creep.
"Encontre a causa, não corrija ainda" — separar diagnóstico de correção.
Correções precoces escondem a raiz.
Peça hipóteses ranqueadas.
Padrão antes, padrão depois, diff aceito, teste de não-regressão.
Refactors sem escopo são o maior buraco de tokens.
Liste todos os call-sites.
Snapshot do comportamento atual + equivalência com o novo.
Legado sem spec escrita = alucinação garantida.
Testes caracterizadores primeiro.
Endpoint, auth, response shape, retry/idempotency, rate limit.
Integrações falham mais por premissa oculta que por código.
Nunca deixe o modelo inferir auth.
Templates no VSCode (snippets.json), Alfred, Raycast ou Claude Code commands.
Atalho > memória.
1 gatilho por template (icca-bug, icca-feat, etc).
🎛️ Níveis de Effort
low, medium, high, xhigh, max — qual escolher e por quê.
Lookups simples, diff pequeno, format code. Modelo para cedo.
4.7 respeita mais rígido — under-thinking é real em tarefas complexas.
Se precisar "explique antes", não é low.
Tarefas com < 3 decisões, volume alto, pipeline automatizado.
Onde o trade-off qualidade/custo é favorável.
Scripts de triagem, sumarização.
Features de média complexidade, quando muitas rodam em paralelo.
Economia sem perder qualidade em fan-out.
Degrade gradual comparado a xhigh.
O default recomendado. Autonomia forte, consumo previsível.
80% dos casos de coding agêntico.
Não precisa configurar — é o default.
Problemas com grande espaço de decisão, arquitetura aberta, research.
Em tarefas simples, gera overthinking e custo elevado.
Use pontualmente, não por default.
4.7 respeita mais estritamente effort=low — para mesmo quando 4.6 continuaria.
Pode parecer regressão se não souber.
Suba o effort se o output é raso.
Tabela: tipo de tarefa × effort — preencha com seus próprios casos.
Automatiza a escolha.
Revise a cada 30 dias.
🔀 Alternando Effort + Output Tokens
Padrão desenho→aplicação→revisão e max_output_tokens=64000.
Arquitetura em xhigh, aplicação em medium, revisão em xhigh.
Padrão que combina qualidade e custo.
Economia real em features médias.
Limite novo do 4.7 — 64k tokens de output por resposta.
Sem configurar, truncamento silencioso em respostas grandes.
Defina no client antes de sessions grandes.
/effort medium no Claude Code, troca viva.
Calibra por fase do trabalho.
Anuncie a troca no prompt seguinte.
Experimento: medium vs xhigh, mesmo briefing, mede tempo+tokens+qualidade.
Calibração com dados pessoais > intuição.
Documente 5 experimentos/mês.
Anexar ao briefing: "effort usado", "trocas que fiz" — útil ao repetir.
Sem registro, reaprender sempre.
Bloco "Execution notes" no final do briefing.
Trocar effort em sessão longa pode expor context rot que não aparecia.
Ao cair para medium, o modelo pode confundir itens antigos.
Considere /compact ao trocar.
Defaults em ~/.claude/settings.json — modelo, effort, max_output.
Consistência entre máquinas.
Versione no git.
🧠 Adaptive Thinking (Migração)
Extended thinking deprecated — migração de budget_tokens para adaptive.
Mecanismo antigo com budget fixo — não é mais suportado no 4.7.
Código antigo falha ou ignora config silenciosamente.
Substitua antes de migrar modelo.
Troque {type:"enabled", budget_tokens:N} por {type:"adaptive"}.
Única forma oficial no 4.7.
Tire todos os budget_tokens do código.
Effort controla intensidade, adaptive controla alocação passo a passo.
A combinação substitui budget integralmente.
Não tente replicar budget com max_tokens.
Adaptive decide thinking por tool-call, por passo, por complexidade detectada.
Entendendo, você deixa de "economizar" forçando budget.
Confie — é melhor que budget manual.
Campo effort no output config do SDK — low/medium/high/xhigh/max.
Interface oficial de calibração.
Settar effort=null reverte ao default.
Mesmo prompt 3×: budget fixo (falha), adaptive alone, adaptive+effort.
Ver a diferença remove dúvida.
Thinking tokens variam — é o esperado.
Grep budget_tokens → remove → adaptive → effort → testa.
Checklist evita esquecer call-sites.
Faça um PR só de migração primeiro.
✍️ Biblioteca de Frases-Gatilho
Frases para mais/menos thinking, commit to approach, auto-check.
"Think carefully and step-by-step", "This task involves multi-step reasoning", "Before you finish, verify your answer".
Sobem adaptive thinking sem mudar effort.
Escolha a que melhor encaixa na tarefa.
"Prioritize responding quickly", "Thinking adds latency — when in doubt, respond directly".
Útil em UX com resposta em streaming.
Não compensa em tarefas críticas.
"Commit to an approach and execute it without revisiting decisions mid-flight."
4.7 tende a revisitar — útil cortar quando arquitetura já decidiu.
Use quando já brainstormou antes.
"Verify your solution against the criteria before returning."
Detecta auto-erros sem você relê-los.
NÃO use "double-check" (anti-pattern 4.6).
"Every N tool calls, summarize", "think step by step every time".
Rouba context e sobreescreve adaptive.
Aposente do sistema inteiro.
"Be thorough but fast", "apply best practices", "use common sense".
4.7 tenta cumprir literalmente e falha.
Substitua por critério mensurável.
Monte um arquivo com 10 frases que você usa mais — cada uma com caso de uso.
Reduz decisão em hot-path.
Versione no repo dotfiles.
🚪 Gestão de Sessão: 5 Portas
Continue, /rewind, /clear, /compact, subagente — o mapa de decisão.
Todo turno é uma escolha entre 5 portas, não só "continuar".
Sem consciência, você sempre escolhe porta 1 — que nem sempre é a melhor.
Pause 3s antes de enter.
Segue a sessão quando o contexto acumulado ajuda a próxima tarefa.
Default saudável em pipeline incremental.
Cuidado com sessões > 2h.
Volta a um turno anterior e tenta nova direção com handoff message.
Melhor que corrigir por baixo — não acumula context corrompido.
Sempre escreva o motivo do rewind.
Limpa tudo e recomeça com briefing destilado — zero context rot.
Tarefa nova merece sessão nova.
Invista 2 min no briefing destilado.
Comprime sessão mantendo o que importa. Use com hint direcionado.
Proativo é melhor que esperar autocompact.
Hint: "mantém decisões de arquitetura".
"Preciso do output intermediário ou só da conclusão?" — se só conclusão, dispare subagente.
Preserva context principal.
Pré-visualização da T3.
10 situações reais — escolha a porta e justifique.
Decisão virou hábito, não reflexão.
Meta: acertar 9/10.