context-first-cli 1.0.0 → 1.1.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/dist/commands/scaffold-orchestrator.d.ts.map +1 -1
- package/dist/commands/scaffold-orchestrator.js +37 -17
- package/dist/commands/scaffold-orchestrator.js.map +1 -1
- package/dist/templates/commands/engineer/plan.md +251 -0
- package/dist/templates/commands/engineer/pr.md +167 -0
- package/dist/templates/commands/engineer/pre-pr.md +262 -0
- package/dist/templates/commands/engineer/start.md +115 -0
- package/dist/templates/commands/engineer/work.md +125 -0
- package/dist/templates/commands/products/check.md +201 -0
- package/dist/templates/commands/products/collect.md +129 -0
- package/dist/templates/commands/products/refine.md +182 -0
- package/dist/templates/commands/products/spec.md +239 -0
- package/dist/templates/commands/warm-up.md +65 -0
- package/package.json +4 -2
- package/templates/commands/engineer/plan.md +251 -0
- package/templates/commands/engineer/pr.md +167 -0
- package/templates/commands/engineer/pre-pr.md +262 -0
- package/templates/commands/engineer/start.md +115 -0
- package/templates/commands/engineer/work.md +125 -0
- package/templates/commands/products/check.md +201 -0
- package/templates/commands/products/collect.md +129 -0
- package/templates/commands/products/refine.md +182 -0
- package/templates/commands/products/spec.md +239 -0
- package/templates/commands/warm-up.md +65 -0
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
# Início do Desenvolvimento
|
|
2
|
+
|
|
3
|
+
Este comando inicia o desenvolvimento de uma funcionalidade no workspace atual.
|
|
4
|
+
|
|
5
|
+
## 🎯 Contexto do Projeto
|
|
6
|
+
|
|
7
|
+
Antes de iniciar, carregue o contexto consultando:
|
|
8
|
+
- `context-manifest.json` - Estrutura de repositórios
|
|
9
|
+
- `specs/business/index.md` - Contexto de negócio
|
|
10
|
+
- `specs/technical/index.md` - Stack, arquitetura e padrões técnicos
|
|
11
|
+
- `.workspace.json` - Informações do workspace atual
|
|
12
|
+
|
|
13
|
+
## ⚙️ Configuração Inicial
|
|
14
|
+
|
|
15
|
+
1. **Verificar Workspace**:
|
|
16
|
+
- Confirme que está no workspace correto (verifique `.workspace.json`)
|
|
17
|
+
- Liste os repositórios disponíveis no workspace
|
|
18
|
+
|
|
19
|
+
2. **Verificar Branches**:
|
|
20
|
+
- Para cada repositório no workspace, verifique a branch atual
|
|
21
|
+
- Confirme que todas as branches estão sincronizadas
|
|
22
|
+
|
|
23
|
+
3. **Carregar Especificação**:
|
|
24
|
+
- **Se task manager configurado**: Leia a issue usando o MCP apropriado
|
|
25
|
+
- **Senão**: Peça ao usuário o arquivo de especificação ou descrição da feature
|
|
26
|
+
|
|
27
|
+
4. **Atualizar Status** (se task manager configurado):
|
|
28
|
+
- Mova a issue para "Em Progresso"
|
|
29
|
+
|
|
30
|
+
## 📋 Análise e Entendimento
|
|
31
|
+
|
|
32
|
+
Analise a especificação e construa entendimento completo respondendo:
|
|
33
|
+
|
|
34
|
+
### Negócio
|
|
35
|
+
- **Por que** isso está sendo construído?
|
|
36
|
+
- **Quem** se beneficia?
|
|
37
|
+
- **Qual** métrica queremos impactar?
|
|
38
|
+
|
|
39
|
+
### Funcional
|
|
40
|
+
- **Qual resultado esperado**? (comportamento do usuário, output do sistema)
|
|
41
|
+
- **Quais componentes** serão criados/modificados em cada repositório?
|
|
42
|
+
- **Quais integrações** entre repositórios são necessárias?
|
|
43
|
+
|
|
44
|
+
### Técnico
|
|
45
|
+
- **Stack aprovada**? Verificar contra especificações técnicas
|
|
46
|
+
- **Padrões arquiteturais**? Verificar ADRs (se disponíveis)
|
|
47
|
+
- **Dependências novas**? Justificar e documentar
|
|
48
|
+
- **Como testar**? (conforme padrões do projeto)
|
|
49
|
+
|
|
50
|
+
### Validação contra Metaspecs
|
|
51
|
+
|
|
52
|
+
Se metaspecs estiverem disponíveis, validar:
|
|
53
|
+
- Alinhado com estratégia e roadmap?
|
|
54
|
+
- Usa stack tecnológica aprovada?
|
|
55
|
+
- Respeita Architecture Decision Records?
|
|
56
|
+
- Segue regras de negócio documentadas?
|
|
57
|
+
|
|
58
|
+
## 🤔 Perguntas de Esclarecimento
|
|
59
|
+
|
|
60
|
+
Após análise inicial, formule **3-5 clarificações mais importantes**:
|
|
61
|
+
|
|
62
|
+
**Exemplos de perguntas relevantes**:
|
|
63
|
+
- Qual repositório deve conter a lógica principal?
|
|
64
|
+
- Como os repositórios devem se comunicar?
|
|
65
|
+
- Há dependências entre as mudanças nos diferentes repos?
|
|
66
|
+
- Qual a ordem de implementação recomendada?
|
|
67
|
+
- Há impacto em APIs ou contratos entre serviços?
|
|
68
|
+
|
|
69
|
+
## 📝 Documentação da Sessão
|
|
70
|
+
|
|
71
|
+
Crie arquivo `./.context-sessions/<ISSUE-ID>/start.md` com:
|
|
72
|
+
|
|
73
|
+
```markdown
|
|
74
|
+
# [Título da Feature] - Início
|
|
75
|
+
|
|
76
|
+
## Entendimento
|
|
77
|
+
[Resumo do que será construído e por quê]
|
|
78
|
+
|
|
79
|
+
## Repositórios Afetados
|
|
80
|
+
- **repo-1**: [O que será feito]
|
|
81
|
+
- **repo-2**: [O que será feito]
|
|
82
|
+
|
|
83
|
+
## Perguntas Pendentes
|
|
84
|
+
1. [Pergunta 1]
|
|
85
|
+
2. [Pergunta 2]
|
|
86
|
+
|
|
87
|
+
## Validações Realizadas
|
|
88
|
+
- [x] Alinhado com estratégia
|
|
89
|
+
- [x] Stack aprovada
|
|
90
|
+
- [ ] Pendente: [algo a validar]
|
|
91
|
+
|
|
92
|
+
## Próximos Passos
|
|
93
|
+
1. Aguardar respostas das perguntas
|
|
94
|
+
2. Executar `/plan` para planejamento técnico detalhado
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
**Argumentos fornecidos**:
|
|
100
|
+
|
|
101
|
+
```
|
|
102
|
+
#$ARGUMENTS
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## 🎯 Próximo Passo
|
|
108
|
+
|
|
109
|
+
Após esclarecimentos e aprovação:
|
|
110
|
+
|
|
111
|
+
```bash
|
|
112
|
+
/plan
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
Este comando criará o planejamento técnico detalhado da implementação.
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
# Execução do Trabalho
|
|
2
|
+
|
|
3
|
+
Este comando executa uma unidade de trabalho no workspace atual, implementando parte do plano técnico.
|
|
4
|
+
|
|
5
|
+
## 📋 Pré-requisitos
|
|
6
|
+
|
|
7
|
+
Antes de executar, certifique-se de que:
|
|
8
|
+
- Executou `/warm-up` para carregar o contexto
|
|
9
|
+
- Executou `/start` e `/plan` para ter o planejamento técnico
|
|
10
|
+
- Está no workspace correto (verifique `.workspace.json`)
|
|
11
|
+
- Tem o arquivo `./.context-sessions/<ISSUE-ID>/plan.md` disponível
|
|
12
|
+
|
|
13
|
+
## 🎯 Objetivo
|
|
14
|
+
|
|
15
|
+
Implementar uma unidade de trabalho específica do plano, que pode envolver:
|
|
16
|
+
- Criar novos arquivos/componentes
|
|
17
|
+
- Modificar arquivos existentes
|
|
18
|
+
- Adicionar testes
|
|
19
|
+
- Atualizar documentação
|
|
20
|
+
|
|
21
|
+
## 📝 Processo de Trabalho
|
|
22
|
+
|
|
23
|
+
### 1. Identificar Unidade de Trabalho
|
|
24
|
+
|
|
25
|
+
Com base no plano técnico (`./.context-sessions/<ISSUE-ID>/plan.md`), identifique:
|
|
26
|
+
- Qual tarefa específica será implementada agora
|
|
27
|
+
- Em qual(is) repositório(s) do workspace
|
|
28
|
+
- Quais arquivos serão criados/modificados
|
|
29
|
+
- Dependências com outras tarefas
|
|
30
|
+
|
|
31
|
+
### 2. Implementação
|
|
32
|
+
|
|
33
|
+
Execute a implementação seguindo:
|
|
34
|
+
- **Padrões do projeto**: Consulte guias de estilo e arquitetura
|
|
35
|
+
- **Stack aprovada**: Use apenas tecnologias documentadas nas metaspecs
|
|
36
|
+
- **Testes**: Implemente testes conforme padrões do projeto
|
|
37
|
+
- **Documentação**: Atualize comentários e docs quando necessário
|
|
38
|
+
|
|
39
|
+
### 3. Validação Local
|
|
40
|
+
|
|
41
|
+
Antes de commitar:
|
|
42
|
+
- Execute testes unitários/integração
|
|
43
|
+
- Verifique linting e formatação
|
|
44
|
+
- Confirme que não quebrou funcionalidades existentes
|
|
45
|
+
|
|
46
|
+
### 4. Commit
|
|
47
|
+
|
|
48
|
+
Para cada repositório modificado:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
cd <repositório>
|
|
52
|
+
git add .
|
|
53
|
+
git commit -m "tipo: descrição concisa
|
|
54
|
+
|
|
55
|
+
- Detalhe 1
|
|
56
|
+
- Detalhe 2
|
|
57
|
+
|
|
58
|
+
Refs: <ISSUE-ID>"
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
**Tipos de commit**: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`
|
|
62
|
+
|
|
63
|
+
### 5. Documentação da Sessão
|
|
64
|
+
|
|
65
|
+
Atualize `./.context-sessions/<ISSUE-ID>/work.md`:
|
|
66
|
+
|
|
67
|
+
```markdown
|
|
68
|
+
# [Título da Feature] - Trabalho Executado
|
|
69
|
+
|
|
70
|
+
## [Data/Hora] - [Descrição da Unidade]
|
|
71
|
+
|
|
72
|
+
### Repositórios Modificados
|
|
73
|
+
- **repo-1**: [Arquivos modificados e o que foi feito]
|
|
74
|
+
- **repo-2**: [Arquivos modificados e o que foi feito]
|
|
75
|
+
|
|
76
|
+
### Decisões Tomadas
|
|
77
|
+
- [Decisão 1 e justificativa]
|
|
78
|
+
- [Decisão 2 e justificativa]
|
|
79
|
+
|
|
80
|
+
### Testes Adicionados
|
|
81
|
+
- [Descrição dos testes]
|
|
82
|
+
|
|
83
|
+
### Próxima Unidade
|
|
84
|
+
- [O que será feito a seguir]
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## 🔍 Checklist de Qualidade
|
|
88
|
+
|
|
89
|
+
Antes de considerar a unidade completa:
|
|
90
|
+
- [ ] Código implementado e testado
|
|
91
|
+
- [ ] Testes passando
|
|
92
|
+
- [ ] Linting/formatação OK
|
|
93
|
+
- [ ] Documentação atualizada (se necessário)
|
|
94
|
+
- [ ] Commit realizado em todos os repos afetados
|
|
95
|
+
- [ ] Sessão documentada
|
|
96
|
+
|
|
97
|
+
## ⚠️ Princípio Jidoka
|
|
98
|
+
|
|
99
|
+
Se encontrar problemas durante a implementação:
|
|
100
|
+
1. 🛑 **PARE** a implementação
|
|
101
|
+
2. 📝 **DOCUMENTE** o problema encontrado
|
|
102
|
+
3. 💬 **ALERTE** o usuário e discuta soluções
|
|
103
|
+
4. 🔄 **AJUSTE** o plano se necessário
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
**Argumentos fornecidos**:
|
|
108
|
+
|
|
109
|
+
```
|
|
110
|
+
#$ARGUMENTS
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 🎯 Próximos Passos
|
|
116
|
+
|
|
117
|
+
- **Continuar implementação**: Execute `/work` novamente para próxima unidade
|
|
118
|
+
- **Finalizar feature**: Quando tudo estiver implementado, execute `/pre-pr`
|
|
119
|
+
|
|
120
|
+
## 💡 Dicas
|
|
121
|
+
|
|
122
|
+
- Trabalhe em unidades pequenas e incrementais
|
|
123
|
+
- Commit frequentemente (atomic commits)
|
|
124
|
+
- Documente decisões importantes na sessão
|
|
125
|
+
- Mantenha os repositórios sincronizados entre si
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
# Validação contra Metaspecs
|
|
2
|
+
|
|
3
|
+
Este comando valida requisitos, decisões ou implementações contra as metaspecs do projeto.
|
|
4
|
+
|
|
5
|
+
## 🎯 Objetivo
|
|
6
|
+
|
|
7
|
+
Garantir alinhamento com:
|
|
8
|
+
- Estratégia de produto
|
|
9
|
+
- Arquitetura técnica
|
|
10
|
+
- Padrões e convenções
|
|
11
|
+
- ADRs (Architecture Decision Records)
|
|
12
|
+
|
|
13
|
+
## 📋 Quando Usar
|
|
14
|
+
|
|
15
|
+
Execute este comando:
|
|
16
|
+
- Após `/spec` - validar PRD
|
|
17
|
+
- Após `/plan` - validar plano técnico
|
|
18
|
+
- Durante `/work` - validar decisões de implementação
|
|
19
|
+
- Antes de `/pr` - validação final
|
|
20
|
+
|
|
21
|
+
## 🔍 Processo de Validação
|
|
22
|
+
|
|
23
|
+
### 1. Identificar Metaspecs Disponíveis
|
|
24
|
+
|
|
25
|
+
Navegue até o diretório do orchestrator e identifique quais metaspecs existem:
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
ls -la ../.context-orchestrator/specs/
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
### 2. Validação de Negócio
|
|
32
|
+
|
|
33
|
+
Se existirem metaspecs de negócio (`specs/business/`):
|
|
34
|
+
|
|
35
|
+
```markdown
|
|
36
|
+
## Validação de Negócio
|
|
37
|
+
|
|
38
|
+
### Estratégia de Produto
|
|
39
|
+
- **Arquivo**: `specs/business/PRODUCT_STRATEGY.md`
|
|
40
|
+
- **Validação**: [Esta feature está alinhada com a estratégia?]
|
|
41
|
+
- **Status**: ✅ Alinhado / ⚠️ Parcialmente / ❌ Desalinhado
|
|
42
|
+
- **Notas**: [Observações]
|
|
43
|
+
|
|
44
|
+
### Personas
|
|
45
|
+
- **Arquivo**: `specs/business/CUSTOMER_PERSONAS.md`
|
|
46
|
+
- **Validação**: [Atende a persona correta?]
|
|
47
|
+
- **Status**: ✅ Alinhado / ⚠️ Parcialmente / ❌ Desalinhado
|
|
48
|
+
- **Notas**: [Observações]
|
|
49
|
+
|
|
50
|
+
### Métricas
|
|
51
|
+
- **Arquivo**: `specs/business/PRODUCT_METRICS.md`
|
|
52
|
+
- **Validação**: [Métrica de sucesso está documentada?]
|
|
53
|
+
- **Status**: ✅ Alinhado / ⚠️ Parcialmente / ❌ Desalinhado
|
|
54
|
+
- **Notas**: [Observações]
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
### 3. Validação Técnica
|
|
58
|
+
|
|
59
|
+
Se existirem metaspecs técnicas (`specs/technical/`):
|
|
60
|
+
|
|
61
|
+
```markdown
|
|
62
|
+
## Validação Técnica
|
|
63
|
+
|
|
64
|
+
### Stack Tecnológica
|
|
65
|
+
- **Arquivo**: `specs/technical/meta/stack.md`
|
|
66
|
+
- **Validação**: [Usa apenas tecnologias aprovadas?]
|
|
67
|
+
- **Status**: ✅ Conforme / ⚠️ Exceção justificada / ❌ Não conforme
|
|
68
|
+
- **Notas**: [Tecnologias usadas e justificativas]
|
|
69
|
+
|
|
70
|
+
### Arquitetura
|
|
71
|
+
- **Arquivo**: `specs/technical/ARCHITECTURE.md`
|
|
72
|
+
- **Validação**: [Segue padrões arquiteturais?]
|
|
73
|
+
- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
|
|
74
|
+
- **Notas**: [Observações]
|
|
75
|
+
|
|
76
|
+
### ADRs (Architecture Decision Records)
|
|
77
|
+
- **Diretório**: `specs/technical/adr/`
|
|
78
|
+
- **Validação**: [Respeita decisões arquiteturais documentadas?]
|
|
79
|
+
- **ADRs Relevantes**: [Lista de ADRs verificados]
|
|
80
|
+
- **Status**: ✅ Conforme / ⚠️ Conflito menor / ❌ Conflito crítico
|
|
81
|
+
- **Notas**: [Observações]
|
|
82
|
+
|
|
83
|
+
### Regras de Negócio
|
|
84
|
+
- **Arquivo**: `specs/technical/BUSINESS_LOGIC.md`
|
|
85
|
+
- **Validação**: [Implementa regras de negócio corretamente?]
|
|
86
|
+
- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
|
|
87
|
+
- **Notas**: [Observações]
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### 4. Validação de Padrões
|
|
91
|
+
|
|
92
|
+
```markdown
|
|
93
|
+
## Validação de Padrões
|
|
94
|
+
|
|
95
|
+
### Código
|
|
96
|
+
- **Arquivo**: `specs/technical/CODE_STANDARDS.md`
|
|
97
|
+
- **Validação**: [Segue padrões de código?]
|
|
98
|
+
- **Status**: ✅ Conforme / ⚠️ Pequenos desvios / ❌ Não conforme
|
|
99
|
+
|
|
100
|
+
### Testes
|
|
101
|
+
- **Arquivo**: `specs/technical/TEST_STANDARDS.md`
|
|
102
|
+
- **Validação**: [Estratégia de testes adequada?]
|
|
103
|
+
- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
|
|
104
|
+
|
|
105
|
+
### Documentação
|
|
106
|
+
- **Arquivo**: `specs/technical/DOC_STANDARDS.md`
|
|
107
|
+
- **Validação**: [Documentação adequada?]
|
|
108
|
+
- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
### 5. Identificação de Conflitos
|
|
112
|
+
|
|
113
|
+
Se houver conflitos ou desalinhamentos:
|
|
114
|
+
|
|
115
|
+
```markdown
|
|
116
|
+
## Conflitos Identificados
|
|
117
|
+
|
|
118
|
+
### Conflito 1: [Descrição]
|
|
119
|
+
- **Severidade**: Crítico / Alto / Médio / Baixo
|
|
120
|
+
- **Metaspec**: [Arquivo que está sendo violado]
|
|
121
|
+
- **Descrição**: [Detalhe do conflito]
|
|
122
|
+
- **Recomendação**: [Como resolver]
|
|
123
|
+
|
|
124
|
+
### Conflito 2: [Descrição]
|
|
125
|
+
[Mesmo formato acima]
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
### 6. Exceções Justificadas
|
|
129
|
+
|
|
130
|
+
Se houver desvios justificados:
|
|
131
|
+
|
|
132
|
+
```markdown
|
|
133
|
+
## Exceções Justificadas
|
|
134
|
+
|
|
135
|
+
### Exceção 1: [Descrição]
|
|
136
|
+
- **Metaspec**: [Arquivo que está sendo desviado]
|
|
137
|
+
- **Desvio**: [O que está diferente]
|
|
138
|
+
- **Justificativa**: [Por que é necessário]
|
|
139
|
+
- **Aprovação**: [Quem aprovou]
|
|
140
|
+
- **Documentação**: [Onde foi documentado]
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
## 📄 Relatório de Validação
|
|
144
|
+
|
|
145
|
+
Crie `./.context-sessions/<ISSUE-ID>/check-report.md`:
|
|
146
|
+
|
|
147
|
+
```markdown
|
|
148
|
+
# Relatório de Validação - [ISSUE-ID]
|
|
149
|
+
|
|
150
|
+
**Data**: [data/hora]
|
|
151
|
+
**Fase**: [spec/plan/work/pre-pr]
|
|
152
|
+
|
|
153
|
+
## Status Geral
|
|
154
|
+
✅ Validado / ⚠️ Validado com ressalvas / ❌ Não validado
|
|
155
|
+
|
|
156
|
+
## Validações Realizadas
|
|
157
|
+
- Negócio: ✅ / ⚠️ / ❌
|
|
158
|
+
- Técnica: ✅ / ⚠️ / ❌
|
|
159
|
+
- Padrões: ✅ / ⚠️ / ❌
|
|
160
|
+
|
|
161
|
+
## Conflitos
|
|
162
|
+
[Lista de conflitos, se houver]
|
|
163
|
+
|
|
164
|
+
## Exceções
|
|
165
|
+
[Lista de exceções justificadas, se houver]
|
|
166
|
+
|
|
167
|
+
## Recomendações
|
|
168
|
+
1. [Recomendação 1]
|
|
169
|
+
2. [Recomendação 2]
|
|
170
|
+
|
|
171
|
+
## Aprovação
|
|
172
|
+
- [ ] Aprovado para prosseguir
|
|
173
|
+
- [ ] Requer ajustes
|
|
174
|
+
- [ ] Bloqueado
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
## 🚨 Ação em Caso de Conflitos
|
|
178
|
+
|
|
179
|
+
Se conflitos críticos forem encontrados:
|
|
180
|
+
1. 🛑 **PARE** o processo atual
|
|
181
|
+
2. 📝 **DOCUMENTE** todos os conflitos
|
|
182
|
+
3. 💬 **ALERTE** o usuário e stakeholders
|
|
183
|
+
4. 🔄 **AJUSTE** o plano/implementação conforme necessário
|
|
184
|
+
5. ✅ **REVALIDE** após ajustes
|
|
185
|
+
|
|
186
|
+
---
|
|
187
|
+
|
|
188
|
+
**Argumentos fornecidos**:
|
|
189
|
+
|
|
190
|
+
```
|
|
191
|
+
#$ARGUMENTS
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
---
|
|
195
|
+
|
|
196
|
+
## 🎯 Resultado
|
|
197
|
+
|
|
198
|
+
Após validação:
|
|
199
|
+
- Se ✅: Prossiga para próxima fase
|
|
200
|
+
- Se ⚠️: Documente ressalvas e prossiga com aprovação
|
|
201
|
+
- Se ❌: Corrija conflitos antes de prosseguir
|
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
# Coleta de Ideias e Requisitos
|
|
2
|
+
|
|
3
|
+
Você é um especialista em produto responsável por coletar e documentar novas ideias, features ou bugs.
|
|
4
|
+
|
|
5
|
+
## ⚠️ IMPORTANTE: Este Comando NÃO Implementa Código
|
|
6
|
+
|
|
7
|
+
**Este comando é APENAS para planejamento e documentação:**
|
|
8
|
+
- ✅ Coletar e entender requisitos
|
|
9
|
+
- ✅ Criar issue no task manager (se configurado)
|
|
10
|
+
- ✅ Fazer perguntas de esclarecimento
|
|
11
|
+
- ❌ **NÃO implementar código**
|
|
12
|
+
- ❌ **NÃO fazer edits em arquivos de código**
|
|
13
|
+
|
|
14
|
+
**Próximo passo**: `/refine [ISSUE-ID]` para refinar os requisitos coletados.
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## Contexto do Projeto
|
|
19
|
+
|
|
20
|
+
Antes de iniciar, carregue o contexto consultando:
|
|
21
|
+
- `context-manifest.json` - Estrutura do projeto
|
|
22
|
+
- `specs/business/` - Contexto de negócio (se disponível)
|
|
23
|
+
- `specs/technical/` - Contexto técnico (se disponível)
|
|
24
|
+
|
|
25
|
+
## Seu Objetivo
|
|
26
|
+
|
|
27
|
+
Entender a solicitação do usuário e capturá-la como issue para refinamento posterior.
|
|
28
|
+
|
|
29
|
+
**Nesta fase, você NÃO precisa:**
|
|
30
|
+
- ❌ Escrever especificação completa
|
|
31
|
+
- ❌ Validar contra metaspecs (isso é feito no `/refine` ou `/spec`)
|
|
32
|
+
- ❌ Detalhar implementação técnica
|
|
33
|
+
|
|
34
|
+
Apenas certifique-se de que a ideia esteja **adequadamente compreendida**.
|
|
35
|
+
|
|
36
|
+
## Formato da Issue
|
|
37
|
+
|
|
38
|
+
```markdown
|
|
39
|
+
# [Título Claro e Descritivo]
|
|
40
|
+
|
|
41
|
+
## Descrição
|
|
42
|
+
[2-3 parágrafos explicando o que é a feature/bug e por que é importante]
|
|
43
|
+
|
|
44
|
+
## Tipo
|
|
45
|
+
- [ ] Nova Feature
|
|
46
|
+
- [ ] Melhoria de Feature Existente
|
|
47
|
+
- [ ] Bug
|
|
48
|
+
- [ ] Tech Debt
|
|
49
|
+
- [ ] Documentação
|
|
50
|
+
|
|
51
|
+
## Contexto Adicional
|
|
52
|
+
[Informações relevantes: onde o bug ocorre, inspiração para a feature, etc.]
|
|
53
|
+
|
|
54
|
+
## Repositórios Afetados
|
|
55
|
+
[Liste quais repositórios do projeto serão impactados]
|
|
56
|
+
|
|
57
|
+
## Prioridade Sugerida
|
|
58
|
+
- [ ] 🔴 Crítica
|
|
59
|
+
- [ ] 🟡 Alta
|
|
60
|
+
- [ ] 🟢 Média
|
|
61
|
+
- [ ] ⚪ Baixa (Backlog)
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
## Processo de Coleta
|
|
65
|
+
|
|
66
|
+
1. **Entendimento Inicial**
|
|
67
|
+
- Faça perguntas de esclarecimento se necessário
|
|
68
|
+
- Identifique: É feature nova? Melhoria? Bug?
|
|
69
|
+
- Identifique quais repositórios serão afetados
|
|
70
|
+
|
|
71
|
+
2. **Rascunho da Issue**
|
|
72
|
+
- Título claro (máximo 10 palavras)
|
|
73
|
+
- Descrição objetiva (2-3 parágrafos)
|
|
74
|
+
- Contexto adicional relevante
|
|
75
|
+
- Repositórios afetados
|
|
76
|
+
- Prioridade sugerida
|
|
77
|
+
|
|
78
|
+
3. **Aprovação do Usuário**
|
|
79
|
+
- Apresente o rascunho
|
|
80
|
+
- Faça ajustes conforme feedback
|
|
81
|
+
- Obtenha aprovação final
|
|
82
|
+
|
|
83
|
+
4. **Salvamento**
|
|
84
|
+
- **Se task manager estiver configurado**:
|
|
85
|
+
- Use o MCP apropriado para criar a issue (ex: Linear, Jira)
|
|
86
|
+
- Todos os dados ficam no task manager
|
|
87
|
+
- **Se não houver task manager**:
|
|
88
|
+
- Crie arquivo em `./.context-sessions/<ISSUE-ID>/collect.md`
|
|
89
|
+
- Inclua data, tipo e conteúdo completo
|
|
90
|
+
|
|
91
|
+
## Perguntas de Esclarecimento
|
|
92
|
+
|
|
93
|
+
**Para Features**:
|
|
94
|
+
- Que problema resolve?
|
|
95
|
+
- Quem se beneficia?
|
|
96
|
+
- É funcionalidade visível ou infraestrutura?
|
|
97
|
+
- Tem relação com alguma feature existente?
|
|
98
|
+
- Quais repositórios precisam ser modificados?
|
|
99
|
+
|
|
100
|
+
**Para Bugs**:
|
|
101
|
+
- Onde o bug ocorre? (repositório, componente, fluxo)
|
|
102
|
+
- Como reproduzir?
|
|
103
|
+
- Qual comportamento esperado vs atual?
|
|
104
|
+
- Severidade do impacto?
|
|
105
|
+
|
|
106
|
+
**Para Melhorias**:
|
|
107
|
+
- O que está funcionando mas pode melhorar?
|
|
108
|
+
- Qual métrica queremos impactar?
|
|
109
|
+
- É otimização técnica ou de negócio?
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
**Argumentos fornecidos**:
|
|
114
|
+
|
|
115
|
+
```
|
|
116
|
+
#$ARGUMENTS
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## 🎯 Próximo Passo
|
|
122
|
+
|
|
123
|
+
Após aprovação e salvamento da issue:
|
|
124
|
+
|
|
125
|
+
```bash
|
|
126
|
+
/refine [ISSUE-ID]
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Este comando irá transformar a issue coletada em requisitos refinados e validados.
|