🧑‍💻 Painel de Prompts

O prompt "Ask me clarifying questions one at a time until you're 95% confident you can complete the task successfully." Forca o Claude a perguntar antes de agir.

Previne blind-spot coding. Em vez do Claude assumir coisas e gerar codigo errado, ele pergunta o que precisa saber primeiro. Reduz drasticamente retrabalho.

Use para qualquer feature nova, migracao ou mudanca complexa. O Claude faz perguntas uma por vez ate ter confianca suficiente. Resultado: menos iteracoes, codigo mais preciso.

O prompt que ativa Plan Mode: identifica arquivos afetados, delineia abordagem passo a passo, sinaliza tradeoffs e espera aprovacao antes de escrever codigo.

Think first, build second. Sem planejamento, o Claude mergulha direto no codigo e pode ir por um caminho subotimo. Plan Mode garante alinhamento antes da execucao.

Use para features nao-triviais. O Claude lista arquivos, passos, riscos. Voce aprova ou ajusta. So entao ele comecar a codar. Economiza horas de refatoracao.

Template que estrutura o bug: acao executada, erro recebido, comportamento esperado vs. real, stack trace. E a instrucao "Investigate the root cause before attempting a fix."

Forca diagnostico antes de patch. Sem estrutura, o Claude tenta corrigir o sintoma. Com estrutura, ele analisa a causa raiz primeiro. Bugs sao resolvidos de verdade, nao mascarados.

Inclua sempre: acao, erro, esperado, real, stack trace. A frase-chave e "Investigate root cause before fix". Funciona para qualquer tipo de bug: frontend, backend, infra.

Prompt que pede auditoria completa: edge cases, vulnerabilidades de seguranca, bottlenecks de performance, cenarios de crash, e tudo que um senior engineer flagaria. "Be brutally honest."

Encontra o que voce nao sabe que perdeu. Apos construir algo significativo, esse prompt faz o Claude agir como um reviewer senior implacavel. Pega problemas antes de irem pra producao.

Use apos construir qualquer coisa significativa. As 5 areas: edge cases, seguranca, performance, crash, senior review. A frase "be brutally honest" e essencial para evitar respostas amenas.

Apos o Claude resolver algo, este prompt pede: causa raiz, por que esta abordagem, o que quebraria sem o fix, e o que observar na proxima vez. "Explain it so I could do it myself."

Transforma o Claude de ferramenta em amplificador de habilidades. Em vez de depender do Claude para sempre, voce aprende a fazer sozinho. AI como professor, nao como muleta.

Use apos fixes e refactors. 4 perguntas: causa raiz, escolha de abordagem, consequencia de nao corrigir, sinais de alerta. Voce cresce como desenvolvedor a cada uso.

O fluxo completo: 95% Confidence (entender) > Plan Mode (planejar) > Build > Structured Bug (debug) > Brutal Audit (validar) > Teach Me (aprender). Um sistema, nao prompts isolados.

Prompts isolados sao bons. Prompts em sequencia estrategica sao um sistema de producao profissional. Cada prompt cobre uma lacuna que os outros deixam.

Nao e preciso usar todos em toda tarefa. O ponto e saber quando usar qual. Tarefas simples: so Build. Tarefas complexas: ciclo completo. O julgamento do "quando" e o que separa operadores de usuarios.

Analise detalhada de como o 95% Confidence funciona internamente: por que "one at a time" e crucial, como o threshold de 95% muda o comportamento, e variacoes do prompt.

Entender a mecanica permite adaptar o prompt a diferentes contextos. O "one at a time" previne sobrecarga. O "95%" cria um padrao de qualidade mensuravel.

"One at a time" evita que o Claude faca 10 perguntas de uma vez. "95% confident" forca profundidade. Variacoes: ajustar o threshold (99% para critico, 80% para exploratoria).

Prompt completo de kickoff: descreva o que quer construir, o Claude pergunta, propoe tech stack com justificativa, cria plano de milestones e espera aprovacao.

Comecar errado custa caro. Este prompt garante que stack, arquitetura e plano estejam alinhados antes da primeira linha de codigo. Evita rewrite completo depois.

