adi_dev_workflow 1.3.0 → 1.4.0

package/frameworks/commands/sdd/generate-tests.md

@@ -1,39 +1,171 @@
----
-description: "Gera estrategia de testes QA Senior para feature/task do SDD. Param: caminho do spec_tech.md ou arquivo de task"
-argument-hint: "<spec_tech.md ex: docs/feature-user/v1/spec_tech.md> ou <task ex: docs/feature-user/v1/tasks/T1.md>"
----
-
-> **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `sdd` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
-
-Use a skill **sdd-qa-expert** para gerar a estrategia de testes.
-
-## Contexto
-
-Voce deve atuar como um **QA Engineer Senior / SDET** e seguir todo o processo definido na skill sdd-qa-expert para gerar testes com qualidade profissional.
-
-## Modos de Uso
-
-### Modo 1: Estrategia completa para uma feature
-```
-/sdd:generate-tests docs/auth-oauth2/spec_tech.md
-```
-Gera a secao 14 completa do SPEC_TECH (unitarios, integracao, e2e, cenarios de erro).
-
-### Modo 2: Testes para uma task especifica
-```
-/sdd:generate-tests docs/auth-oauth2/tasks/T1.md
-```
-Gera a secao 6 completa da task (unitarios, integracao, e2e, cenarios de erro).
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** gere testes genericos — cada teste deve ter cenario especifico e verificavel
-- **SEMPRE** pesquise padroes de teste existentes no projeto antes de gerar
-- **SEMPRE** mapeie criterios de aceite (CA-XX) para testes
-- **SEMPRE** considere cenarios de erro, boundary values e edge cases
-- Todo fluxo de sucesso deve ter **pelo menos 2 cenarios de falha** correspondentes
-
-## Entrada
-
-$ARGUMENTS
+---
+description: "Gera estrategia de testes usando o agente qa-staff-engineer para feature/task do SDD. Param: caminho do spec_tech.md ou arquivo de task"
+argument-hint: "<spec_tech.md ex: docs/specs/feature-user/v1/spec_tech.md> ou <task ex: docs/specs/feature-user/v1/tasks/T1.md>"
+---
+
+> **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `sdd` antes de salvar artefatos. O path real de cada artefato vem do config (`docs/specs/{feature}/{version}/...`).
+
+Este comando delega a geracao de testes ao agente **`qa-staff-engineer`**. Voce (comando orquestrador) prepara a entrada, dispara o agente, converte o JSON retornado em markdown tabular e integra ao arquivo destino.
+
+## Contexto
+
+O comando atua como orquestrador — o **qa-staff-engineer** (definido em `.claude/agents/qa-staff-engineer.md`) e quem gera os casos de teste de alto valor como QA Engineer Senior / SDET.
+
+## Modos de Uso
+
+### Modo 1: Estrategia completa para uma feature (SPEC_TECH)
+
+```
+/sdd:generate-tests docs/specs/auth-oauth2/v1/spec_tech.md
+```
+
+Preenche a **secao 14 do SPEC_TECH** (unitarios, integracao, e2e, cenarios de erro).
+
+### Modo 2: Testes para uma task especifica
+
+```
+/sdd:generate-tests docs/specs/auth-oauth2/v1/tasks/T1.md
+```
+
+Preenche a **secao 6 da task individual** (unitarios, integracao, e2e, cenarios de erro).
+
+## Processo Orquestrado
+
+### Passo 1: Identificar o alvo
+
+A partir do `$ARGUMENTS`, determine:
+
+- Se e um `spec_tech.md` → alvo e a **secao 14 do SPEC_TECH**
+- Se e uma `tasks/T[N].md` → alvo e a **secao 6 da task**
+
+### Passo 2: Preparar a lista de arquivos
+
+Monte a lista de `arquivos` que o agente deve ler:
+
+- **SPEC_TECH**: `docs/specs/[nome-feature]/[versao]/spec_tech.md`
+- **PRD**: `docs/specs/[nome-feature]/[versao]/prd.md`
+- **Task alvo** (modo 2): `docs/specs/[nome-feature]/[versao]/tasks/T[N].md`
+- **Regras do projeto**: `CLAUDE.md`, `.claude/rules/*.md`
+- **Testes existentes** relacionados aos componentes impactados
+- **Codigo-fonte existente** listado na secao 15 do SPEC_TECH (modo 1) ou secao 5 da task (modo 2)
+
+### Passo 3: Preparar as instrucoes
+
+Monte o campo `instrucoes` com:
+
+1. O **escopo** do que testar (feature inteira ou task especifica)
+2. Os **criterios de aceite** (CA-XX do PRD ou da task)
+3. Os **arquivos impactados**
+4. O **tipo** (feature completa, task de handler, task de service, etc.)
+5. Contexto adicional relevante
+
+### Passo 4: Disparar o agente qa-staff-engineer
+
+Lance o agente usando a ferramenta `Agent` com:
+
+- **subagent_type**: `qa-staff-engineer`
+- **description**: "QA gerar testes [feature ou TN]"
+- **prompt**: Monte o prompt com os 3 parametros obrigatorios:
+
+```
+Voce foi invocado com os seguintes parametros:
+
+1. **modo**: GERAR_TESTES
+2. **arquivos**: [lista de caminhos dos arquivos preparados no Passo 2]
+3. **instrucoes**: [conteudo preparado no Passo 3]
+```
+
+### Passo 5: Converter JSON em markdown tabular
+
+O agente retorna um JSON com `casos_teste[]`. Converta para o formato tabular da secao destino usando o mapeamento:
+
+| Campo `tipo` no JSON | Subsecao destino |
+|---------------------|-----------------|
+| `UNITARIO` | **14.1 / 6.1 — Testes Unitarios** |
+| `INTEGRACAO` | **14.2 / 6.2 — Testes de Integracao** |
+| `E2E` | **14.3 / 6.3 — Testes E2E** |
+| `SEGURANCA` / `PERFORMANCE` | **14.4 / 6.4 — Cenarios de Erro** |
+
+Alem disso, inclua em 14.4/6.4 todo `casos_teste` com `categoria` igual a `tratamento_erro`, `caso_extremo` ou `fronteira`.
+
+#### Formato tabular — Testes Unitarios
+
+```markdown
+#### [Camada]: [NomeComponente] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-XX | TestMetodo_Cenario | CA-XX | Verificar que [comportamento] quando [condicao] | dados entrada | resultado esperado | dependencias mockadas |
+```
+
+#### Formato tabular — Testes de Integracao
+
+```markdown
+#### [CamadaA + CamadaB] (`arquivo_test.go`)
+
+Setup: [banco in-memory, migracoes, fixtures]
+
+| CT | Teste | CA | Objetivo | Fluxo | Validacao |
+|----|-------|----|----------|-------|-----------|
+| CT-XX | TestIntegracao_Cenario | CA-XX | Verificar que [comportamento] quando [condicao] | Passos do fluxo | Assertions esperadas |
+```
+
+#### Formato descritivo — Testes E2E
+
+```markdown
+#### Fluxo: [Nome do Fluxo] (CT-XX)
+- **CA**: CA-XX, CA-YY
+- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
+- **Pre-condicoes**: (estado inicial do sistema)
+- **Passos**:
+  1. Passo 1
+  2. Passo 2
+- **Validacoes**: (assertions sobre dados e estado final)
+```
+
+#### Formato tabular — Cenarios de Erro
+
+```markdown
+| Cenario | CA | Objetivo | Trigger | Codigo/Status | Log Esperado |
+|---------|----|----------|---------|---------------|-------------|
+| Descricao do cenario | CA-XX | Verificar que [constraint] impede [operacao] | Acao trigger | Codigo erro | Mensagem log |
+```
+
+### Passo 6: Integrar ao arquivo destino
+
+1. Leia o arquivo destino (`spec_tech.md` ou `tasks/T[N].md`)
+2. Substitua a secao de testes (14 ou 6) pelo conteudo convertido
+3. Valide coerencia: componentes testados devem existir em secoes anteriores; testes devem cobrir os criterios de aceite
+4. Salve o arquivo
+
+### Passo 7: Apresentar ao usuario
+
+Apresente o resumo ao usuario (nao o conteudo completo):
+
+```
+Testes gerados para: [feature ou TN]
+Total: [N] casos de teste
+- Unitarios: [n]
+- Integracao: [n]
+- E2E: [n]
+- Cenarios de erro: [n]
+
+Arquivo atualizado: [path]
+
+Aprova essa secao de testes? (sim/nao)
+```
+
+## Regras Adicionais
+
+- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
+- **NUNCA** gere testes genericos — cada teste deve ter cenario especifico e verificavel
+- **SEMPRE** mapeie criterios de aceite (CA-XX) para testes
+- **SEMPRE** considere cenarios de erro, boundary values e edge cases
+- Todo fluxo de sucesso deve ter **pelo menos 2 cenarios de falha** correspondentes
+- Para tasks sem codigo (documentacao, configuracao): preencha "N/A — task nao envolve codigo testavel"
+
+## Entrada
+
+$ARGUMENTS

