🎯 Escolhendo o projeto certo
O primeiro projeto onde você aplica o método determina se vai querer usá-lo novamente. Escolha um projeto onde a metodologia possa brilhar — não um onde a complexidade do domínio vai obscurecer o que está aprendendo sobre o método.
Critérios para um bom primeiro projeto
✓ Bom candidato
- • Escopo em 1-2 páginas de SPEC
- • Um único ponto de integração
- • Resultado verificável em minutos
- • Sem dependências externas complexas
- • Você consegue descrever em uma frase
✗ Mau candidato
- • Integra com 3+ serviços externos
- • Requer autenticação e autorização
- • Domínio que você não conhece bem
- • Prazo apertado sem margem para aprendizado
- • Resultado depende de dados externos
💡 Exemplos de bons primeiros projetos
- •Hook de PreToolUse que loga operações de arquivo em JSON
- •Plugin que exibe um resumo do contexto atual antes de cada commit
- •Stop Hook que envia notificação quando uma sessão longa termina
- •Plugin que mantém um log de todas as ferramentas usadas na sessão
📋 Escrevendo o SPEC do seu projeto
Exercício prático: 30 minutos para preencher o template de SPEC para o projeto que você escolheu. O objetivo não é o SPEC perfeito — é descobrir onde as perguntas são difíceis.
Exercício: preencha agora (30 min)
1. Objetivo (2 min)
Em uma frase: "Este plugin X para que Y possa Z"
2. Componentes (5 min)
Liste 2-5 componentes. Para cada um: nome, responsabilidade única, o que NÃO é responsabilidade dele
3. Invariantes (8 min)
Complete: "O sistema NUNCA pode ___". Mínimo 3 invariantes. Inclua fail-open obrigatoriamente.
4. Interface pública (5 min)
Como invocar o sistema, que parâmetros recebe, o que retorna em sucesso e em falha
5. Sequência de build (5 min)
Liste 4-6 camadas na ordem: scaffold → estado → lógica → segurança
6. Critérios de aceitação (5 min)
Para cada camada da sequência: "a camada está completa quando ___"
🔢 Quebrando em prompts
Com o SPEC completo, o próximo passo é transformar a sequência de build em prompts concretos. Para cada camada, definir: o que já existe (pré-condições), o que este prompt cria (entrega) e como verificar (critério).
Exemplo: plugin de logging
Scaffold
Cria hooks/pre_tool_use.sh com fail-open. Aceita: nada. Verifica: arquivo existe, invocável, exit 0 sempre.
Estado
Cria log.json com schema {entries:[]}. Aceita: P1 verificado. Verifica: inicializa, lê, adiciona entrada sem corrupção.
Lógica
Hook lê stdin JSON, extrai ferramenta e input, adiciona ao log. Aceita: P2 verificado. Verifica: entry correta no log após invocação.
Segurança
Write atômico, ERR trap, lockfile. Aceita: P3 verificado. Verifica: kill durante write não corrompe, 2 instâncias concorrentes ok.
⚡ Identificando as primitivas de segurança do seu projeto
Nem todo projeto precisa das seis primitivas com a mesma intensidade. A análise de primitivas relevantes identifica quais são críticas para o seu projeto específico — evitando over-engineering e garantindo que as críticas não sejam esquecidas.
Perguntas para cada primitiva
🧪 Definindo as verificações entre prompts
Para cada prompt da sua sequência, defina os critérios de aceitação antes de executar o prompt. Critérios definidos antes são objetivos — critérios definidos depois tendem a se ajustar ao que foi entregue.
Formato de critério de aceitação
Prompt N está completo quando:
1. [arquivo ou artefato esperado] existe e é válido
2. Executar [comando concreto] produz [resultado concreto]
3. Forçar [falha específica] resulta em [comportamento esperado]
4. Regressão: todos os testes de camadas anteriores ainda passam
💡 O sinal de critério ruim
Se você não consegue escrever o critério antes de ver o código, o requisito está ambíguo. A dificuldade de escrever o critério é informação valiosa — indica que você não sabe o que quer, e o modelo vai ter a mesma dificuldade.
🚀 Checklist de pré-build
O checklist de pré-build é a última verificação antes de enviar o primeiro prompt. Confirmar cada item garante que você está planejando um build, não uma série de tentativas.
Checklist completo
Quando você está pronto
Se todos os seis itens do checklist estão confirmados, você tem um plano. Não uma lista de desejos, não uma vaga ideia — um plano com critérios objetivos de sucesso. Execute o Prompt 1, verifique, avance.
Isso é O Método.
🎓 Trilha 3 Concluída
Você agora tem o método completo. Os seis módulos cobriram os princípios que tornam o Claudex e qualquer plugin bem-construído possível:
Próxima Trilha:
Trilha 4 — Avançado: padrões complexos, otimizações e casos edge