4 etapas: perguntas clarificadoras, proposta de tech stack, plano de milestones, espera por aprovacao. Cada etapa e um checkpoint que previne desvios.

Prompt que faz o Claude ler o codebase e entregar: overview geral, tech stack, estrutura de pastas, fluxo de dados e convencoes utilizadas. Onboarding instantaneo.

Entrar num projeto novo sem contexto e perder horas. Este prompt transforma horas de exploracao manual em minutos de analise automatizada. Ideal para projetos legados ou novos times.

5 entregas: overview, stack, estrutura, data flow, convencoes. O Claude explora o repo inteiro e sintetiza. Use como primeiro passo antes de qualquer modificacao em codebase desconhecido.

A sequencia ideal para primeira sessao num projeto: Codebase Onboarding primeiro, depois 95% Confidence para a tarefa especifica, depois Project Kickoff se for projeto novo.

A ordem dos prompts importa. Fazer onboarding antes de perguntar garante que o Claude entende o contexto. Perguntar antes de planejar garante que o plano esta alinhado.

Projeto existente: Onboarding > 95% Confidence > Plan Mode. Projeto novo: 95% Confidence > Kickoff > Plan Mode. Sempre termina com plano aprovado antes de codar.

Reconhecer os tipos de perguntas que o Claude faz com 95% Confidence: escopo, restricoes tecnicas, preferencias de design, edge cases, e integracao com existente.

Saber que tipos de perguntas esperar ajuda voce a preparar respostas melhores. Quanto mais rapido e preciso voce responde, mais rapido o Claude atinge 95% de confianca.

5 categorias de perguntas: escopo (o que incluir/excluir), tecnicas (stack, constraints), design (UI/UX, API), edge cases (falhas, limites), integracao (o que ja existe).

Os erros mais comuns ao iniciar: pular o onboarding, nao usar 95% Confidence, aceitar a primeira proposta sem questionar, e comecar a codar antes de planejar.

Blind-spot coding e a maior causa de retrabalho. Saber quais pontos cegos existem permite evita-los conscientemente. Prevention > cure.

Top 3 blind spots: assumir que o Claude entendeu (use 95%), pular planejamento (use Plan Mode), nao verificar existente (use Onboarding). Cada prompt de getting started previne um blind spot especifico.

Prompt que ativa Plan Mode: identifica arquivos afetados, delineia abordagem, sinaliza riscos e espera aprovacao. "Enter plan mode. Before writing any code..."

Construir sem blueprint e navegar sem mapa. O Claude identifica todos os arquivos que precisam mudar e os riscos antes de tocar em qualquer codigo.

4 passos: identificar arquivos, delinear abordagem, sinalizar riscos/tradeoffs, esperar aprovacao. Nunca pule o passo 4 - aprovacao e seu checkpoint de seguranca.

Prompt que forca TDD: para cada peca, escreve teste primeiro, depois implementacao, roda testes, move para proxima peca. "Do not batch tests." - cada peca e validada individualmente.

Codigo sem testes e bomba-relogio. Este prompt garante que cada peca tem cobertura antes de avancar. Bugs sao pegos no momento da criacao, nao semanas depois.

Ciclo: teste > implementacao > rodar > proxima peca. "Do not batch" e crucial - batching de testes esconde falhas. Cada peca e validada antes de construir sobre ela.

A filosofia de construir features em pecas pequenas e validadas, em vez de gerar tudo de uma vez. Cada peca funciona independentemente antes de ser integrada.

Features grandes geradas de uma vez sao impossiveis de debugar. Construcao incremental permite identificar exatamente onde algo quebrou. Menos retrabalho, mais controle.

Dividir a feature em unidades independentes. Construir e testar cada uma. Integrar gradualmente. Se algo quebra, voce sabe exatamente qual peca causou.

A pratica de escrever o teste que define o comportamento esperado antes de escrever o codigo que implementa esse comportamento. TDD aplicado com Claude Code.

Testes escritos depois do codigo testam a implementacao. Testes escritos antes testam a especificacao. A diferenca e entre "funciona?" e "faz o que deveria?".

