📐 Feature Blueprint (Plan Mode Approach)
O Feature Blueprint e a evolucao do Plan Mode para features especificas. Enquanto o Plan Mode generico pede um plano geral, o Blueprint vai mais fundo: identifica todos os arquivos que precisam mudar, detalha a abordagem passo a passo, e mapeia riscos especificos da feature.
🎯 Conceito Principal
- • Arquivos afetados: O Claude navega o codebase e lista exatamente quais arquivos precisam ser criados, modificados ou deletados. Isso evita surpresas no meio do build
- • Abordagem detalhada: Nao e "adicionar autenticacao". E "1. Criar middleware de auth em src/middleware/auth.ts, 2. Adicionar schema de user em prisma/schema.prisma, 3. Criar rota POST /auth/login..." - cada passo e concreto
- • Riscos sinalizados: "Esta feature requer alteracao na tabela users que pode afetar queries existentes" - esse tipo de aviso previne desastres
💡 Dica Pratica
Antes de aprovar o blueprint, faca perguntas: "E se o usuario estiver deslogado?", "Como isso afeta mobile?", "Precisa de migration?". Quanto mais voce questiona o plano, melhor ele fica. O custo de ajustar um plano e zero. O custo de refazer codigo e alto.
🧪 Build With Tests (TDD Prompt)
O Build With Tests e o prompt que implementa Test-Driven Development com Claude Code. Em vez de construir a feature e depois escrever testes (que quase nunca acontece), voce forca o Claude a escrever o teste primeiro, implementar, rodar, e so entao avancar para o proximo pedaco.
🎯 Conceito Principal
- • Teste primeiro: O Claude escreve o teste que define o comportamento esperado. Depois escreve o codigo que faz o teste passar. Isso garante que cada pedaco funciona antes de avancar
- • Execucao real: O Claude roda os testes no terminal. Se falha, corrige antes de continuar. Voce ve o ciclo red-green acontecendo em tempo real
- • "Do not batch tests": Sem essa instrucao, o Claude tende a escrever todos os testes de uma vez e depois toda a implementacao. Isso anula o beneficio do TDD
💡 Dica Pratica
Certifique-se de que seu projeto ja tem um framework de testes configurado (Jest, Vitest, pytest, etc.) antes de usar este prompt. O Claude precisa poder executar os testes realmente. Se nao ha test runner, peca primeiro para configurar um.
🧱 Incremental Building (Step-by-Step)
Nem toda feature precisa de TDD formal. O Incremental Building e a versao pragmatica de construcao passo-a-passo. O Claude constroi uma peca, verifica que funciona, e so entao avanca para a proxima. Sem testes automatizados, mas com validacao a cada passo.
🎯 Conceito Principal
O Incremental Building funciona com um prompt que forca pausas entre etapas:
- • Smallest working version: Comeca com o minimo viavel. Um endpoint que retorna hello world. Um componente que renderiza um div. Depois evolui incrementalmente
- • Checkpoints manuais: A cada passo voce valida visualmente ou com um teste manual. So apos seu OK o Claude continua. Isso evita que ele construa 500 linhas de codigo que nao compilam
- • Ideal para UI: Construir interfaces incrementalmente permite que voce veja o resultado visual a cada passo e peca ajustes antes de adicionar mais complexidade
💡 Dica Pratica
Combine Incremental Building com git commits a cada checkpoint. Depois de cada "OK", peca ao Claude para commitar. Assim, se algo der errado num passo futuro, voce pode voltar para o ultimo ponto estavel sem perder tudo.
🎨 Component Building (UI Component Prompt)
Construir componentes de UI requer um tipo especifico de prompt. O Component Building prompt define props, estados, variantes e acessibilidade de forma estruturada, garantindo componentes completos e reutilizaveis desde a primeira versao.
🎯 Conceito Principal
- • Props explicitas: Listar as props evita que o Claude invente interfaces que nao fazem sentido para seu design system
- • Todos os estados: Hover, active, disabled, loading. Sem isso, o Claude constroi so o estado default e voce descobre os outros no QA
- • "Follow existing patterns": O Claude le os componentes ja existentes e replica o mesmo estilo, convencoes de naming e estrutura de arquivos
💡 Dica Pratica
Se voce usa Storybook ou similar, adicione ao prompt: "Also create a Storybook story showing all variants and states." O Claude gera o componente e a documentacao visual de uma vez.
🔌 API Endpoint Building (Backend Prompt)
Endpoints de API tem requisitos especificos: validacao de input, tratamento de erros, autorizacao, paginacao. O API Endpoint prompt garante que nenhum desses aspectos seja esquecido, produzindo endpoints production-ready desde o inicio.
🎯 Conceito Principal
- • Validacao com mensagens: Nao basta validar. O usuario precisa saber o que errou. "email is required" e melhor que "validation error"
- • Status codes corretos: 201 para criacao, 404 para nao encontrado, 422 para validacao. O Claude conhece todos os status codes HTTP e usa corretamente quando instruido
- • Auth/authz: Especificar que o endpoint precisa de autenticacao evita o erro classico de endpoints publicos que deveriam ser protegidos
💡 Dica Pratica
Para APIs RESTful completas, construa um endpoint CRUD completo de uma vez com o prompt: "Build full CRUD for [resource]: GET list (with pagination), GET by id, POST, PUT, DELETE. Follow REST conventions and existing patterns." O Claude gera todos os endpoints consistentes entre si.
🔗 Full-Stack Feature Workflow
A maioria das features do mundo real e full-stack: banco de dados + backend + frontend. O workflow completo combina todos os prompts deste modulo numa sequencia end-to-end que produz features completas com qualidade de producao.
🎯 Conceito Principal
O workflow full-stack segue esta sequencia:
- • Passo 1 - Feature Blueprint: Planejar a feature completa: schema, API, componentes, testes
- • Passo 2 - Database/Schema: Criar ou modificar o schema do banco. Migrations se necessario
- • Passo 3 - API Endpoints: Construir os endpoints com validacao, auth e error handling
- • Passo 4 - UI Components: Construir os componentes que consomem a API
- • Passo 5 - Integration: Conectar tudo e testar o fluxo end-to-end
- • Passo 6 - Brutal Audit: Auditar a feature completa antes de considerar pronta
💡 Dica Pratica
Para features grandes, use sessoes separadas para cada camada (database, API, UI). Isso mantem o contexto limpo e evita que o Claude misture preocupacoes de backend com frontend. Referencie os arquivos criados nas etapas anteriores explicitamente em cada nova sessao.
Exercicio Pratico
Construir feature usando Build With Tests prompt
Escolha uma feature simples (ex: funcao de validacao de email, endpoint de criacao de usuario, componente de formulario) e construa usando TDD:
- 1. Descreva a feature e use o Feature Blueprint para planejar
- 2. Use o Build With Tests para implementar com TDD. Observe o ciclo red-green
- 3. Verifique que todos os testes passam ao final
- 4. Rode um Brutal Audit no resultado e corrija issues encontrados
✅ Criterios de Sucesso
📋 Resumo do Modulo
Proximo Modulo:
4.4 - Prompts de Debugging e Log Analysis