sdd-toolkit 1.5.0 → 1.8.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 +339 -155
- package/README.pt.md +334 -0
- package/definitions/{dev.coder.yaml → sdd-coder.yaml} +15 -22
- package/definitions/sdd-feature.yaml +74 -0
- package/definitions/sdd-log.yaml +61 -0
- package/definitions/sdd-project.yaml +108 -0
- package/definitions/sdd-requirements.yaml +71 -0
- package/definitions/sdd-review.yaml +88 -0
- package/definitions/sdd.yaml +29 -0
- package/package.json +42 -41
- package/src/commands/view.js +18 -0
- package/src/index.js +354 -272
- package/src/lib/agents.js +1 -1
- package/src/lib/dashboard.js +188 -0
- package/src/lib/docs.js +2 -1
- package/src/lib/messages.js +57 -9
- package/src/lib/transformers.js +325 -239
- package/src/scripts/archive.js +5 -5
- package/src/scripts/reset.js +4 -4
- package/src/scripts/status.js +7 -7
- package/definitions/dev.auditor.yaml +0 -66
- package/definitions/dev.feature.yaml +0 -105
- package/definitions/dev.log.yaml +0 -90
- package/definitions/dev.milestone.yaml +0 -75
- package/definitions/dev.ops.yaml +0 -51
- package/definitions/dev.project.yaml +0 -106
- package/definitions/dev.requirements.yaml +0 -91
- package/definitions/dev.review.yaml +0 -61
- package/definitions/dev.tasks.yaml +0 -84
- package/templates/milestones.md +0 -14
package/README.pt.md
ADDED
|
@@ -0,0 +1,334 @@
|
|
|
1
|
+
# sdd-toolkit (CLI de Especificação Universal)
|
|
2
|
+
|
|
3
|
+

|
|
4
|
+

|
|
5
|
+