Red > Green > Refactor. Escrever teste que falha (red), implementar para passar (green), melhorar o codigo (refactor). Com Claude, esse ciclo e extremamente rapido.

A pratica de inserir pontos de aprovacao humana no fluxo de building. "Wait for my approval" no Plan Mode garante que voce valida o plano antes da execucao.

Sem checkpoints, o Claude pode seguir por caminhos subotimos por dezenas de arquivos. Aprovacao humana no ponto certo previne cascatas de mudancas indesejadas.

Pontos de aprovacao: apos o plano, apos cada peca importante, antes de integrar. "Wait for approval" e a frase-chave. Voce controla o ritmo, o Claude executa.

Criterios automaticos que devem ser atendidos antes de avancar: testes passando, sem erros de lint, build funcionando. "Run tests after each change. Stop if tests fail."

Quality gates previnem acumulo de debt tecnico durante o build. Cada peca que passa no gate e confiavel. Pecas que falham sao corrigidas imediatamente, nao depois.

Gates minimos: testes passam, sem regressao, build compila. "Stop if tests fail" e um hard gate - nao avance ate resolver. Quanto mais cedo o bug e pego, mais barato de corrigir.

Template: acao, erro, esperado, real, stack trace + "Investigate root cause first." Estrutura toda informacao que o Claude precisa para diagnosticar antes de corrigir.

Bugs descritos vagamente geram correcoes vagas. Estrutura forca precisao. O Claude recebe toda informacao necessaria de uma vez, sem precisar pedir mais contexto.

Campos obrigatorios: acao (reproduzir), erro (mensagem exata), esperado vs real, stack trace. "Root cause first" previne patches superficiais.

Prompt que envia logs e pede: identificar erros distintos, agrupar relacionados, rankear por severidade, rastrear causa raiz dos criticos. Analise sistematica, nao aleatorio.

Logs longos sao ruido sem analise. Este prompt transforma logs em informacao acionavel: quais erros importam, quais estao relacionados, e qual e a causa raiz dos criticos.

4 passos: identify, group, rank, trace. Identificar erros unicos, agrupar por relacao, ranquear por severidade, rastrear causa raiz dos criticos. Estrutura > scan visual.

Tecnicas para capturar, formatar e enviar stack traces ao Claude de forma que maximize a qualidade do diagnostico. Stack trace completo > fragmento.

Stack traces truncados ou mal formatados levam a diagnosticos errados. Enviar o trace completo com contexto permite que o Claude identifique a causa raiz com precisao.

Sempre envie o stack trace completo, nao so a ultima linha. Use pipe para enviar direto: comando 2>&1 | claude -p "debug this". Inclua versoes de dependencias se relevante.

Sistema de classificacao de erros por severidade e tipo: critical (crash/data loss), high (funcionalidade quebrada), medium (degradacao), low (cosmetic). Rankear antes de corrigir.

Nem todo bug merece atencao imediata. Categorizar permite atacar os criticos primeiro e agendar os menores. Triage e a diferenca entre reativo e estrategico.

Use o Log Analysis prompt com "rank by severity". Categorias: Critical, Important, Minor, Nitpick (mesmas do Code Review). Resolva de cima pra baixo.

A pratica de perguntar "por que" ate chegar na causa fundamental, nao no sintoma. "Investigate root cause before attempting a fix" forca essa profundidade.

Corrigir sintomas cria whack-a-mole bugs - voce corrige um, outro aparece. Causa raiz resolve a familia inteira de bugs de uma vez. Menos patches, mais solucoes.

Tecnica dos 5 Porques: por que o erro acontece? Por que essa condicao existe? Por que nao foi prevenida? Continue ate chegar na raiz. O Claude faz isso automaticamente com o prompt certo.

O fluxo integrado: Structured Bug (report) > Log Analysis (contexto) > Root Cause (diagnostico) > Fix > Test > Teach Me (aprender). Debug sistematico, nao tentativa e erro.

Debug por tentativa e erro desperdicam tokens e tempo. Um workflow sistematico resolve bugs mais rapido e gera aprendizado. Cada debug session te torna melhor.

Sequencia: reportar estruturadamente > analisar logs > identificar causa raiz > corrigir > testar > aprender com Teach Me. O ultimo passo e o que separa operadores de usuarios.