package/frameworks/config/ai-framework-config.yaml

@@ -95,11 +95,11 @@ ministack:
 # --------------------------------------------------------------------------
 taskcard:
   task_plan:
-    path: "docs/specs/{feature}/{version}/task-plan.md"
+    path: "docs/specs/{feature}/{version}/task_plan.md"
     generated_by: "taskcard:generate-taskcard"
 
   tasks:
-    dir: "docs/specs/{feature}/{version}/"
+    dir: "docs/specs/{feature}/{version}/tasks/"
     pattern: "task-{nn}-{slug}.md"
     generated_by: "taskcard:generate-taskcard"
 

package/frameworks/skills/ministack-tasks-expert/SKILL.md

@@ -1,15 +1,31 @@
 ---
 name: ministack-tasks-expert
-description: Especialista em geracao de TASKS do framework miniStack. Atua como Engenheiro de Software Senior decompondo SCOPE em tasks atomicas e executaveis.
-argument-hint: [INTENT aprovada + SCOPE aprovado]
+description: Especialista em geração de TASKS do framework miniStack. Atua como Engenheiro de Software Sênior decompondo SCOPE em tasks atômicas e executáveis.
+argument-hint: [caminho do intent.md + caminho do scope.md]
 ---
 
-Voce e um **Engenheiro de Software Senior** que decompoe SCOPE aprovado em tasks atomicas e executaveis.
+Você é um **Engenheiro de Software Sênior** que decompõe SCOPE aprovado em tasks atômicas e executáveis.
 
 Você domina completamente o framework miniStack e seu foco é **EXCLUSIVAMENTE** na geração de TASKS — definindo COMO EXECUTAR a implementação em unidades atômicas de trabalho.
 
 ---
 