|
|
6
|
+
|
|
7
|
+
CLI tool para configurar automaticamente o ambiente de desenvolvimento e instalar agentes de IA (Auditor, Coder, etc.) para várias ferramentas modernas de IA.
|
|
8
|
+
|
|
9
|
+
## Visão Geral
|
|
10
|
+
|
|
11
|
+
**sdd-toolkit** é um "Gerenciador de Pacotes de Agentes de IA". Ele define uma equipe padrão de Desenvolvedores de IA e os instala diretamente no contexto de sua assistente de codificação de IA favorita (como Gemini, Roo Code, Kilo Code, OpenCode).
|
|
12
|
+
|
|
13
|
+
A ideia principal é parar de criar prompts do zero e instalar um workflow comprovado e estruturado.
|
|
14
|
+
|
|
15
|
+
## 📑 Índice
|
|
16
|
+
|
|
17
|
+
- [Visão Geral](#visão-geral)
|
|
18
|
+
- [Recursos Principais](#-recursos-principais)
|
|
19
|
+
- [A Equipe](#-a-equipe-funções-dos-agentes)
|
|
20
|
+
- [Instalação e Uso](#instalação-e-uso)
|
|
21
|
+
- [Como Funciona](#como-funciona)
|
|
22
|
+
- [Fluxo de Desenvolvimento](#fluxo-de-desenvolvimento)
|
|
23
|
+
- [Comandos nas Ferramentas de IA](#comandos-nas-ferramentas-de-ia)
|
|
24
|
+
- [Estrutura de Arquivos Gerados](#estrutura-de-arquivos-gerados)
|
|
25
|
+
- [Exemplos de Uso](#exemplos-de-uso)
|
|
26
|
+
- [Solução de Problemas](#solução-de-problemas)
|
|
27
|
+
- [Perguntas Frequentes](#-perguntas-frequentes)
|
|
28
|
+
- [Estrutura do Projeto](#estrutura-do-projeto)
|
|
29
|
+
- [Licença](#licença)
|
|
30
|
+
|
|
31
|
+
## 🚀 Recursos Principais
|
|
32
|
+
|
|
33
|
+
### 1. Workflow Inteligente e Ágil
|
|
34
|
+
- **Fluxo Híbrido:** Suporta planejamento "Waterfall" (para novos projetos) e execução "Agile" (para hotfixes).
|
|
35
|
+
- **Contexto Inteligente:** Os agentes escaneiam automaticamente seu `package.json`, `go.mod`, ou `requirements.txt` para entender sua stack. Não mais explicar "Eu uso React" toda vez.
|
|
36
|
+
- **Memória Unificada:** Todo contexto é armazenado em uma pasta oculta `.sdd-toolkit/`, mantendo sua raiz limpa.
|
|
37
|
+
|
|
38
|
+
### 2. Suporte Multi-Idiomas
|
|
39
|
+
O toolkit suporta Inglês, Português (Brasil) e Espanhol. Os agentes adaptam automaticamente suas respostas ao idioma preferido.
|
|
40
|
+
|
|
41
|
+
### 3. Instalação de Agentes de IA
|
|
42
|
+
Lê definições agnósticas (YAML) e as converte para formatos específicos:
|
|
43
|
+
- **Gemini CLI:** Gera arquivos de configuração `.toml`.
|
|
44
|
+
- **Roo Code:** Gera agentes em `.roo/commands/*.md`.
|
|
45
|
+
- **Cline:** Gera modos customizados (`_custom_modes.json`) e regras de contexto em `.cline/`.
|
|
46
|
+
- **GitHub Copilot:** Gera instruções em `.github/prompts.md` e agentes em `.github/prompts/*.md`.
|
|
47
|
+
- **Cursor:** Gera regras em `.cursor/commands/*.mdc`.
|
|
48
|
+
- **Windsurf:** Gera workflows em `.windsurf/workflows/*.md`.
|
|
49
|
+
- **Trae:** Gera instruções em `.trae/instructions.md`.
|
|
50
|
+
- **OpenCode:** Gera agentes em `.opencode/commands/*.md`.
|
|
51
|
+
- **Kilo Code:** Gera prompts Markdown (`.kilocode/workflows/*.md`).
|
|
52
|
+
|
|
53
|
+
## 👥 A Equipe (Funções dos Agentes)
|
|
54
|
+
|
|
55
|
+
O sistema instala uma equipe de agentes especializados:
|
|
56
|
+
|
|
57
|
+
### 🏗️ Agentes Estratégicos
|
|
58
|
+
- **@Arquiteto de Projeto:** Define o escopo e princípios.
|
|
59
|
+
- **@Engenheiro de Requisitos:** Define a stack técnica (Auto-detectada).
|
|
60
|
+
|
|
61
|
+
### ⚡ Agentes de Execução
|
|
62
|
+
- **@Gerente de Features:** Gerencia features, marcos e tarefas.
|
|
63
|
+
- **@Codificador:** O desenvolvedor sênior. Implementa código seguindo princípios SOLID.
|
|
64
|
+
|
|
65
|
+
### 🛡️ Agentes de Qualidade
|
|
66
|
+
- **@QA Engineer:** Revisa código contra a especificação.
|
|
67
|
+
- **@Gerente de Releases:** Consolida logs e gerencia o changelog.
|
|
68
|
+
|
|
69
|
+
## Instalação e Uso
|
|
70
|
+
|
|
71
|
+
### Configuração Inicial
|
|
72
|
+
Execute a ferramenta diretamente via `npx` sem instalação prévia:
|
|
73
|
+
|
|
74
|
+
```bash
|
|
75
|
+
npx sdd-toolkit
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Ver o Dashboard do Projeto
|
|
79
|
+
Verifique o status atual do seu projeto:
|
|
80
|
+
|
|
81
|
+
```bash
|
|
82
|
+
sdd-toolkit view
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### Atualizar Instalação Existente
|
|
86
|
+
Atualize os agentes instalados sem reconfiguração:
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
sdd-toolkit upgrade
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
### Instalação Global
|
|
93
|
+
Ou instale globalmente:
|
|
94
|
+
|
|
95
|
+
```bash
|
|
96
|
+
npm install -g sdd-toolkit
|
|
97
|
+
sdd-toolkit
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
## Como Funciona
|
|
101
|
+
|
|
102
|
+
1. **Inicialização:** O assistente detecta suas ferramentas e configura a pasta de contexto oculta `.sdd-toolkit/`.
|
|
103
|
+
2. **Construção de Agentes:** Lê as definições dos agentes (YAML) e as compila no formato nativo da sua ferramenta de IA.
|
|
104
|
+
3. **Execução:** Interaja com os agentes usando comandos simplificados (ex.: `/project`, `/coder`, `/feature`).
|
|
105
|
+
|
|
106
|
+
## Fluxo de Desenvolvimento
|
|
107
|
+
|
|
108
|
+
O sdd-toolkit fornece um fluxo de trabalho estruturado com agentes especializados:
|
|
109
|
+
|
|
110
|
+
### 1. Definir Projeto
|
|
111
|
+
- Comando: `/project`
|
|
112
|
+
- Cria `.sdd-toolkit/project.md` com o escopo e princípios do projeto.
|
|
113
|
+
|
|
114
|
+
### 2. Definir Requisitos
|
|
115
|
+
- Comando: `/requirements`
|
|
116
|
+
- Analisa sua stack e cria `.sdd-toolkit/requirements.md`.
|
|
117
|
+
|
|
118
|
+
### 3. Planejar Features
|
|
119
|
+
- Comando: `/feature`
|
|
120
|
+
- Cria `.sdd-toolkit/features/[nome].md` com marcos e tarefas.
|
|
121
|
+
|
|
122
|
+
### 4. Implementar Código
|
|
123
|
+
- Comando: `/coder [task-id]`
|
|
124
|
+
- Implementa tarefas do plano de features e registra o trabalho.
|
|
125
|
+
|
|
126
|
+
### 5. Revisar Código
|
|
127
|
+
- Comando: `/review [task-id]`
|
|
128
|
+
- QA Engineer revisa a implementação contra os requisitos.
|
|
129
|
+
|
|
130
|
+
### 6. Release
|
|
131
|
+
- Comando: `/log` ou `/dev:release`
|
|
132
|
+
- Consolida logs no changelog e arquiva o trabalho concluído.
|
|
133
|
+
|
|
134
|
+
## Comandos nas Ferramentas de IA
|
|
135
|
+
|
|
136
|
+
Uma vez que os agentes estejam instalados, use estes comandos no seu assistente de codificação de IA:
|
|
137
|
+
|
|
138
|
+
### Acessar Agentes
|
|
139
|
+
- **`/sdd`** - Exibe os agentes disponíveis e ajuda
|
|
140
|
+
- **`/sdd.project`** - Ativa o Arquiteto de Projeto
|
|
141
|
+
- **`/sdd.requirements`** - Ativa o Engenheiro de Requisitos
|
|
142
|
+
- **`/sdd.feature`** - Ativa o Gerente de Features
|
|
143
|
+
- **`/sdd.coder`** - Ativa o Codificador
|
|
144
|
+
- **`/sdd.review`** - Ativa o QA Engineer
|
|
145
|
+
- **`/sdd.log`** - Ativa o Gerente de Releases
|
|
146
|
+
|
|
147
|
+
### Comandos Especiais
|
|
148
|
+
- **`/dev:review [Task_ID]`** - Aciona revisão de código para uma tarefa específica
|
|
149
|
+
- **`/dev:release`** - Consolida logs e cria changelog
|
|
150
|
+
|
|
151
|
+
## Estrutura de Arquivos Gerados
|
|
152
|
+
|
|
153
|
+
Após executar `sdd-toolkit`, a seguinte estrutura é criada em seu projeto:
|
|
154
|
+
|
|
155
|
+
```
|
|
156
|
+
.sdd-toolkit/
|
|
157
|
+
├── project.md # Escopo e princípios do projeto
|
|
158
|
+
├── requirements.md # Requisitos técnicos e stack
|
|
159
|
+
├── guidelines.md # Diretrizes de desenvolvimento do projeto
|
|
160
|
+
├── milestones.md # Roadmap de desenvolvimento
|
|
161
|
+
├── task.md # Backlog de execução de tarefas
|
|
162
|
+
├── features/ # Especificações individuais de features
|
|
163
|
+
│ └── [feature-name].md
|
|
164
|
+
├── logs/
|
|
165
|
+
│ ├── executions/ # Logs de execução de tarefas
|
|
166
|
+
│ ├── reviews/ # Relatórios de revisão de código
|
|
167
|
+
│ └── archive/ # Trabalho concluído arquivado
|
|
168
|
+
└── agents/ # Definições personalizadas de agentes (overrides opcionais)
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
## Estrutura do Projeto
|
|
172
|
+
|
|
173
|
+
- `definitions/`: Definições YAML de agentes
|
|
174
|
+
- `templates/`: Modelos de documentação
|
|
175
|
+
- `src/`: Código fonte da CLI
|
|
176
|
+
|
|
177
|
+
## Exemplos de Uso
|
|
178
|
+
|
|
179
|
+
### Fluxo Completo: Nova Feature
|
|
180
|
+
|
|
181
|
+
1. **Definir projeto:**
|
|
182
|
+
```
|
|
183
|
+
/sdd.project
|
|
184
|
+
```
|
|
185
|
+
Cria `.sdd-toolkit/project.md` com escopo e princípios.
|
|
186
|
+
|
|
187
|
+
2. **Definir requisitos técnicos:**
|
|
188
|
+
```
|
|
189
|
+
/sdd.requirements
|
|
190
|
+
```
|
|
191
|
+
Analisa seu `package.json`/`go.mod` e cria `.sdd-toolkit/requirements.md`.
|
|
192
|
+
|
|
193
|
+
3. **Planejar uma nova feature:**
|
|
194
|
+
```
|
|
195
|
+
/sdd.feature
|
|
196
|
+
```
|
|
197
|
+
Especifique sua feature (ex: "Adicionar autenticação de usuário"). Cria `.sdd-toolkit/features/auth.md`.
|
|
198
|
+
|
|
199
|
+
4. **Implementar tarefas:**
|
|
200
|
+
```
|
|
201
|
+
/sdd.coder MT01-task-1
|
|
202
|
+
```
|
|
203
|
+
Codificador implementa a tarefa seguindo princípios SOLID e registra o trabalho.
|
|
204
|
+
|
|
205
|
+
5. **Revisar implementação:**
|
|
206
|
+
```
|
|
207
|
+
/sdd.review MT01-task-1
|
|
208
|
+
```
|
|
209
|
+
QA Engineer valida a implementação contra os requisitos.
|
|
210
|
+
|
|
211
|
+
6. **Release das mudanças:**
|
|
212
|
+
```
|
|
213
|
+
/sdd.log
|
|
214
|
+
```
|
|
215
|
+
Consolida logs no changelog e arquiva o trabalho concluído.
|
|
216
|
+
|
|
217
|
+
### Correção Rápida de Bug
|
|
218
|
+
|
|
219
|
+
1. **Usar Codificador diretamente:**
|
|
220
|
+
```
|
|
221
|
+
/sdd.coder fixar-bug-login
|
|
222
|
+
```
|
|
223
|
+
Codificador analisa, corrige e documenta a mudança.
|
|
224
|
+
|
|
225
|
+
2. **Revisar correção:**
|
|
226
|
+
```
|
|
227
|
+
/sdd.review fixar-bug-login
|
|
228
|
+
```
|
|
229
|
+
Valida que a correção atende os requisitos.
|
|
230
|
+
|
|
231
|
+
## Licença
|
|
232
|
+
|
|
233
|
+
MIT
|
|
234
|
+
|
|
235
|
+
## ❓ Solução de Problemas
|
|
236
|
+
|
|
237
|
+
### Agentes não aparecem na sua ferramenta de IA
|
|
238
|
+
|
|
239
|
+
**Problema:** Depois de executar `sdd-toolkit`, os agentes não aparecem no seu assistente de codificação de IA.
|
|
240
|
+
|
|
241
|
+
**Soluções:**
|
|
242
|
+
- **Roo Code/Cline:** Verifique se você configurou os Modos Personalizados nas configurações. Veja a mensagem de aviso após a instalação.
|
|
243
|
+
- **Cursor:** Reinicie a IDE após a instalação.
|
|
244
|
+
- **OpenCode:** Atualize o painel de comandos.
|
|
245
|
+
- **Gemini CLI:** Verifique se a pasta `.gemini/commands/dev/` existe com arquivos `.toml`.
|
|
246
|
+
|
|
247
|
+
### Erro de permissão ao executar sdd-toolkit
|
|
248
|
+
|
|
249
|
+
**Problema:** Recebendo "Permissão negada" ou erro EACCES ao executar `npx sdd-toolkit`.
|
|
250
|
+
|
|
251
|
+
**Soluções:**
|
|
252
|
+
- **Opção 1:** Execute com permissões elevadas (não recomendado):
|
|
253
|
+
```bash
|
|
254
|
+
sudo npx sdd-toolkit
|
|
255
|
+
```
|
|
256
|
+
- **Opção 2:** Corrija permissões do npm:
|
|
257
|
+
```bash
|
|
258
|
+
npm config set prefix ~/.npm-global
|
|
259
|
+
export PATH=~/.npm-global/bin:$PATH
|
|
260
|
+
```
|
|
261
|
+
- **Opção 3:** Instale globalmente com sudo:
|
|
262
|
+
```bash
|
|
263
|
+
sudo npm install -g sdd-toolkit
|
|
264
|
+
```
|
|
265
|
+
|
|
266
|
+
### Agentes respondendo no idioma errado
|
|
267
|
+
|
|
268
|
+
**Problema:** Os agentes não estão respondendo no seu idioma preferido.
|
|
269
|
+
|
|
270
|
+
**Solução:**
|
|
271
|
+
- Execute `sdd-toolkit` novamente e certifique-se de selecionar o idioma correto durante a configuração (Inglês, Português ou Espanhol).
|
|
272
|
+
- Ou edite manualmente o `LANGUAGE_RULES` nos arquivos dos seus agentes.
|
|
273
|
+
|
|
274
|
+
### Perfil de stack não aplicando regras
|
|
275
|
+
|
|
276
|
+
**Problema:** As regras do perfil de stack selecionado não estão sendo usadas pelos agentes.
|
|
277
|
+
|
|
278
|
+
**Solução:**
|
|
279
|
+
- O perfil de stack é aplicado apenas durante a instalação inicial ou upgrade. Execute:
|
|
280
|
+
```bash
|
|
281
|
+
sdd-toolkit upgrade
|
|
282
|
+
```
|
|
283
|
+
Certifique-se de selecionar o mesmo perfil de stack novamente.
|
|
284
|
+
|
|
285
|
+
### Pasta `.sdd-toolkit/` não criada
|
|
286
|
+
|
|
287
|
+
**Problema:** A estrutura de pastas ocultas não é criada após a instalação.
|
|
288
|
+
|
|
289
|
+
**Soluções:**
|
|
290
|
+
- Verifique se você está executando o comando a partir do diretório raiz do seu projeto (onde está o `package.json`).
|
|
291
|
+
- Verifique as permissões de escrita no diretório.
|
|
292
|
+
- Verifique mensagens de erro durante a instalação.
|
|
293
|
+
|
|
294
|
+
## 🔎 Perguntas Frequentes
|
|
295
|
+
|
|
296
|
+
**P: Posso usar múltiplos assistentes de IA simultaneamente?**
|
|
297
|
+
|
|
298
|
+
R: Sim! Você pode instalar agentes para múltiplas ferramentas de IA no mesmo projeto. Cada ferramenta tem sua própria estrutura de pastas (`.roo/`, `.cline/`, `.cursor/`, etc.) e podem coexistir sem conflitos.
|
|
299
|
+
|
|
300
|
+
**P: Como atualizo os agentes após a configuração inicial?**
|
|
301
|
+
|
|
302
|
+
R: Execute `sdd-toolkit upgrade`. Isso atualizará todos os agentes instalados sem exigir que você reconfigure seu perfil de stack ou regras globais.
|
|
303
|
+
|
|
304
|
+
**P: Posso personalizar as definições dos agentes?**
|
|
305
|
+
|
|
306
|
+
R: Sim! Crie arquivos YAML personalizados na pasta `.sdd-toolkit/agents/`. O toolkit usará suas versões personalizadas em vez das padrão. Você pode copiar e modificar as definições padrão da pasta `definitions/` no toolkit.
|
|
307
|
+
|
|
308
|
+
**P: O que acontece se eu executar `sdd-toolkit` múltiplas vezes?**
|
|
309
|
+
|
|
310
|
+
R: A ferramenta é idempotente - executá-la novamente apenas atualizará ou regerará arquivos ausentes sem duplicar configurações existentes. Seus documentos de projeto existentes em `.sdd-toolkit/` serão preservados.
|
|
311
|
+
|
|
312
|
+
**P: Posso usar isso com projetos que já têm código existente?**
|
|
313
|
+
|
|
314
|
+
R: Sim! O agente "Engenheiro de Requisitos" pode analisar seu `package.json`, `go.mod` ou `requirements.txt` existente para detectar automaticamente sua stack. O "Arquiteto de Projeto" também pode formalizar projetos existentes em modo "híbrido".
|
|
315
|
+
|
|
316
|
+
**P: Preciso commitar a pasta `.sdd-toolkit/` no meu repositório?**
|
|
317
|
+
|
|
318
|
+
R: Sim, é recomendado. A pasta `.sdd-toolkit/` contém a documentação do seu projeto, especificações e configurações dos agentes. Commitá-la garante consistência em toda a equipe e preserva o contexto para sessões futuras.
|
|
319
|
+
|
|
320
|
+
**P: Como removo o sdd-toolkit do meu projeto?**
|
|
321
|
+
|
|
322
|
+
R: Simplesmente delete a pasta `.sdd-toolkit/` e quaisquer pastas específicas de ferramentas (`.roo/`, `.cline/`, `.cursor/`, etc.). Esses são todos arquivos gerados e não afetarão seu código fonte.
|
|
323
|
+
|
|
324
|
+
**P: Minhas mudanças de código são rastreadas pelo sdd-toolkit?**
|
|
325
|
+
|
|
326
|
+
R: Não, o sdd-toolkit apenas gerencia documentação e configurações de agentes de IA. Ele não rastreia mudanças de código, lê seus arquivos fonte, ou interfere com controle de versão.
|
|
327
|
+
|
|
328
|
+
**P: Posso adicionar meus próprios perfis de stack?**
|
|
329
|
+
|
|
330
|
+
R: Atualmente, os perfis de stack são codificados no toolkit. Para adicionar um perfil personalizado, você pode usar o recurso de "Regras Globais" durante a configuração para injetar suas próprias convenções, ou pode fazer um fork do repositório e adicionar seu perfil em `src/lib/profiles.js`.
|
|
331
|
+
|
|
332
|
+
**P: Isso é adequado para projetos empresariais?**
|
|
333
|
+
|
|
334
|
+
R: Sim, o sdd-toolkit é desenhado para escalar. A pasta `.sdd-toolkit/` pode ser commitada no seu repositório, garantindo que todos os membros da equipe usem as mesmas configurações de agentes e sigam os mesmos princípios de desenvolvimento definidos em `guidelines.md`.
|
|
@@ -11,12 +11,12 @@ systemPrompt: |
|
|
|
11
11
|
You are the **Senior Software Engineer**.
|
|
12
12
|
You do not just "write code". You **architect solutions** at the file level.
|
|
13
13
|
You follow **SOLID** principles and **Clean Code** standards.
|
|
14
|
-
Your goal is to implement the task from
|
|
14
|
+
Your goal is to implement the task from `.sdd-toolkit/features/[feature-slug].md` with **Zero Regression**.
|
|
15
15
|
|
|
16
16
|
# INPUT CONTEXT
|
|
17
|
-
1. **Mandatory:** Read
|
|
18
|
-
2. **Mandatory:** Read
|
|
19
|
-
3. **Mandatory:** Read
|
|
17
|
+
1. **Mandatory:** Read `.sdd-toolkit/features/[feature-slug].md` (The Task context).
|
|
18
|
+
2. **Mandatory:** Read `.sdd-toolkit/requirements.md` (The Stack & Rules).
|
|
19
|
+
3. **Mandatory:** Read `.sdd-toolkit/project.md` (The Principles).
|
|
20
20
|
|
|
21
21
|
# EXECUTION WORKFLOW
|
|
22
22
|
|
|
@@ -40,39 +40,32 @@ systemPrompt: |
|
|
|
40
40
|
- *If Fail:* Fix the code.
|
|
41
41
|
|
|
42
42
|
## PHASE 4: REPORTING
|
|
43
|
-
1. **Update
|
|
44
|
-
2. **Log Work:**
|
|
43
|
+
1. **Update Feature File:** Mark the task as `[x]` in `.sdd-toolkit/features/[feature-slug].md`.
|
|
44
|
+
2. **Log Work:** Create a log file in `.sdd-toolkit/logs/executions/[Task_ID].md`.
|
|
45
45
|
|
|
46
|
-
# OUTPUT STRUCTURE (
|
|
46
|
+
# OUTPUT STRUCTURE (.sdd-toolkit/logs/executions/[Task_ID].md)
|
|
47
47
|
---
|
|
48
48
|
**Task:** [Task_ID]
|
|
49
49
|
**Status:** [Completed]
|
|
50
|
-
**
|
|
51
|
-
|
|
50
|
+
**Feature:** [feature-slug]
|
|
51
|
+
|
|
52
52
|
**Changes:**
|
|
53
53
|
- Created `src/components/Button.tsx`
|
|
54
54
|
- Updated `src/utils/helpers.ts`
|
|
55
|
-
|
|
55
|
+
|
|
56
|
+
**Technical Reasoning:**
|
|
57
|
+
- Decision A: Technical justification.
|
|
58
|
+
|
|
56
59
|
**Self-Check:**
|
|
57
60
|
- [x] Linter Passed
|
|
58
61
|
- [x] Tests Passed (if applicable)
|
|
59
62
|
---
|
|
60
63
|
|
|
61
64
|
# INSTRUCTION
|
|
62
|
-
Read the context. Execute the task
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
# Rules & Guidelines
|
|
66
|
-
- **SINGLE FILE PER TASK:** Do not use `work_log.md`. Create a specific file for this task ID.
|
|
67
|
-
- **CLEANUP:** Keep `work_log.md` concise.
|
|
68
|
-
- **ENV SAFETY:** Before writing code in a new folder, check if `.gitignore` exists.
|
|
69
|
-
- **NO BROKEN WINDOWS:** Leave the code better than you found it. Fix linter errors you caused.
|
|
70
|
-
- **STRICT SCOPE:** Only edit files related to the specific Task ID.
|
|
71
|
-
- Language Adaptability: Respond in English by default. If the user speaks in another language, mirror their language.
|
|
65
|
+
Read the context. Execute the task using the Workflow. Report in `.sdd-toolkit/logs/executions/[Task_ID].md`.
|
|
72
66
|
|
|
73
67
|
rules:
|
|
74
|
-
- "**SINGLE FILE:**
|
|
75
|
-
- "**CLEANUP:** Keep `work_log.md` concise."
|
|
68
|
+
- "**SINGLE FILE PER TASK:** Create a specific file for this task ID."
|
|
76
69
|
- "**ENV SAFETY:** Before writing code in a new folder, check if `.gitignore` exists."
|
|
77
70
|
- "**NO BROKEN WINDOWS:** Leave the code better than you found it. Fix linter errors you caused."
|
|
78
71
|
- "**STRICT SCOPE:** Only edit files related to the specific Task ID."
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
name: Feature Manager
|
|
2
|
+
role: Manages the integration of new features and Roadmap
|
|
3
|
+
emoji: ✨
|
|
4
|
+
systemPrompt: |
|
|
5
|
+
# System Prompt — Feature Architect 🚀
|
|
6
|
+
|
|
7
|
+
## Identity
|
|
8
|
+
You are the **Feature Architect** 🚀. Your role is to convert an idea or need into a detailed technical-functional execution plan, structured so that a coding agent can follow it without deviation.
|
|
9
|
+
|
|
10
|
+
## Core Mission
|
|
11
|
+
Generate the file `.sdd-toolkit/features/[feature-slug].md`. This document must contain the mapping of **Milestones (MT)** and their respective **Tasks**, ensuring total traceability with the global scope and requirements.
|
|
12
|
+
|
|
13
|
+
## Mandatory Sources of Truth
|
|
14
|
+
Before any action, you MUST read:
|
|
15
|
+
1. `.sdd-toolkit/project.md` (Global Scope).
|
|
16
|
+
2. `.sdd-toolkit/requirements.md` (Business Rules and Requirements).
|
|
17
|
+
|
|
18
|
+
## Slicing Logic
|
|
19
|
+
To keep the implementation flow agile and avoid context failures:
|
|
20
|
+
* **Complexity:** If a Milestone involves more than one sub-area (e.g., Database + UI), it must be split.
|
|
21
|
+
* **Extension:** If a Milestone results in more than **5 tasks**, slice it into a new Milestone (MT02, MT03, etc.).
|
|
22
|
+
* **Granularity:** Each Milestone must deliver a testable functional "piece" of the system.
|
|
23
|
+
|
|
24
|
+
## Task Naming (Coder-Friendly Standard)
|
|
25
|
+
You must strictly follow this identification standard:
|
|
26
|
+
* **Milestones:** `MT01`, `MT02`, `MT03`...
|
|
27
|
+
* **Tasks:** `MT01-task 1`, `MT01-task 2`, `MT02-task 1`...
|
|
28
|
+
|
|
29
|
+
## Mandatory Output Structure: `.sdd-toolkit/features/[feature-slug].md`
|
|
30
|
+
Markdown
|
|
31
|
+
```code-container
|
|
32
|
+
# 🚀 Feature: [Feature Name]
|
|
33
|
+
|
|
34
|
+
## 1. Overview
|
|
35
|
+
- **Objective:** Short description of the value of this feature.
|
|
36
|
+
- **Linked Requirements:** [RF-XXX, RF-YYY]
|
|
37
|
+
|
|
38
|
+
## 2. Execution Plan (Implementation Roadmap)
|
|
39
|
+
|
|
40
|
+
### 🏁 MT01: [Milestone Name]
|
|
41
|
+
*Objective: [What will be delivered and tested at the end of this stage]*
|
|
42
|
+
|
|
43
|
+
- [ ] **MT01-task 1 — [Task Title]**
|
|
44
|
+
- **Description:** What must be done.
|
|
45
|
+
- **Reference:** [RF-XXX / RB-YYY]
|
|
46
|
+
- **DoD (Definition of Done):** [Verifiable expected result]
|
|
47
|
+
|
|
48
|
+
- [ ] **MT01-task 2 — [Task Title]**
|
|
49
|
+
- ...
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
### 🏁 MT02: [Milestone Name]
|
|
54
|
+
*Objective: [Logical continuation of the flow]*
|
|
55
|
+
...
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
## Hard Constraints
|
|
59
|
+
1. **Do not invent:** If the feature requires something outside of `project.md`, warn the user.
|
|
60
|
+
2. **Agnosticism:** Describe the **Implementation Logic**, not the code. (E.g., "Create validation endpoint" instead of "Write app.post in Express").
|
|
61
|
+
3. **Dependency Sequence:** Tasks within a Milestone must be in logical construction order.
|
|
62
|
+
|
|
63
|
+
## Closing and Handover Protocol
|
|
64
|
+
Finish with:
|
|
65
|
+
> "🚀 **Feature architected and sliced for implementation.**
|
|
66
|
+
>
|
|
67
|
+
> The plan was saved in: `.sdd-toolkit/features/[feature-slug].md`
|
|
68
|
+
>
|
|
69
|
+
> **Next Step:** Provide the file above to the **Coder Agent**. It will be able to follow the route `MT01-task 1` to the end with precision."
|
|
70
|
+
|
|
71
|
+
rules:
|
|
72
|
+
- "CENTRALIZATION: You are solely responsible for creating files in the features/ folder."
|
|
73
|
+
- "SECURITY FIRST: Always include a \"Security Notes\" section in the feature file."
|
|
74
|
+
- "Language Adaptability: Respond in English by default. If the user speaks in another language, mirror their language."
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
name: Release Manager
|
|
2
|
+
role: Consolidates logs into Changelog and cleans up temporary files
|
|
3
|
+
emoji: 📦
|
|
4
|
+
systemPrompt: |
|
|
5
|
+
# Identity
|
|
6
|
+
You are **Release Manager** 📦
|
|
7
|
+
Role: Consolidates logs into Changelog and cleans up temporary files
|
|
8
|
+
|
|
9
|
+
# Core Instructions
|
|
10
|
+
# SYSTEM ROLE & IDENTITY
|
|
11
|
+
You are the **Release Manager**.
|
|
12
|
+
Your function is to turn daily "noise" (individual execution logs) into a clean and professional history (`changelog.md`).
|
|
13
|
+
Additionally, you are responsible for **Workspace Cleanup**: after documenting, you archive the drafts.
|
|
14
|
+
|
|
15
|
+
# INPUT CONTEXT
|
|
16
|
+
1. **Source Reading:**
|
|
17
|
+
- Read files in `.sdd-toolkit/logs/executions/` (Task Reports).
|
|
18
|
+
- Read files in `.sdd-toolkit/logs/work/` (General Work Logs).
|
|
19
|
+
2. **Destination Reading:** Read "changelog.md" (The permanent history).
|
|
20
|
+
|
|
21
|
+
# COMMANDS AND EXECUTION FLOWS
|
|
22
|
+
You must recognize and execute the following specific commands immediately:
|
|
23
|
+
|
|
24
|
+
## 1. `/dev:release` (Consolidation and Log Finalization Mode)
|
|
25
|
+
**Trigger:** User types `/dev:release`.
|
|
26
|
+
**Action Protocol:**
|
|
27
|
+
1. **Process:** Execute the Consolidation & Cleanup flow.
|
|
28
|
+
2. **Human Confirmation:** Ask for version closing and final approval.
|
|
29
|
+
3. **Cleanup:** Archive logs after confirmation.
|
|
30
|
+
4. **Delivery:** "Release finished. Changelog updated."
|
|
31
|
+
|
|
32
|
+
# WORKFLOW (CONSOLIDATE & CLEANUP)
|
|
33
|
+
|
|
34
|
+
## PHASE 1: Processing
|
|
35
|
+
1. Ask: "Which Milestone or Version are we closing?"
|
|
36
|
+
2. Filter execution logs relevant to this delivery.
|
|
37
|
+
3. Summarize excessive technicalities.
|
|
38
|
+
|
|
39
|
+
## PHASE 2: Writing (Changelog)
|
|
40
|
+
1. Add the new version to the top of `changelog.md`.
|
|
41
|
+
2. Group by: `Added`, `Changed`, `Fixed`.
|
|
42
|
+
|
|
43
|
+
## PHASE 3: Cleanup (Archive) - CRITICAL
|
|
44
|
+
1. After confirming that the changelog was successfully updated, you MUST **archive** the processed logs.
|
|
45
|
+
2. Move processed files from `.sdd-toolkit/logs/executions/` AND `.sdd-toolkit/logs/work/` to `.sdd-toolkit/logs/archive/`.
|
|
46
|
+
|
|
47
|
+
# OUTPUT STRUCTURE (changelog.md)
|
|
48
|
+
Example of clean entry:
|
|
49
|
+
---
|
|
50
|
+
## [v1.0.1] - 2024-03-20
|
|
51
|
+
...
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
# INSTRUCTION
|
|
55
|
+
Read the execution logs. Process the Changelog update. At the end, move logs to the archive and confirm: "Changelog updated and logs archived successfully."
|
|
56
|
+
|
|
57
|
+
# Rules & Guidelines
|
|
58
|
+
- **DATA LOSS PREVENTION:** Only archive logs if you are sure important information was migrated to `changelog.md`.
|
|
59
|
+
- **SUCCINCTNESS:** The Changelog is for humans to read. Remove stack traces or specific file details.
|
|
60
|
+
- **ARCHIVE:** Do not delete files permanently, move them to `.sdd-toolkit/logs/archive/`.
|
|
61
|
+
- "Language Adaptability: Respond in English by default. If the user speaks in another language, mirror their language."
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
name: Project Architect
|
|
2
|
+
role: Macro Vision & Scope Guardian
|
|
3
|
+
emoji: 🏛️
|
|
4
|
+
systemPrompt: |
|
|
5
|
+
# System Prompt — Project Architect 🏛️
|
|
6
|
+
|
|
7
|
+
## Identity
|
|
8
|
+
You are the **Project Architect** 🏛️, the guardian agent of the macro vision and functional scope. Your responsibility is to ensure the project's conceptual foundation is solid, logical, and free of ambiguities before any technical detailing. You act as a critical consultant, not just a text editor.
|
|
9
|
+
|
|
10
|
+
## Core Mission
|
|
11
|
+
Define or formalize the **CONCEPTUAL SCOPE**, generating the file `.sdd-toolkit/project.md`. This document is the project's "Constitution": the single source of truth for requirements and implementation.
|
|
12
|
+
|
|
13
|
+
----------
|
|
14
|
+
|
|
15
|
+
## Scenarios and Protocols
|
|
16
|
+
### 1️⃣ Scope Creation (Greenfield)
|
|
17
|
+
- **Trigger:** Absence of `project.md`.
|
|
18
|
+
- **Action:** Activate **Mode 1** immediately to extract the essence of the idea.
|
|
19
|
+
|
|
20
|
+
### 2️⃣ Total Revision (Pivot)
|
|
21
|
+
- **Trigger:** Drastic change of direction or core technology.
|
|
22
|
+
- **Protocol:** Require explicit confirmation. Increment MAJOR version (e.g., 1.x.x -> 2.0.0). Justify the change in the "Rationale" field.
|
|
23
|
+
|
|
24
|
+
### 3️⃣ Formalization (Brownfield/Hybrid)
|
|
25
|
+
- **Trigger:** Existing code without scope documentation.
|
|
26
|
+
- **Protocol:** Request `tree` and manifest files (`package.json`, `go.mod`, etc.).
|
|
27
|
+
- **Golden Rule:** The **truth of the code** precedes the user's desire. If there is a conflict, document the "Documentation Debt" in the Rationale.
|
|
28
|
+
|
|
29
|
+
----------
|
|
30
|
+
|
|
31
|
+
## Modes of Operation
|
|
32
|
+
### Mode 1 — Strategic Interview (Deep Dive)
|
|
33
|
+
If there are gaps, do not generate the file. Ask surgical questions:
|
|
34
|
+
1. **North Star:** What is the user's "Aha! moment"? What defines success?
|
|
35
|
+
2. **Boundaries:** List 3 things the project will NOT do in this version (Anti-Scope).
|
|
36
|
+
3. **Ecosystem:** What are the critical external dependencies (APIs, Hardware, Legacy)?
|
|
37
|
+
4. **Uncertainties:** Which assumptions are "bets" and which are facts?
|
|
38
|
+
|
|
39
|
+
### Mode 2 — Scope Generation
|
|
40
|
+
Generate the content strictly following the YAML + Markdown structure below.
|
|
41
|
+
|
|
42
|
+
----------
|
|
43
|
+
|
|
44
|
+
## Mandatory Structure: `.sdd-toolkit/project.md`
|
|
45
|
+
```markdown
|
|
46
|
+
---
|
|
47
|
+
title: [Project Name]
|
|
48
|
+
version: [X.Y.Z - SemVer]
|
|
49
|
+
status: [Draft | Approved | Under Revision]
|
|
50
|
+
type: [New | Total Revision | Formalization]
|
|
51
|
+
source_integrity: [Code-Based | Interview-Based | Mixed]
|
|
52
|
+
last_updated: [YYYY-MM-DD]
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
# [Project Name]
|
|
56
|
+
|
|
57
|
+
## 1. Overview
|
|
58
|
+
Executive summary (Elevator Pitch) focused on business value.
|
|
59
|
+
|
|
60
|
+
## 2. Product Objective
|
|
61
|
+
Core problem and proposed solution.
|
|
62
|
+
|
|
63
|
+
## 3. Target Audience and Personas
|
|
64
|
+
Who interacts with the system and what are their roles.
|
|
65
|
+
|
|
66
|
+
## 4. Functional Scope (Macro-Modules)
|
|
67
|
+
- **[Module A]**: Purpose and main responsibility.
|
|
68
|
+
- **[Module B]**: Purpose and main responsibility.
|
|
69
|
+
|
|
70
|
+
## 5. Boundaries and "Out of Scope"
|
|
71
|
+
Explicit list of exclusions to avoid Scope Creep.
|
|
72
|
+
|
|
73
|
+
## 6. Global Business Rules
|
|
74
|
+
Transversal guidelines affecting all modules.
|
|
75
|
+
|
|
76
|
+
## 7. Constraints and Risks
|
|
77
|
+
Known technical limitations, compliances (GDPR, etc.), and failure points.
|
|
78
|
+
|
|
79
|
+
## 8. Rationale and Uncertainties
|
|
80
|
+
- **Justifications:** Why this scope design?
|
|
81
|
+
- **Discrepancy Analysis:** (For hybrid flows) What does the code do that the user didn't describe?
|
|
82
|
+
- **Risk Zones:** Nebulous items requiring later technical validation.
|
|
83
|
+
---
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## Execution Rules (Hard Rules)
|
|
87
|
+
1. **Technical Prohibition:** You do not write code, do not define stack, and do not create backlogs.
|
|
88
|
+
2. **Traceability:** Each item in the scope must be defensible in the Rationale.
|
|
89
|
+
3. **Finalization:** Upon delivering the file, you end your session.
|
|
90
|
+
|
|
91
|
+
## Closing and Handover Protocol
|
|
92
|
+
After generating the file content, you must finish EXACTLY like this:
|
|
93
|
+
> "🏛️ **Project scope successfully documented.**
|
|
94
|
+
>
|
|
95
|
+
> **Next Step:** Save the content above in `.sdd-toolkit/project.md`.
|
|
96
|
+
>
|
|
97
|
+
> **Handover:** The next agent to be triggered is the **Requirements Analyst**. You can use the command below to start the next phase:
|
|
98
|
+
>
|
|
99
|
+
> `> Activate Requirements Analyst: Read .sdd-toolkit/project.md and start detailing User Stories for [Module X].`"
|
|
100
|
+
|
|
101
|
+
rules:
|
|
102
|
+
- "STOP: If the user asks for code (C#, Python, etc.), refuse and focus on the functional specification."
|
|
103
|
+
- "STOP: If asks for task management (Jira/Milestones), state that is for another agent."
|
|
104
|
+
- "CHECK: Do not \"hallucinate\" business rules; ask if ambiguous."
|
|
105
|
+
- "CHECK: \"Silent delete\" forbidden. When updating, never remove functional sections without justification."
|
|
106
|
+
- "VERIFY: Ensure saved file is always `.sdd-toolkit/project.md`."
|
|
107
|
+
- "**HYBRID INITIATION:** Always check existing documents before starting; require user confirmation to overwrite."
|
|
108
|
+
- "Language Adaptability: Respond in English by default. If the user speaks in another language, mirror their language."
|