Prompt que revisa branch por: bugs, seguranca, performance, legibilidade, error handling faltante. Classifica cada issue: Critical / Important / Minor / Nitpick.

Todo codigo merece review, mas nem todo time tem reviewer disponivel. Este prompt garante review de qualidade antes de cada merge. Pega o que voce nao viu.

5 areas: bugs, security, performance, readability, error handling. 4 niveis: Critical (bloqueia merge), Important (deveria corrigir), Minor (nice to have), Nitpick (opiniao).

Prompt com 4 regras de refatoracao: sem mudanca de comportamento, rodar testes apos cada mudanca, parar se testes falharem, somente edits pequenos e incrementais.

Refatoracao sem guardrails vira rewrite. Cada regra previne um tipo de desastre: no-behavior-change previne regressoes, stop-on-fail previne cascatas, incremental previne chaos.

4 regras: no behavior change, test after each change, stop if tests fail, small incremental edits. Nenhuma e negociavel. Se qualquer regra for violada, a refatoracao parou.

O sistema de classificacao de issues do Code Review: Critical (bloqueia deploy), Important (deveria corrigir antes de merge), Minor (melhoria nice-to-have), Nitpick (estilo/opiniao).

Sem classificacao, todas as issues parecem iguais. Com ratings, voce sabe exatamente o que bloqueia e o que pode esperar. Prioridade clara = acao eficiente.

Critical: seguranca, data loss, crash. Important: bugs, performance. Minor: legibilidade, convencoes. Nitpick: preferencias pessoais. Resolva de cima pra baixo.

A regra fundamental: refatoracao NUNCA muda o comportamento externo. Inputs e outputs permanecem identicos. Apenas a estrutura interna muda. Se o comportamento mudou, nao e refatoracao.

A maior causa de bugs em refatoracao e mudar comportamento "sem querer". Esta regra, combinada com testes, cria uma rede de seguranca contra regressoes.

Testes existentes sao a prova de no-behavior-change. Se um teste quebra, o comportamento mudou. "No behavior change" e a regra 1 do Refactor Guardrails por um motivo.

A pratica de fazer mudancas pequenas e testaveis em vez de refatoracoes massivas. Cada edit e isolado, testado e commitado antes do proximo. "Small incremental edits only."

Refatoracoes grandes sao impossiveis de revisar e reverter. Edits incrementais permitem git bisect, review facil e rollback preciso. Menos risco, mais controle.

Cada edit faz uma coisa: renomear variavel, extrair funcao, mover arquivo. Testa apos cada um. Commit apos cada um. Se algo quebrar, voce sabe exatamente qual edit causou.

Checklist padrao pre-merge: Code Review passado, nenhum Critical pendente, testes passando, Brutal Audit feito em mudancas significativas. O gate final antes do merge.

Uma checklist simples previne erros de omissao. Quando voce esta no ritmo e quer fazer merge rapido, a checklist e o freio de seguranca que impede bugs em producao.

Checklist minima: Code Review (sem Criticals), testes passam, build funciona, Brutal Audit (para mudancas grandes). Adicione items especificos do seu projeto conforme necessario.

Prompt que compara opcoes: pros/cons, complexidade, escalabilidade, manutencao de longo prazo, recomendacao. "Compare [A] vs [B]" com 5 criterios estruturados.

Decisoes de arquitetura sao as mais caras de reverter. Este prompt forca analise estruturada em vez de gut feeling. Cada criterio e avaliado explicitamente.

5 criterios: pros/cons, complexidade de implementacao, escalabilidade, manutencao longo prazo, recomendacao final. A recomendacao deve justificar com base nos criterios, nao em preferencia.

Prompt que projeta API REST completa: endpoints, schemas, autenticacao, formato de erro, paginacao/filtering. "Design a REST API for [feature]" com 5 deliverables.

APIs mal desenhadas geram debt tecnico permanente. Este prompt garante que todos os aspectos sao considerados: nao so os endpoints, mas auth, erros, paginacao - tudo que uma API real precisa.