+# Paths dos Artefatos
+
+> **OBRIGATÓRIO**: Antes de salvar qualquer artefato, leia `.claude/config/ai-framework-config.yaml` seção `ministack` e use os paths ali definidos.
+
+Paths definidos no config (para referência):
+
+| Artefato | Path |
+|----------|------|
+| task_plan | `docs/specs/{feature}/{version}/task_plan.md` |
+| tasks (dir) | `docs/specs/{feature}/{version}/tasks/` |
+| tasks (arquivo) | `docs/specs/{feature}/{version}/tasks/T{n}.md` |
+
+Substitua `{feature}` pelo nome da feature em kebab-case e `{version}` pela versão (ex: `v1`) identificados a partir do path da INTENT/SCOPE recebido como argumento.
+
+---
+
 # Regra de Acentuação
 
 Todo artefato gerado por esta skill é um documento em português brasileiro. Todo conteúdo textual (títulos, descrições, instruções, regras, mensagens) deve usar acentuação correta do pt-BR:
@@ -24,178 +40,173 @@ Apenas nomes de código (funções, variáveis, structs, pacotes) permanecem sem
 
 # Framework miniStack — Especialista TASKS
 
-## Visao Geral
+## Visão Geral
 
-**miniStack** e um framework estruturado para decomposicao e execucao de features de forma colaborativa, baseado em documentacao clara com **3 etapas principais**: INTENT, SCOPE e TASKS.
+**miniStack** é um framework estruturado para decomposição e execução de features de forma colaborativa, baseado em documentação clara com **3 etapas principais**: INTENT, SCOPE e TASKS.
 
 ### Fluxo Completo
 
 ```
-Descricao da Feature
+Descrição da Feature
         |
-   /generate-intent          (ministack-intent-expert)
+   /generate-intent           (ministack-intent-expert)
         | (INTENT aprovada)
-   /generate-scope            (ministack-scope-expert)
+   /generate-scope             (ministack-scope-expert)
         | (SCOPE aprovado)
-   /generate-tasks            <-- voce esta aqui (ministack-tasks-expert)
+   /generate-tasks             <-- você está aqui (ministack-tasks-expert)
         | (TASKS aprovadas)
-   /run-ministack-tasks       (comando orquestrador)
+   /run-ministack-tasks        (comando orquestrador)
         |
    Feature Implementada
 ```
 
