kakaroto-config 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +48 -0
- package/bin/install.js +101 -0
- package/config/ARCHITECTURE.md +474 -0
- package/config/CLAUDE.md +24 -0
- package/config/agents/code-reviewer.md +265 -0
- package/config/agents/code-simplifier.md +151 -0
- package/config/agents/dry-enforcer.md +227 -0
- package/config/agents/memory-sync.md +140 -0
- package/config/agents/terraform-validator.md +275 -0
- package/config/agents/test-fixer.md +355 -0
- package/config/agents/visual-validator.md +296 -0
- package/config/commands/debug/01-investigate.md +119 -0
- package/config/commands/debug/02-fix.md +108 -0
- package/config/commands/debug/03-verify.md +66 -0
- package/config/commands/debug.md +19 -0
- package/config/commands/feature/01-interview.md +151 -0
- package/config/commands/feature/02-spec.md +174 -0
- package/config/commands/feature/03-planner.md +123 -0
- package/config/commands/feature/04-implement.md +74 -0
- package/config/commands/feature/05-quality.md +122 -0
- package/config/commands/feature.md +19 -0
- package/config/commands/gate.md +313 -0
- package/package.json +26 -0
|
@@ -0,0 +1,119 @@
|
|
|
1
|
+
# Fase 1: Investigate
|
|
2
|
+
|
|
3
|
+
## Passo 1: Carregar Contexto
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
mcp__memory__search_nodes({ query: "config" })
|
|
7
|
+
mcp__memory__search_nodes({ query: "<termos-do-bug>" })
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
Extrair termos relevantes de $ARGUMENTS e buscar bugs similares já resolvidos.
|
|
11
|
+
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
## Passo 2: Reproduzir Bug
|
|
15
|
+
|
|
16
|
+
### 2.1 Executar Passos
|
|
17
|
+
Tentar reproduzir com informações fornecidas.
|
|
18
|
+
|
|
19
|
+
### 2.2 Documentar
|
|
20
|
+
```
|
|
21
|
+
REPRODUÇÃO:
|
|
22
|
+
- Passos: [...]
|
|
23
|
+
- Input: [...]
|
|
24
|
+
- Output esperado: [...]
|
|
25
|
+
- Output real: [...]
|
|
26
|
+
- Reproduzido: SIM/NAO
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
### 2.3 Gate
|
|
30
|
+
Se NÃO reproduziu: usar AskUserQuestion para mais detalhes.
|
|
31
|
+
Se reproduziu: continuar.
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Passo 3: Verificar Estado Externo (OBRIGATÓRIO para scraping/browser)
|
|
36
|
+
|
|
37
|
+
**SE o bug envolve:** web scraping, Playwright, Puppeteer, seletores, ou qualquer interação com páginas web externas:
|
|
38
|
+
|
|
39
|
+
### 3.1 VERIFICAR ANTES DE ASSUMIR
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
1. mcp__playwright__browser_navigate({ url: "[URL do bug]" })
|
|
43
|
+
2. mcp__playwright__browser_wait_for({ time: 3 })
|
|
44
|
+
3. mcp__playwright__browser_snapshot({})
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
### 3.2 Comparar Estado Atual vs Esperado
|
|
48
|
+
|
|
49
|
+
- O que o código espera encontrar?
|
|
50
|
+
- O que realmente existe na página?
|
|
51
|
+
- Quais seletores existem/mudaram?
|
|
52
|
+
|
|
53
|
+
### 3.3 Gate
|
|
54
|
+
|
|
55
|
+
- [ ] Estado atual da página VERIFICADO com Playwright?
|
|
56
|
+
- [ ] Diferenças entre esperado e real DOCUMENTADAS?
|
|
57
|
+
|
|
58
|
+
**PROIBIDO:** Assumir que "a página mudou" sem verificar. SEMPRE abrir a URL e constatar.
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## Passo 4: Explorar Código Relacionado
|
|
63
|
+
|
|
64
|
+
### 4.1 Buscar no Codebase
|
|
65
|
+
```
|
|
66
|
+
Grep: termos do bug
|
|
67
|
+
Glob: arquivos com nomes relacionados
|
|
68
|
+
git log --oneline --grep="fix" -- [arquivos suspeitos]
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
### 4.2 Identificar
|
|
72
|
+
- Arquivos/funções envolvidos
|
|
73
|
+
- Como erros são tratados nesta área
|
|
74
|
+
- Há validação que deveria existir?
|
|
75
|
+
- Há helper existente que resolve?
|
|
76
|
+
|
|
77
|
+
---
|
|
78
|
+
|
|
79
|
+
## Passo 5: 5 Whys (Causa Raiz)
|
|
80
|
+
|
|
81
|
+
Para cada "Por que?", fornecer EVIDÊNCIA de código:
|
|
82
|
+
|
|
83
|
+
```
|
|
84
|
+
ANÁLISE DE CAUSA RAIZ:
|
|
85
|
+
|
|
86
|
+
Sintoma: [o que está acontecendo]
|
|
87
|
+
|
|
88
|
+
Por que #1: [resposta]
|
|
89
|
+
Evidência: [arquivo:linha] - [código]
|
|
90
|
+
|
|
91
|
+
Por que #2: [resposta]
|
|
92
|
+
Evidência: [arquivo:linha] - [código]
|
|
93
|
+
|
|
94
|
+
Por que #3: [resposta]
|
|
95
|
+
Evidência: [arquivo:linha] - [código]
|
|
96
|
+
|
|
97
|
+
CAUSA RAIZ: [declaração clara]
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Passo 6: Validar Causa Raiz
|
|
103
|
+
|
|
104
|
+
A causa raiz deve ser:
|
|
105
|
+
- [ ] Algo que você pode MUDAR
|
|
106
|
+
- [ ] Suportada por evidência de código
|
|
107
|
+
- [ ] Explica TODOS os sintomas
|
|
108
|
+
|
|
109
|
+
Se não validar: voltar ao Passo 5.
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## Output
|
|
114
|
+
|
|
115
|
+
Causa raiz documentada com evidência.
|
|
116
|
+
|
|
117
|
+
---
|
|
118
|
+
## PRÓXIMA FASE
|
|
119
|
+
AÇÃO OBRIGATÓRIA: Read ~/.claude/commands/debug/02-fix.md
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
# Fase 2: Fix
|
|
2
|
+
|
|
3
|
+
## Contexto
|
|
4
|
+
Causa raiz identificada. Implementar fix de forma AUTÔNOMA.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Passo 0: Gate de Criticidade
|
|
9
|
+
|
|
10
|
+
### 0.1 Identificar Paths Afetados
|
|
11
|
+
|
|
12
|
+
Extrair arquivos da causa raiz documentada na investigacao (fase 01-investigate).
|
|
13
|
+
|
|
14
|
+
### 0.2 Lista de Paths Criticos
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
PATHS_CRITICOS:
|
|
18
|
+
- **/auth/**
|
|
19
|
+
- **/payment/**
|
|
20
|
+
- **/migration*/**
|
|
21
|
+
- **/oauth*
|
|
22
|
+
- **/credential*
|
|
23
|
+
- **/secret*
|
|
24
|
+
- api/middleware.ts
|
|
25
|
+
- services/*Service.ts (core services)
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
### 0.3 Decision Gate
|
|
29
|
+
|
|
30
|
+
**SE** arquivos afetados ∩ PATHS_CRITICOS **nao vazio**:
|
|
31
|
+
|
|
32
|
+
1. Documentar fix planejado:
|
|
33
|
+
- Causa raiz (com evidencia)
|
|
34
|
+
- Arquivos a modificar
|
|
35
|
+
- Mudancas propostas
|
|
36
|
+
- Riscos identificados
|
|
37
|
+
|
|
38
|
+
2. Chamar `EnterPlanMode`
|
|
39
|
+
- Escrever plano de fix em `.claude/plans/debug-fix-{timestamp}.md`
|
|
40
|
+
- User aprova ou rejeita via ExitPlanMode
|
|
41
|
+
|
|
42
|
+
3. Apos aprovacao: Prosseguir para Passo 1
|
|
43
|
+
|
|
44
|
+
**SENAO** (nao critico):
|
|
45
|
+
Prosseguir direto para Passo 1 (autonomia total)
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## Passo 1: Teste de Regressao
|
|
50
|
+
|
|
51
|
+
### 1.1 Criar Teste que Reproduz o Bug
|
|
52
|
+
```typescript
|
|
53
|
+
describe('[contexto do bug]', () => {
|
|
54
|
+
it('should [comportamento esperado]', () => {
|
|
55
|
+
// Arrange: setup que causa o bug
|
|
56
|
+
// Act: ação que dispara o bug
|
|
57
|
+
// Assert: verificar comportamento correto
|
|
58
|
+
})
|
|
59
|
+
})
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### 1.2 Verificar que Teste FALHA
|
|
63
|
+
```bash
|
|
64
|
+
npm test -- --testPathPattern="[arquivo]"
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
O teste DEVE falhar antes do fix. Se passar, o teste não reproduz o bug.
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## Passo 2: Implementar Fix
|
|
72
|
+
|
|
73
|
+
### 2.1 Fix Mínimo
|
|
74
|
+
```
|
|
75
|
+
FIX:
|
|
76
|
+
Arquivo: [arquivo:linha]
|
|
77
|
+
Antes: [código atual]
|
|
78
|
+
Depois: [código novo]
|
|
79
|
+
Justificativa: [por que resolve a causa raiz]
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### 2.2 Regras
|
|
83
|
+
- APENAS o necessário para resolver a causa raiz
|
|
84
|
+
- NÃO refatorar código não relacionado
|
|
85
|
+
- NÃO adicionar features
|
|
86
|
+
- Seguir patterns existentes do projeto
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## Passo 3: Verificar Fix
|
|
91
|
+
|
|
92
|
+
### 3.1 Teste Deve Passar
|
|
93
|
+
```bash
|
|
94
|
+
npm test -- --testPathPattern="[arquivo]"
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### 3.2 Bug Não Reproduz
|
|
98
|
+
Executar passos originais. Bug não deve ocorrer.
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Output
|
|
103
|
+
|
|
104
|
+
Fix implementado. Teste de regressão passando.
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
## PRÓXIMA FASE
|
|
108
|
+
AÇÃO OBRIGATÓRIA: Read ~/.claude/commands/debug/03-verify.md
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
# Fase 3: Verify
|
|
2
|
+
|
|
3
|
+
## Contexto
|
|
4
|
+
Fix implementado. Verificar e finalizar de forma AUTÔNOMA.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Passo 1: Quality Gates
|
|
9
|
+
|
|
10
|
+
Rodar em sequência:
|
|
11
|
+
```bash
|
|
12
|
+
npm test
|
|
13
|
+
npx tsc --noEmit
|
|
14
|
+
npm run build
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
**Se falhar:** Corrigir e rodar novamente. Não prosseguir até passar.
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## Passo 2: Verificação Final
|
|
22
|
+
|
|
23
|
+
- [ ] Testes passam
|
|
24
|
+
- [ ] TypeScript sem erros
|
|
25
|
+
- [ ] Build bem-sucedido
|
|
26
|
+
- [ ] Bug não reproduz mais
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Passo 3: Memory Sync (se bug não-óbvio)
|
|
31
|
+
|
|
32
|
+
Se o bug foi difícil de encontrar, salvar na memory:
|
|
33
|
+
|
|
34
|
+
```javascript
|
|
35
|
+
mcp__memory__create_entities({
|
|
36
|
+
entities: [{
|
|
37
|
+
name: "{prefix}:bug:{nome-descritivo}",
|
|
38
|
+
entityType: "bug",
|
|
39
|
+
observations: [
|
|
40
|
+
"Sintoma: [...]",
|
|
41
|
+
"Causa raiz: [...]",
|
|
42
|
+
"Solução: [...]",
|
|
43
|
+
"Arquivos: [...]"
|
|
44
|
+
]
|
|
45
|
+
}]
|
|
46
|
+
})
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## Passo 4: Relatório Final
|
|
52
|
+
|
|
53
|
+
Reportar ao user:
|
|
54
|
+
- Bug resolvido
|
|
55
|
+
- Causa raiz identificada
|
|
56
|
+
- Fix implementado
|
|
57
|
+
- Teste de regressão criado
|
|
58
|
+
- Quality gates passando
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## Regras Invioláveis
|
|
63
|
+
|
|
64
|
+
1. **PROIBIDO** prosseguir com testes falhando
|
|
65
|
+
2. **PROIBIDO** prosseguir com build falhando
|
|
66
|
+
3. **PROIBIDO** perguntar ao user (só reportar no final)
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
model: opus
|
|
3
|
+
---
|
|
4
|
+
# Debug Workflow
|
|
5
|
+
|
|
6
|
+
Investigar e resolver: $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
## INICIAR
|
|
9
|
+
AÇÃO OBRIGATÓRIA: Read ~/.claude/commands/debug/01-investigate.md
|
|
10
|
+
Seguir instruções. Cada fase aponta para a próxima.
|
|
11
|
+
|
|
12
|
+
## Fluxo
|
|
13
|
+
Investigate → Fix → Verify → Fim (SEM PARADAS)
|
|
14
|
+
|
|
15
|
+
## Regras
|
|
16
|
+
1. ZERO paradas até o final
|
|
17
|
+
2. ZERO perguntas ao user (exceto se não conseguir reproduzir)
|
|
18
|
+
3. Fix mínimo - só o necessário para resolver
|
|
19
|
+
4. Erros: corrigir e continuar, não abandonar
|
|
@@ -0,0 +1,151 @@
|
|
|
1
|
+
# Fase 1: Interview
|
|
2
|
+
|
|
3
|
+
## Passo 1: Exploração Autônoma (ANTES de qualquer pergunta)
|
|
4
|
+
|
|
5
|
+
### 1.1 Carregar Contexto
|
|
6
|
+
```
|
|
7
|
+
mcp__memory__search_nodes({ query: "config" })
|
|
8
|
+
mcp__memory__search_nodes({ query: "<termos-da-feature>" })
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
### 1.2 Explorar Codebase
|
|
12
|
+
```
|
|
13
|
+
Glob: **/*.ts, **/*.tsx
|
|
14
|
+
Read: package.json, schema.prisma (se existir)
|
|
15
|
+
Grep: termos relacionados à feature
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
### 1.3 Identificar Patterns
|
|
19
|
+
- Como components similares funcionam
|
|
20
|
+
- Como services são estruturados
|
|
21
|
+
- Como erros são tratados
|
|
22
|
+
- Como loading states funcionam
|
|
23
|
+
|
|
24
|
+
**Você DEVE saber (não perguntar):**
|
|
25
|
+
- Estrutura de pastas
|
|
26
|
+
- Schema do banco
|
|
27
|
+
- Libs disponíveis
|
|
28
|
+
- Patterns existentes
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Passo 2: Reflexão (ANTES de perguntar)
|
|
33
|
+
|
|
34
|
+
Usar `mcp__sequential-thinking__sequentialthinking`:
|
|
35
|
+
|
|
36
|
+
1. **O que descobri** - Síntese da exploração (patterns, services, schema encontrados)
|
|
37
|
+
2. **O que ainda posso descobrir** - Gaps que consigo preencher explorando mais código
|
|
38
|
+
3. **O que APENAS o user pode responder** - Decisões de produto, preferências de UX
|
|
39
|
+
4. **Tentar descobrir o que falta** - Última tentativa autônoma antes de perguntar
|
|
40
|
+
5. **Formular perguntas mínimas** - Só o essencial que não consegui descobrir
|
|
41
|
+
|
|
42
|
+
`totalThoughts`: 5
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Passo 3: Perguntas ao User (APENAS decisões de produto)
|
|
47
|
+
|
|
48
|
+
**Usar AskUserQuestion para todas as perguntas.**
|
|
49
|
+
|
|
50
|
+
### 3.1 Problema e Escopo
|
|
51
|
+
```javascript
|
|
52
|
+
AskUserQuestion({
|
|
53
|
+
questions: [
|
|
54
|
+
{
|
|
55
|
+
question: "Qual problema principal essa feature resolve?",
|
|
56
|
+
header: "Problema",
|
|
57
|
+
multiSelect: false,
|
|
58
|
+
options: [
|
|
59
|
+
{ label: "Eficiência", description: "Processo manual que precisa ser automatizado" },
|
|
60
|
+
{ label: "Funcionalidade", description: "Capacidade que não existe hoje" },
|
|
61
|
+
{ label: "UX", description: "Experiência que precisa melhorar" }
|
|
62
|
+
]
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
question: "Qual escopo para primeira versão?",
|
|
66
|
+
header: "Escopo",
|
|
67
|
+
multiSelect: false,
|
|
68
|
+
options: [
|
|
69
|
+
{ label: "MVP mínimo", description: "Só o essencial" },
|
|
70
|
+
{ label: "MVP completo", description: "Casos principais cobertos" },
|
|
71
|
+
{ label: "Feature completa", description: "Todos os casos de uso" }
|
|
72
|
+
]
|
|
73
|
+
}
|
|
74
|
+
]
|
|
75
|
+
})
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### 3.2 UX (se aplicável)
|
|
79
|
+
```javascript
|
|
80
|
+
AskUserQuestion({
|
|
81
|
+
questions: [{
|
|
82
|
+
question: "Há design/mockup de referência?",
|
|
83
|
+
header: "Design",
|
|
84
|
+
multiSelect: false,
|
|
85
|
+
options: [
|
|
86
|
+
{ label: "Sim, tenho", description: "Vou compartilhar" },
|
|
87
|
+
{ label: "Seguir padrão", description: "Usar patterns do app" },
|
|
88
|
+
{ label: "Proponha", description: "Quero sugestão" }
|
|
89
|
+
]
|
|
90
|
+
}]
|
|
91
|
+
})
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### 3.3 Trade-offs (apenas se houver decisão com impacto)
|
|
95
|
+
```javascript
|
|
96
|
+
AskUserQuestion({
|
|
97
|
+
questions: [{
|
|
98
|
+
question: "Encontrei 2 approaches. Qual prefere?",
|
|
99
|
+
header: "Approach",
|
|
100
|
+
multiSelect: false,
|
|
101
|
+
options: [
|
|
102
|
+
{ label: "Approach A", description: "[trade-off A]" },
|
|
103
|
+
{ label: "Approach B", description: "[trade-off B]" }
|
|
104
|
+
]
|
|
105
|
+
}]
|
|
106
|
+
})
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Passo 4: Apresentar Descobertas
|
|
112
|
+
|
|
113
|
+
Mostrar ao user:
|
|
114
|
+
- Services/patterns encontrados
|
|
115
|
+
- Tabelas relevantes do schema
|
|
116
|
+
- Libs que serão usadas
|
|
117
|
+
- Pattern que será seguido
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Passo 5: Checkpoint
|
|
122
|
+
|
|
123
|
+
Usar TodoWrite para registrar conclusao da fase:
|
|
124
|
+
|
|
125
|
+
```javascript
|
|
126
|
+
TodoWrite({
|
|
127
|
+
todos: [
|
|
128
|
+
{ content: "Interview: contexto carregado", status: "completed", activeForm: "Loading context" },
|
|
129
|
+
{ content: "Interview: codebase explorado", status: "completed", activeForm: "Exploring codebase" },
|
|
130
|
+
{ content: "Interview: perguntas respondidas", status: "completed", activeForm: "Answering questions" },
|
|
131
|
+
{ content: "Interview: descobertas documentadas", status: "completed", activeForm: "Documenting findings" },
|
|
132
|
+
{ content: "Spec: gerar especificacao", status: "pending", activeForm: "Generating spec" }
|
|
133
|
+
]
|
|
134
|
+
})
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
**Gate:** SE items de Interview nao estao "completed" → Completar antes de prosseguir
|
|
138
|
+
|
|
139
|
+
---
|
|
140
|
+
|
|
141
|
+
## Output
|
|
142
|
+
|
|
143
|
+
Resumo estruturado:
|
|
144
|
+
- Problema identificado
|
|
145
|
+
- Escopo definido
|
|
146
|
+
- Decisões de UX
|
|
147
|
+
- Patterns a seguir
|
|
148
|
+
|
|
149
|
+
---
|
|
150
|
+
## PRÓXIMA FASE
|
|
151
|
+
AÇÃO OBRIGATÓRIA: Read ~/.claude/commands/feature/02-spec.md
|
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
# Fase 2: Spec
|
|
2
|
+
|
|
3
|
+
## Passo 0: Context
|
|
4
|
+
|
|
5
|
+
Contexto de projeto ja carregado em 01-interview (mesma sessao).
|
|
6
|
+
Buscar apenas patterns para reutilizacao:
|
|
7
|
+
|
|
8
|
+
```
|
|
9
|
+
mcp__memory__search_nodes({ query: "pattern" })
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
SE retomando sessao interrompida:
|
|
13
|
+
```
|
|
14
|
+
Read .claude/specs/current.md (se existir)
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## Passo 1: Pensamento Estruturado
|
|
20
|
+
|
|
21
|
+
Usar `mcp__sequential-thinking__sequentialthinking` para planejar:
|
|
22
|
+
|
|
23
|
+
1. **Thought 1**: Quais componentes esta feature precisa?
|
|
24
|
+
2. **Thought 2**: Onde código similar existe no codebase?
|
|
25
|
+
3. **Thought 3**: Quais patterns do projeto devo seguir?
|
|
26
|
+
4. **Thought 4**: Quais trade-offs arquiteturais existem?
|
|
27
|
+
5. **Thought 5**: Qual a abordagem mais simples que resolve?
|
|
28
|
+
|
|
29
|
+
`totalThoughts`: 5-8 (ajustar conforme complexidade)
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Passo 2: Análise de Reutilização
|
|
34
|
+
|
|
35
|
+
### 2.1 Buscar Código Existente
|
|
36
|
+
```
|
|
37
|
+
Grep: termos da feature em services/, utils/, lib/
|
|
38
|
+
Glob: arquivos com nomes similares
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### 1.2 Mapear Reutilização
|
|
42
|
+
| Necessidade | Código Existente | Ação |
|
|
43
|
+
|-------------|------------------|------|
|
|
44
|
+
| [o que precisa] | [arquivo:linha] | Reutilizar/Estender/Criar |
|
|
45
|
+
|
|
46
|
+
**Default = reutilizar. Código novo precisa justificativa.**
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Passo 2: Gerar Spec
|
|
51
|
+
|
|
52
|
+
```markdown
|
|
53
|
+
# Spec: [Nome da Feature]
|
|
54
|
+
|
|
55
|
+
**Status:** Draft
|
|
56
|
+
|
|
57
|
+
## Problema
|
|
58
|
+
[1-2 frases - o problema, não a solução]
|
|
59
|
+
|
|
60
|
+
## Solução
|
|
61
|
+
[Descrição de alto nível]
|
|
62
|
+
|
|
63
|
+
## Escopo
|
|
64
|
+
|
|
65
|
+
### Inclui
|
|
66
|
+
- [Deliverable 1]
|
|
67
|
+
- [Deliverable 2]
|
|
68
|
+
|
|
69
|
+
### Não Inclui
|
|
70
|
+
- [O que não será feito]
|
|
71
|
+
|
|
72
|
+
## Design Técnico
|
|
73
|
+
|
|
74
|
+
### Dados
|
|
75
|
+
[Estruturas, campos novos, tabelas]
|
|
76
|
+
|
|
77
|
+
### Services
|
|
78
|
+
| Service | Mudanças |
|
|
79
|
+
|---------|----------|
|
|
80
|
+
| [nome] | [o que muda] |
|
|
81
|
+
|
|
82
|
+
### API (se aplicável)
|
|
83
|
+
[Endpoints, signatures]
|
|
84
|
+
|
|
85
|
+
### Tratamento de Erros
|
|
86
|
+
| Cenário | Comportamento |
|
|
87
|
+
|---------|---------------|
|
|
88
|
+
| [erro] | [o que acontece] |
|
|
89
|
+
|
|
90
|
+
### Reutilização Obrigatória
|
|
91
|
+
| Existente | Uso |
|
|
92
|
+
|-----------|-----|
|
|
93
|
+
| [código] | [como usar] |
|
|
94
|
+
|
|
95
|
+
### Justificativa para Código Novo
|
|
96
|
+
| Novo Código | Por que não reutilizar existente? |
|
|
97
|
+
|-------------|-----------------------------------|
|
|
98
|
+
| [arquivo/função] | [justificativa] |
|
|
99
|
+
|
|
100
|
+
## UI/UX (se aplicável)
|
|
101
|
+
|
|
102
|
+
### Fluxo
|
|
103
|
+
1. User faz X
|
|
104
|
+
2. Sistema responde Y
|
|
105
|
+
|
|
106
|
+
### Estados
|
|
107
|
+
| Estado | Display |
|
|
108
|
+
|--------|---------|
|
|
109
|
+
| Loading | [desc] |
|
|
110
|
+
| Empty | [desc] |
|
|
111
|
+
| Error | [desc] |
|
|
112
|
+
| Success | [desc] |
|
|
113
|
+
|
|
114
|
+
## Edge Cases
|
|
115
|
+
| Caso | Tratamento |
|
|
116
|
+
|------|------------|
|
|
117
|
+
| [edge] | [como tratar] |
|
|
118
|
+
|
|
119
|
+
## Testes
|
|
120
|
+
|
|
121
|
+
### Unitários (OBRIGATÓRIO)
|
|
122
|
+
| Função | Arquivo Teste | Casos |
|
|
123
|
+
|--------|---------------|-------|
|
|
124
|
+
| [func] | [file.test.ts] | [casos] |
|
|
125
|
+
|
|
126
|
+
## Decisões
|
|
127
|
+
| Decisão | Justificativa |
|
|
128
|
+
|---------|---------------|
|
|
129
|
+
| [escolha] | [por quê] |
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## Output
|
|
135
|
+
|
|
136
|
+
1. MOSTRAR spec completa ao user (visibilidade)
|
|
137
|
+
2. Spec = contrato, implementacao deve seguir
|
|
138
|
+
|
|
139
|
+
---
|
|
140
|
+
|
|
141
|
+
## Passo 3: Persistir Spec
|
|
142
|
+
|
|
143
|
+
1. Gerar slug: primeira palavra do problema + data
|
|
144
|
+
Exemplo: `filtro-2026-01-10.md`
|
|
145
|
+
|
|
146
|
+
2. Salvar spec:
|
|
147
|
+
```
|
|
148
|
+
Write .claude/specs/{slug}.md
|
|
149
|
+
Write .claude/specs/current.md (copia do conteudo)
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
3. Confirmar: "Spec salva em .claude/specs/{slug}.md"
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Passo 4: Checkpoint
|
|
157
|
+
|
|
158
|
+
Atualizar TodoWrite com conclusao da spec:
|
|
159
|
+
|
|
160
|
+
```javascript
|
|
161
|
+
TodoWrite({
|
|
162
|
+
todos: [
|
|
163
|
+
// items anteriores como completed
|
|
164
|
+
{ content: "Spec: especificacao gerada", status: "completed", activeForm: "Generating spec" },
|
|
165
|
+
{ content: "Spec: reutilizacao mapeada", status: "completed", activeForm: "Mapping reuse" },
|
|
166
|
+
{ content: "Spec: spec persistida em arquivo", status: "completed", activeForm: "Persisting spec" },
|
|
167
|
+
{ content: "Planner: criar plano de tarefas", status: "pending", activeForm: "Creating plan" }
|
|
168
|
+
]
|
|
169
|
+
})
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
---
|
|
173
|
+
## PROXIMA FASE
|
|
174
|
+
ACAO OBRIGATORIA: Read ~/.claude/commands/feature/03-planner.md
|