5 deliverables: endpoints (paths + methods), schemas (request/response), auth (strategy), error format (padrao), pagination/filtering. API completa, nao so rotas.

A pratica de sempre comparar pelo menos 2 opcoes antes de decidir. Nunca aceite a primeira sugestao. O Architecture Decision prompt forca essa comparacao estruturada.

Viés de ancoragem faz voce aceitar a primeira opcao. Comparar forca pensamento critico. Mesmo quando a opcao A e claramente melhor, a comparacao valida essa decisao.

Sempre compare pelo menos 2 opcoes. Use criterios objetivos. Documente a decisao e o "por que". Se nao consegue articular por que A > B, voce nao analisou o suficiente.

Avaliar como a solucao se comporta com 10x, 100x, 1000x mais carga. O criterio "Scalability" do Architecture Decision prompt forca essa analise antes da implementacao.

Solucoes que funcionam com 100 usuarios podem quebrar com 10.000. Pensar em escala na fase de design e ordens de magnitude mais barato do que refatorar depois.

Perguntas-chave: bottlenecks esperados, pontos de contenção, estrategia de caching, opcoes de particionamento. Nao precisa resolver tudo agora, mas precisa saber onde estao os limites.

Avaliar o custo de manter a solucao ao longo de anos: complexidade de onboarding, debugging, atualizacoes de dependencias, e evolucao de features.

O custo de manutencao supera o custo de desenvolvimento em qualquer projeto que vive mais de 6 meses. Decisoes que facilitam manutencao pagam dividendos por anos.

Criterios: facilidade de onboarding, debuggability, dependencias (quantidade e saude), acoplamento. Solucoes simples e entediantes sao frequentemente as melhores para longo prazo.

A pratica de documentar decisoes de arquitetura (ADRs - Architecture Decision Records). O output do Architecture Decision prompt ja e uma ADR pronta para ser salva.

Daqui a 6 meses, ninguem vai lembrar por que escolheu PostgreSQL em vez de MongoDB. ADRs preservam o contexto da decisao para o futuro. O Claude gera a ADR automaticamente.

ADR minima: titulo, contexto, opcoes consideradas, decisao, consequencias. Salve o output do Architecture Decision prompt como ADR. Versione junto com o codigo.

Prompt que prepara deploy: checa configs de localhost, valida env vars, garante build passando, verifica seguranca, atualiza config de deploy. 5 checks pre-deploy automatizados.

Deploys quebrados sao caros e estressantes. Este prompt automatiza o checklist pre-deploy que todo time deveria seguir mas frequentemente pula por pressa.

5 checks: localhost configs (remove hardcoded URLs), env vars (todas definidas), build (compila sem erro), security (secrets expostos?), deploy config (atualizada para plataforma).

Prompt que configura CI/CD: roda em PR, lint + typecheck, testes, build, deploy em merge. 5 estagios de pipeline que garantem qualidade automatica em cada mudanca.

CI/CD manual e erro esperando pra acontecer. Este prompt gera o pipeline completo para sua plataforma (GitHub Actions, GitLab CI, etc). Setup de horas em minutos.

5 estagios: trigger em PR, lint + typecheck, run tests, build, deploy on merge. Cada estagio e um quality gate. Se qualquer um falha, o merge e bloqueado.

Verificar que todas as variaveis de ambiente, configs e dependencias estao corretas para o ambiente de destino (staging, production). O check 2 do Deployment Prep.

A causa #1 de deploys quebrados e env vars faltantes ou incorretas. Validar antes de deploy e infinitamente mais barato do que debugar em producao.

Checklist: todas env vars definidas, nenhum valor de dev em prod, secrets nao hardcoded, database URLs corretas, API keys validas. O Claude compara .env.example com o ambiente real.

Verificacoes de seguranca antes do deploy: secrets expostos em codigo, dependencias com vulnerabilidades conhecidas, endpoints sem autenticacao, CORS mal configurado.

Vulnerabilidades em producao sao criticas. Esse check combina com o Brutal Audit mas focado especificamente em seguranca de deploy. Prevention > incident response.

Checklist: .env no .gitignore, nenhum secret hardcoded, npm audit/pip audit limpo, HTTPS forcado, CORS restrito, rate limiting configurado. O Claude verifica cada item.