-O TASKS Expert responde: **COMO decompor o SCOPE em unidades atomicas de trabalho?**
+O TASKS Expert responde: **COMO decompor o SCOPE em unidades atômicas de trabalho?**
 
 ---
 
-## Principio Fundamental
+## Princípio Fundamental
 
-As TASKS transformam o SCOPE aprovado em **unidades atomicas de trabalho** executaveis por humanos ou agentes de IA.
+As TASKS transformam o SCOPE aprovado em **unidades atômicas de trabalho** executáveis por humanos ou agentes de IA.
 
-## Regras Obrigatorias
+## Regras Obrigatórias
 
-- **NUNCA** deduzir escopo ou inventar informacoes — na DUVIDA, PERGUNTE AO USUARIO
-- **SEMPRE** salvar os arquivos fisicos antes de pedir aprovacao
-- **NUNCA** iniciar automaticamente a proxima etapa
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
+- **NUNCA** deduzir escopo ou inventar informações — na DÚVIDA, PERGUNTE AO USUÁRIO
+- **SEMPRE** salvar os arquivos físicos antes de pedir aprovação
+- **NUNCA** iniciar automaticamente a próxima etapa
+- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer dúvidas com o usuário
 
-## Criterios de Qualidade
+## Critérios de Qualidade
 
-| Atributo | Descricao |
+| Atributo | Descrição |
 |----------|-----------|
-| Atomica | Executavel sem novas decisoes |
-| Independente | Minimize dependencias |
+| Atômica | Executável sem novas decisões |
+| Independente | Minimize dependências |
 | Pequena | Se > 3 subtarefas, quebre em tasks |
 | Clara | Suficiente para LLM executar |
-| Verificavel | Criterio claro de conclusao |
-| Ordenada | Ordem e dependencias definidas |
+| Verificável | Critério claro de conclusão |
+| Ordenada | Ordem e dependências definidas |
 
 ## Processo (3 Fases)
 
-### Fase 1: Analise e Validacao
+### Fase 1: Análise e Validação
 
 **ANTES de gerar as tasks**, analise Intent e Scope:
 
-- Intent esta claro sobre o objetivo?
+- Intent está claro sobre o objetivo?
 - Scope delimita claramente o que entra e sai?
-- Ha ambiguidades que precisam esclarecimento?
-- Detectou dependencias ocultas?
-- Algo parece inviavel ou conflitante?
+- Há ambiguidades que precisam esclarecimento?
+- Detectou dependências ocultas?
+- Algo parece inviável ou conflitante?
 
-Se houver duvidas, pergunte ao usuario antes de prosseguir.
+Se houver dúvidas, pergunte ao usuário antes de prosseguir.
 
-### Fase 2: Geracao das Tasks
+### Fase 2: Geração das Tasks
 
 Para cada task, preencha o template individual (`task_template.md`) com:
-- **ID**: T1, T2, T3... (unico)
-- **Nome**: Descricao curta
-- **Objetivo**: O que sera entregue
+- **ID**: T1, T2, T3... (único)
+- **Nome**: Descrição curta
+- **Objetivo**: O que será entregue
 - **Arquivos**: Criados/modificados (economiza tokens e scans)
-- **Dependencias**: Quais tasks antes
-- **Criterio de Conclusao**: Como validar
-- **Detalhes de Implementacao**: Subtasks com checklist
-- **Testes**: Secao controlada pelo comando orquestrador (ver nota abaixo)
+- **Dependências**: Quais tasks antes
+- **Critério de Conclusão**: Como validar
+- **Detalhes de Implementação**: Subtasks com checklist
+- **Testes**: Seção controlada pelo comando orquestrador (ver nota abaixo)
 
-Alem disso, preencha o `task_plan_template.md` com:
-- **Macro-Fases**: agrupamento logico das tasks
+Além disso, preencha o `task_plan_template.md` com:
+- **Macro-Fases**: agrupamento lógico das tasks
 - **Lista de Tasks**: tabela com links para cada arquivo individual
-- **Grafo de Dependencias**: ordem de execucao e paralelismo
-- **Visao consolidada de arquivos**: todos os arquivos impactados
-
-> **IMPORTANTE**: A secao de **Testes** de cada task e controlada pelo comando orquestrador
-> (`/ministack:generate-tasks`) que delega ao agente QA especializado (`qa-staff-engineer`).
-> Voce NAO deve delegar diretamente ao agente QA — apenas deixe a secao de Testes vazia
-> com o marcador `[PENDENTE — sera preenchida pelo agente QA]`.
-
-### Fase 3: Salvar Arquivos (OBRIGATORIO)
-
-1. Identificar nome da feature a partir da INTENT/SCOPE
-2. **Remover todos os comentarios `<!-- LLM-ONLY: ... -->`** do conteudo antes de salvar — sao instrucoes internas do template e NAO devem aparecer nos arquivos gerados
-3. **Salvar os arquivos fisicos**:
-   - Task Plan: `docs/[nome-feature]/vN/task_plan.md`
-   - Cada task individual: `docs/[nome-feature]/vN/tasks/T1.md`, `T2.md`, ...
+- **Grafo de Dependências**: ordem de execução e paralelismo
+- **Visão consolidada de arquivos**: todos os arquivos impactados
+
+> **IMPORTANTE — Divisão de Responsabilidades (Testes)**:
+>
+> O fluxo de geração de testes é **sequencial** e dividido entre skill e comando:
+>
+> 1. **Esta skill** preenche todas as seções da task EXCETO a seção de Testes. Na seção de Testes,
+>    deixe apenas o marcador: `[PENDENTE — será preenchida pelo comando orquestrador via qa-staff-engineer]`
+> 2. **O comando `/ministack:generate-tasks`** (orquestrador) assume depois: lê a task parcial gerada,
+>    delega ao agente `qa-staff-engineer` (modo `GERAR_TESTES`), recebe o JSON estruturado, converte
+>    para markdown tabular e integra na seção de Testes antes de salvar o arquivo final.
+>
+> Você NÃO deve invocar o agente QA diretamente — essa orquestração é do comando. Apenas deixe
+> a seção marcada como pendente e permita que o comando complete o fluxo.
+
+### Fase 3: Salvar Arquivos (OBRIGATÓRIO)
+
+1. Identificar nome da feature a partir da INTENT/SCOPE (kebab-case) e a versão (ex: `v1`)
+2. **Remover todos os comentários `<!-- LLM-ONLY: ... -->`** do conteúdo antes de salvar — são instruções internas do template e NÃO devem aparecer nos arquivos gerados
+3. **Salvar os arquivos físicos** usando os paths do config (`.claude/config/ai-framework-config.yaml`, seção `ministack`):
+   - Task Plan: `docs/specs/[nome-feature]/[versão]/task_plan.md`
+   - Cada task individual: `docs/specs/[nome-feature]/[versão]/tasks/T1.md`, `T2.md`, ...
 4. Confirmar que todos os arquivos foram criados
 
 ## Templates
 
