📐 Feature Blueprint
O Feature Blueprint transforma uma ideia vaga em um plano de implementacao concreto. Ele forca o Claude a decompor a feature em componentes, definir interfaces e mapear dependencias antes de escrever uma linha de codigo.
🎯 Template do Prompt
Crie um blueprint para esta feature antes de implementar: Feature: [descricao detalhada] Preciso de: 1. Decomposicao em sub-tarefas (max 5 passos) 2. Para cada sub-tarefa: arquivos envolvidos, mudancas especificas 3. Interfaces/tipos que serao criados ou modificados 4. Dependencias entre os passos (o que precisa vir primeiro) 5. Estimativa de complexidade por passo (simples/medio/complexo) 6. Testes necessarios por passo Formato: tabela com colunas [Passo | Arquivos | Mudanca | Dependencia | Complexidade | Testes] NAO implemente. Apenas o blueprint.
- • O formato tabela facilita a visualizacao e revisao do plano
- • Limitar a 5 passos forca decomposicao sem over-engineering
💡 Dica Pratica
Apos receber o blueprint, diga "Implemente o passo 1" e revise antes de prosseguir. Nunca diga "implemente tudo". A implementacao incremental passo a passo e a chave para manter qualidade.
🧪 Build With Tests
O Build With Tests garante que cada pedaco de codigo novo ja nasce com testes. Em vez de construir e testar depois, voce instrui o Claude a escrever o teste primeiro e depois a implementacao que o satisfaz.
🎯 Template do Prompt
Implemente [FEATURE] usando TDD: 1. PRIMEIRO: Escreva os testes que definem o comportamento esperado - Happy path (caso normal) - Edge cases (limites, valores nulos, erros) - Integracão com componentes existentes 2. DEPOIS: Implemente o codigo minimo que faz todos os testes passarem 3. FINALMENTE: Rode os testes e me mostre o resultado Regras: - Cada teste deve ter um nome descritivo que explica O QUE testa - Use o framework de testes que ja existe no projeto - Nao use mocks desnecessarios - prefira testes de integracao quando possivel
💡 Dica Pratica
Se os testes passarem de primeira, desconfie. Peca para o Claude adicionar casos de edge case mais agressivos. Testes que nunca falham podem estar testando a coisa errada.
✓ O que FAZER
- ✓Escrever teste ANTES do codigo de producao
- ✓Incluir edge cases e cenarios de erro
- ✓Rodar testes e verificar que passam
✗ O que NAO fazer
- ✗Construir tudo e "testar depois"
- ✗Aceitar testes que so cobrem happy path
- ✗Usar mocks para tudo em vez de testes reais
🧱 Construcao Incremental
A construcao incremental e o principio de nunca pedir ao Claude que implemente mais do que um passo de cada vez. Cada passo e revisado, testado e aprovado antes de prosseguir. Isso elimina rewrites massivos e mantem o controle total.
🎯 Fluxo Incremental
Passo 1: "Implemente apenas [componente A]. Nao toque em mais nada."
→ Revise → Teste → Aprove
Passo 2: "Agora implemente [componente B] que se conecta com A."
→ Revise → Teste → Aprove
Passo 3: "Integre A e B. Rode os testes de integracao."
→ Revise → Teste → Aprove
REGRA: Cada passo deve ser commitavel isoladamente.
- • Cada passo commitavel isoladamente significa que voce pode reverter sem perder tudo
- • Dizer "nao toque em mais nada" previne mudancas indesejadas em outros arquivos
💡 Dica Pratica
Use git diff apos cada passo para verificar que o Claude nao modificou arquivos que nao deveria. Se modificou, reverta e peca novamente com instrucoes mais explicitas.
🔄 Abordagem Test-First
A abordagem test-first vai alem do TDD classico. Voce usa testes como especificacao executavel: define o comportamento desejado em testes e pede ao Claude para fazer os testes passarem. Isso inverte o fluxo e gera codigo mais focado.
🎯 Template do Prompt
Eu ja escrevi os testes que definem o comportamento esperado. Eles estao em [caminho/do/teste]. Sua tarefa: 1. Leia os testes e entenda o que cada um espera 2. Implemente o codigo de producao que faz TODOS passarem 3. NAO modifique os testes - eles sao a especificacao 4. Se algum teste parece impossivel de satisfazer, me avise antes de mudar Rode os testes ao final e me mostre o resultado.
💡 Dica Pratica
Escreva voce mesmo os testes mais criticos (regras de negocio, seguranca) e deixe o Claude escrever os testes de edge case e integracao. Voce mantem controle sobre o "que" enquanto delega o "como".
✅ Workflow de Aprovacao
O workflow de aprovacao define checkpoints onde voce para, revisa e decide se o Claude deve prosseguir. Sem esses gates, o Claude pode construir uma feature inteira em uma direcao errada antes que voce perceba.
🎯 Template com Gates
Implemente [FEATURE] com os seguintes gates de aprovacao: GATE 1 - Plano: Me mostre o plano antes de codar. PARE e espere aprovacao. GATE 2 - Interfaces: Crie os tipos/interfaces. PARE e espere aprovacao. GATE 3 - Implementacao core: Implemente a logica principal. PARE e espere aprovacao. GATE 4 - Testes: Escreva e rode os testes. PARE e espere aprovacao. GATE 5 - Integracao: Conecte com o resto do sistema. PARE e espere aprovacao. Em NENHUM momento pule um gate. Sempre espere meu "ok" ou "aprovado" para continuar.
💡 Dica Pratica
Para tarefas simples, use apenas 2 gates (plano e implementacao). Para tarefas criticas, use 5. Ajuste a granularidade dos gates conforme o risco da mudanca.
🏁 Quality Gates Automaticos
Os quality gates automaticos sao instrucoes que voce coloca no CLAUDE.md para que o Claude aplique verificacoes de qualidade automaticamente, sem voce precisar pedir a cada vez.
🎯 Quality Gates para CLAUDE.md
# Quality Gates (CLAUDE.md) Antes de considerar qualquer tarefa como "completa": - [ ] Testes escritos E passando - [ ] Sem erros de linting - [ ] Sem TODO/FIXME sem issue associada - [ ] Tipos corretos (sem any desnecessario) - [ ] Error handling para todos os caminhos de falha - [ ] Sem dados hardcoded (use env vars ou config) - [ ] git diff revisado - nenhuma mudanca inesperada
💡 Dica Pratica
Adicione esses quality gates ao seu CLAUDE.md e o Claude vai automaticamente verificar cada item antes de dizer que terminou. Se voce perceber que um gate e sempre ignorado, torne a instrucao mais explicita.
📋 Resumo do Modulo
Proximo Modulo:
4.4 - Prompts de Debugging