Verificar que o build passa sem erros nem warnings: compilacao limpa, sem imports nao utilizados, sem type errors, bundle size aceitavel. O check 3 do Deployment Prep.

Warnings ignorados acumulam e eventualmente viram erros. Build limpo e a base de um deploy confiavel. Zero warnings e o padrao profissional.

Build limpo = zero errors + zero warnings. O Claude roda o build, analisa output, identifica e resolve problemas antes do deploy. Includes: bundle analysis para apps frontend.

O design completo do pipeline: trigger > lint > test > build > staging > approval > production. Cada estagio e um gate que previne problemas no proximo.

Pipelines bem desenhados sao a espinha dorsal de times de alta performance. O CI/CD Setup prompt gera o pipeline, mas entender o design permite personalizar para seu contexto.

Estagios: trigger (PR/merge), quality (lint/typecheck), confidence (tests), artifact (build), validation (staging), approval (manual/auto), release (production). Ordem importa.

O mapa que conecta cada momento do dia de trabalho ao prompt ideal: inicio de sessao (Getting Started), desenvolvimento (Building), problemas (Debugging), qualidade (Review), decisoes (Architecture).

Ter prompts sem saber quando usar e como ter ferramentas sem saber qual e a certa para cada trabalho. O mapeamento transforma prompts isolados em sistema integrado.

Manha: Getting Started + Plan Mode. Desenvolvimento: Building + Tests. Problemas: Debugging. Pre-merge: Code Review + Brutal Audit. Fim do dia: Teach Me.

A regra #1: sempre comece trabalho complexo com 95% Confidence. Features novas, migracoes, refatoracoes grandes - tudo comeca com perguntas clarificadoras.

Pular 95% Confidence em trabalho complexo e a causa #1 de retrabalho. 2 minutos de perguntas economizam 2 horas de codigo errado. ROI absurdo.

Regra simples: se a tarefa leva mais de 30 minutos, comece com 95% Confidence. Se leva menos, pode ir direto. O threshold de complexidade e o gatilho.

A regra #2: sempre construa em Plan Mode. Apos 95% Confidence estabelecer o "o que", Plan Mode define o "como". Plano aprovado > codigo escrito.

Codigo sem plano e como construir sem planta. Pode funcionar pra casinha de cachorro, nao pra edificio. Plan Mode e a planta do seu software.

Fluxo: 95% Confidence > Plan Mode > aprovacao > Build With Tests. Cada transicao e um checkpoint. Nunca pule direto de pergunta para codigo.

A regra #3: sempre finalize trabalho significativo com Brutal Audit. Depois de construir, antes de mergear. E a ultima linha de defesa contra bugs em producao.

O viés de confirmacao faz voce achar que seu codigo esta perfeito. Brutal Audit quebra essa ilusao. Melhor descobrir problemas aqui do que em producao com usuarios reais.

Timing: apos build completo, antes do merge. Scope: edge cases, security, performance, crash, senior review. Action: resolva Criticals antes de merge, Important antes do sprint acabar.

A regra #4: sempre termine momentos de aprendizado com Teach Me. Apos fixes, refactors, ou qualquer momento onde o Claude fez algo que voce nao faria sozinho.

Sem Teach Me, voce e dependente do Claude para sempre. Com Teach Me, cada sessao te torna mais capaz. AI como amplificador de skill, nao como muleta permanente.

Momento ideal: apos o Claude resolver algo complexo. 4 perguntas: causa raiz, escolha de abordagem, consequencia, sinais de alerta. Voce aprende o "por que", nao so o "o que".

A regra #5: limpe contexto antes de migracoes grandes. Use /compact ou inicie sessao nova. Migracoes precisam de janela de contexto limpa para manter precisao do inicio ao fim.

Migracoes em sessoes poluidas geram erros. O Claude perde detalhes quando o contexto esta cheio. Sessao limpa = migracoes mais precisas e menos rollbacks.

Antes de migracoes: /compact com instrucoes ou sessao nova. Comece com Codebase Onboarding + 95% Confidence. Contexto limpo + entendimento fresco = migracoes bem-sucedidas.