-- **Task Plan (indice)**: [task_plan_template.md](templates/task_plan_template.md)
+- **Task Plan (índice)**: [task_plan_template.md](templates/task_plan_template.md)
 - **Task Individual**: [task_template.md](templates/task_template.md)
 
-## Estrutura de Saida
+## Estrutura de Saída
 
 ```
 docs/
-  <nome-feature>/
-    vN/
-      intent.md          # INTENT aprovada (ministack-intent-expert)
-      scope.md           # SCOPE aprovado (ministack-scope-expert)
-      task_plan.md       # Indice e coordenacao (voce gera este arquivo)
-      tasks/
-        T1.md            # Task individual (voce gera cada arquivo)
-        T2.md
-        T3.md
-        ...
+  specs/
+    <nome-feature>/
+      <versão>/
+        intent.md          # INTENT aprovada (ministack-intent-expert)
+        scope.md           # SCOPE aprovado (ministack-scope-expert)
+        task_plan.md       # Índice e coordenação (você gera este arquivo)
+        tasks/
+          T1.md            # Task individual (você gera cada arquivo)
+          T2.md
+          T3.md
+          ...
 ```
 
-## Saida Esperada
+## Saída Esperada
 
 ```
-Arquivos salvos em: docs/[nome-feature]/vN/
-  - task_plan.md (indice com [N] tasks)
+Arquivos salvos em: docs/specs/[nome-feature]/[versão]/
+  - task_plan.md (índice com [N] tasks)
   - tasks/T1.md ... tasks/T[N].md
 
 Tarefas Geradas
 Total: [N] tasks
-Sequencia: T1 -> T2 -> T3 (paralelo: T4, T5) -> T6
+Sequência: T1 -> T2 -> T3 (paralelo: T4, T5) -> T6
 
-Aprova essas tasks para execucao? (sim/nao)
+Aprova essas tasks para execução? (sim/não)
 ```
 
 **IMPORTANTE:**
-- NAO inicie `/run-ministack-tasks` automaticamente
-- NAO sugira executar o proximo comando
-- Apenas aguarde a confirmacao do usuario e encerre
+- NÃO inicie `/run-ministack-tasks` automaticamente
+- NÃO sugira executar o próximo comando
+- Apenas aguarde a confirmação do usuário e encerre
 
 ---
 
-## Guardrails Inviolaveis
+## Guardrails Invioláveis
 
-1. **Aprovacao obrigatoria** — nunca avance sem confirmacao do usuario
-2. **Sem invencao** — se faltar informacao, PERGUNTE ao usuario
-3. **Escopo fechado** — cada documento deve ser auto-suficiente
-4. **Template completo** — todas as secoes devem ser preenchidas
-5. **Arquivos fisicos** — SEMPRE salvar antes de apresentar ao usuario
-6. **AskUserQuestion** — no Claude Code, use esta ferramenta para esclarecer duvidas
-7. **Testes via orquestrador** — NAO delegue testes diretamente, o comando orquestrador faz isso
+1. **Paths do config** — SEMPRE leia `.claude/config/ai-framework-config.yaml` antes de salvar
+2. **Aprovação obrigatória** — nunca avance sem confirmação do usuário
+3. **Sem invenção** — se faltar informação, PERGUNTE ao usuário
+4. **Escopo fechado** — cada documento deve ser auto-suficiente
+5. **Template completo** — todas as seções devem ser preenchidas
+6. **Arquivos físicos** — SEMPRE salvar antes de apresentar ao usuário
+7. **AskUserQuestion** — no Claude Code, use esta ferramenta para esclarecer dúvidas
+8. **Testes via orquestrador** — NÃO delegue testes diretamente, o comando orquestrador faz isso
 
 ---
 
-## Convencoes
+## Convenções
 
 ### Nomenclatura
 
-| Elemento | Convencao | Exemplo |
+| Elemento | Convenção | Exemplo |
 |----------|-----------|---------|
 | Nome da feature | kebab-case | `auth-oauth2`, `user-profile` |
-| ID de task | T + numero | `T1`, `T2`, `T3` |
-| Diretorio | `docs/<nome>/vN/` | `docs/auth/v1/` |
-| Arquivo task plan | `task_plan.md` | `docs/auth/v1/task_plan.md` |
-| Arquivo task individual | `T[N].md` | `docs/auth/v1/tasks/T1.md` |
-
-### Estrutura de Diretorios
-
-```
-docs/
-  <nome-feature>/
-    vN/
-      intent.md          # INTENT aprovada (ministack-intent-expert)
-      scope.md           # SCOPE aprovado (ministack-scope-expert)
-      task_plan.md       # Indice e coordenacao (voce gera este arquivo)
-      tasks/
-        T1.md            # Task individual (voce gera cada arquivo)
-        T2.md
-        ...
-```
+| ID de task | T + número | `T1`, `T2`, `T3` |
+| Diretório | `docs/specs/<nome>/<versão>/` | `docs/specs/auth/v1/` |
+| Arquivo task plan | `task_plan.md` | `docs/specs/auth/v1/task_plan.md` |
+| Arquivo task individual | `T[N].md` | `docs/specs/auth/v1/tasks/T1.md` |
 
 ---
 

package/frameworks/skills/ministack-tech-direction-expert/SKILL.md

@@ -20,6 +20,20 @@ Estilo: Objetivo. Contextualizado. Perguntas curtas com opções baseadas no cod
 
 ---
 
+# Paths dos Artefatos
+
+> **OBRIGATÓRIO**: Antes de salvar qualquer artefato, leia `.claude/config/ai-framework-config.yaml` seção `ministack` e use os paths ali definidos.
+
+Paths definidos no config (para referência):
+
+| Artefato | Path |
+|----------|------|
+| tech_direction | `docs/specs/{feature}/{version}/tech_direction.md` |
+
+Substitua `{feature}` pelo nome da feature em kebab-case e `{version}` pela versão (ex: `v1`) identificados a partir do path da INTENT recebida como argumento.
+
+---
+
 # Regra de Acentuação
 
 Todo artefato gerado por esta skill é um documento em português brasileiro. Todo conteúdo textual (títulos, descrições, instruções, regras, mensagens) deve usar acentuação correta do pt-BR:
@@ -184,7 +198,7 @@ Estas regras sao **absolutas** e nao podem ser violadas em nenhuma circunstancia
 
 O Tech Direction e salvo **na mesma pasta** da INTENT aprovada. O versionamento ja foi definido pela INTENT:
 
-- Se a INTENT esta em `docs/feature-x/v1/intent.md`, o tech_direction vai em `docs/feature-x/v1/tech_direction.md`
+- Se a INTENT esta em `docs/specs/feature-x/v1/intent.md`, o tech_direction vai em `docs/specs/feature-x/v1/tech_direction.md`
 - **NAO crie nova versao** — use a mesma pasta da INTENT fornecida como argumento
 
 ---
@@ -193,10 +207,11 @@ O Tech Direction e salvo **na mesma pasta** da INTENT aprovada. O versionamento
 
 **ANTES de apresentar o Tech Direction ao usuario**, voce DEVE:
 
-1. **Identificar o diretorio** da INTENT fornecida (ex: `docs/feature-x/v1/`)
-2. **Remover todos os comentarios `<!-- LLM-ONLY: ... -->`** do conteudo antes de salvar
-3. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/tech_direction.md` (mesmo diretorio da INTENT)
-4. **Confirmar** que o arquivo foi criado com sucesso
+1. **Ler o config** `.claude/config/ai-framework-config.yaml` secao `ministack.tech_direction` para obter o path
+2. **Identificar o diretorio** da INTENT fornecida (ex: `docs/specs/feature-x/v1/`)
+3. **Remover todos os comentarios `<!-- LLM-ONLY: ... -->`** do conteudo antes de salvar
+4. **Salvar o arquivo fisico** em: `docs/specs/[nome-feature]/[versao]/tech_direction.md` (mesmo diretorio da INTENT)
+5. **Confirmar** que o arquivo foi criado com sucesso
 
 ---
 
@@ -205,7 +220,7 @@ O Tech Direction e salvo **na mesma pasta** da INTENT aprovada. O versionamento
 Apos salvar o arquivo fisico, apresente **apenas um resumo compacto**. NAO exiba o tech_direction completo no terminal.
 
 ```
-Arquivo salvo em: docs/[nome-feature]/vN/tech_direction.md
+Arquivo salvo em: docs/specs/[nome-feature]/[versao]/tech_direction.md
 
 ## Resumo do Tech Direction
 - **Decisoes:** [lista curta]

package/frameworks/skills/prompt-engineer-expert/SKILL.md

@@ -165,14 +165,15 @@ O template completo está em: [prompt_template.md](templates/prompt_template.md)
 | 5. Formato da Resposta | Inferido do tipo de tarefa |
 | 6. Persona / Tom | Inferido do contexto |
 
-### Seções opcionais (7-10)
+### Seções opcionais (7-9)
 
 | Seção | Quando incluir |
 |-------|---------------|
 | 7. Critérios de Aceite | Tarefas complexas ou com requisitos mensuráveis |
 | 8. Exemplos | Quando houver padrões claros de entrada/saída |
 | 9. Arquivos Envolvidos | Quando a tarefa envolve criar/modificar arquivos específicos |
-| 10. Testes de Unidade | Quando o usuário solicitar (preenchida pelo comando, não pela skill) |
+
+> **Nota sobre Testes**: a geração de testes (seção 10 do template, quando aplicável) é responsabilidade do **comando orquestrador** `/generate-prompt`, que delega ao agente `qa-staff-engineer`. Esta skill NÃO preenche a seção 10 — deixe-a ausente no rascunho ou com o marcador `[PENDENTE — será preenchida pelo comando via qa-staff-engineer]`.
 
 ### Apresentação ao usuário
 
@@ -182,7 +183,7 @@ Apresente o rascunho completo e pergunte:
 Aqui está o rascunho do prompt. Revise e me diga:
 - Algo está incorreto ou faltando?
 - Alguma seção precisa de mais detalhe?
-- Deseja adicionar seções opcionais (Critérios de Aceite, Exemplos, Arquivos, Testes)?
+- Deseja adicionar seções opcionais (Critérios de Aceite, Exemplos, Arquivos Envolvidos)?
 ```
 
 ---
@@ -193,7 +194,7 @@ Itere com o usuário até que o prompt esteja satisfatório.
 
 - Aceite feedback livre e aplique as correções
 - Não limite o número de iterações — o prompt precisa estar bom
-- A seção 10 (Testes de Unidade) **não é responsabilidade desta skill** — ela é tratada pelo comando `/generate-prompt` após a skill concluir
+- **Seção 10 (Testes)** NÃO é responsabilidade desta skill — o comando orquestrador `/generate-prompt` delega ao agente `qa-staff-engineer` após a skill concluir. Deixe a seção 10 ausente ou com o marcador `[PENDENTE — será preenchida pelo comando via qa-staff-engineer]`
 
 ---
 
@@ -217,9 +218,11 @@ Se algum guardrail falhar, corrija antes de salvar — não peça ao usuário pa
 ### Salvamento
 
 1. Derive o slug da tarefa a partir do objetivo (ex: `autenticacao-jwt`, `crud-produtos`)
-2. Crie o diretório: `docs/prompts/[slug]/`
-3. Salve o prompt: `docs/prompts/[slug]/[slug]_prompt.md`
-4. Informe o caminho ao usuário
+2. Verifique se o diretório `docs/prompts/` existe; se não, crie-o
+3. Crie o subdiretório: `docs/prompts/[slug]/`
+4. Salve o prompt: `docs/prompts/[slug]/[slug]_prompt.md`
+5. Confirme que o arquivo foi criado com sucesso
+6. Informe o caminho ao usuário
 
 ---