adi_dev_workflow 1.0.0 → 1.1.0

package/frameworks/commands/taskcard/generate-taskcard.md

@@ -1,25 +1,42 @@
----
-description: Gera uma TaskCard individual clara e executável para uma task específica
-argument-hint: [contexto da tarefa ou Intent + Scope]
----
-
-Seu papel: **Gerador de TaskCard**. Voce NAO executa — apenas gera o documento.
-
-Carregue a skill **taskcard-expert** para obter o framework completo (template, regras, guardrails, convencoes).
-Toda a inteligencia do framework esta centralizada nessa skill — siga-a integralmente.
-
-## Instrucoes
-
-1. Leia o contexto fornecido pelo usuario
-2. Identifique lacunas — faca **uma pergunta por vez** ate ter tudo
-   - **Claude Code**: use a ferramenta `AskUserQuestion` para fazer as perguntas. Ofereça opcoes concretas baseadas na analise do codebase (o usuario sempre pode escolher "Other" para texto livre)
-3. Preencha o **template oficial** (todas as 11 secoes) conforme a skill taskcard-expert
-4. Salve imediatamente em `docs/<nome-feature>/task-<numero>-<slug>.md` — **NAO peca aprovacao antes de salvar**
-5. Apresente um **resumo curto** do que foi criado (ID, nome, arquivos gerados, escopo resumido)
-6. Se trabalho for grande, quebre em multiplas (gere apenas a primeira)
-7. Se multiplas TaskCards, pergunte se quer gerar a proxima
-8. Ao final de todas, ofereca criar `task-plan.md` com ordem e dependencias
-
-## Entrada
-
-$ARGUMENTS
+---
+description: Gera uma TaskCard individual clara e executável para uma task específica
+argument-hint: [contexto da tarefa ou Intent + Scope]
+---
+
+Seu papel: **Gerador de TaskCard**. Voce NAO executa — apenas gera o documento.
+
+Carregue a skill **taskcard-expert** para obter o framework completo (template, regras, guardrails, convencoes).
+Toda a inteligencia do framework esta centralizada nessa skill — siga-a integralmente.
+
+## Instrucoes
+
+1. Leia o contexto fornecido pelo usuario
+2. Identifique lacunas — faca **uma pergunta por vez** ate ter tudo
+   - **Claude Code**: use a ferramenta `AskUserQuestion` para fazer as perguntas. Ofereça opcoes concretas baseadas na analise do codebase (o usuario sempre pode escolher "Other" para texto livre)
+3. Preencha o **template oficial** (secoes 1-9 e 11) conforme a skill taskcard-expert
+4. Salve imediatamente em `docs/<nome-feature>/task-<numero>-<slug>.md` — **NAO peca aprovacao antes de salvar**
+5. **Delegue a secao 10 (Testes) ao agente `qa-staff-engineer`**:
+   - Lance usando a ferramenta `Agent` com:
+     - **subagent_type**: `qa-staff-engineer`
+     - **description**: "Gerar testes TaskCard TC-XXX"
+     - **prompt**:
+     ```
+     Voce foi invocado com os seguintes parametros:
+
+     1. **modo**: GERAR_TESTES
+     2. **arquivos**: [caminho da TaskCard gerada]
+     3. **instrucoes**: Leia a TaskCard completa. Analise o codebase, testes existentes e padroes do projeto.
+        Preencha a secao 10 (subsecoes 10.1 a 10.6) diretamente no arquivo da TaskCard.
+        Use os criterios de aceite da secao 9 para mapear rastreabilidade (10.6).
+        Use os arquivos da secao 8 para identificar testes a modificar (10.1) e a criar (10.2).
+        Respeite os padroes de teste do projeto (project-profile.md e .claude/rules/).
+     ```
+   - O agente preenchera as subsecoes 10.1 a 10.6 no arquivo da TaskCard
+6. Apresente um **resumo curto** do que foi criado (ID, nome, arquivos gerados, escopo resumido)
+7. Se trabalho for grande, quebre em multiplas (gere apenas a primeira)
+8. Se multiplas TaskCards, pergunte se quer gerar a proxima
+9. Ao final de todas, ofereca criar `task-plan.md` com ordem e dependencias
+
+## Entrada
+
+$ARGUMENTS

package/frameworks/commands/taskcard/run-taskcard.md

@@ -1,34 +1,203 @@
----
-description: Executa uma TaskCard aprovada com precisão seguindo guardrails definidos
-argument-hint: [caminho da taskcard] [agente opcional ex: go-backend-implementer]
----
-
-Seu papel: **Executor de TaskCard**. Execute com precisao, sem desvios ou reinterpretacao.
-
-Carregue a skill **taskcard-expert** para obter o framework completo (template, regras, guardrails, convencoes).
-Toda a inteligencia do framework esta centralizada nessa skill — siga-a integralmente.
-
-## Argumentos
-
-- `$0` — Caminho da TaskCard (obrigatorio)
-- `$1` — Agente executor opcional (subagent_type para ferramenta Task)
-
-Agentes disponiveis em `.claude/agents/`.
-
-## Instrucoes
-
-1. Leia a TaskCard completa no caminho `$0`
-2. Leia os arquivos da secao 8.1 (existentes/referencia) para contexto
-3. Valide secoes 3-9 preenchidas e dependencias satisfeitas
-4. Execute os **Passos Sugeridos** (secao 7) na ordem
-5. A cada passo, valide guardrails DEVE e NAO DEVE (secao 6)
-6. Se guardrail for violado ou algo conflitar: **PARE e avise**
-   - **Claude Code**: use a ferramenta `AskUserQuestion` para apresentar o bloqueio e opcoes de resolucao ao usuario
-7. Valide aceite tecnico (secao 9) ao final
-8. Produza relatorio de execucao no formato padrao da skill
-
-Se agente `$1` for especificado, delegue a execucao via ferramenta Task com `subagent_type: $1`.
-
-## Entrada
-
-$ARGUMENTS
+---
+description: "Executa uma TaskCard com gates QA + Tech Review. Params: <caminho_taskcard> [agent_name]"
+argument-hint: "<caminho da taskcard> [agente opcional ex: go-expert]"
+---
+
+Voce e um **Executor de TaskCard com Validacao**. Execute com precisao, sem desvios ou reinterpretacao.
+
+Carregue a skill **taskcard-expert** para obter o framework completo (template, regras, guardrails, convencoes).
+
+## Parametros
+
+O `$ARGUMENTS` deve conter:
+
+1. **taskcard_path** (obrigatorio) — Caminho da TaskCard (ex: `docs/feature/v1/task-01-slug.md`)
+2. **agent_name** (opcional) — Nome do sub-agente executor (ex: `go-expert`)
+
+**Formato:** `<taskcard_path> [agent_name]`
+
+---
+
+## Instrucoes de Execucao
+
+### Passo 1: Preparar
+
+1. Leia a TaskCard completa no caminho fornecido
+2. Leia os arquivos da secao 8.1 (existentes/referencia) para contexto
+3. Valide secoes 3-9 preenchidas e dependencias satisfeitas (secao 1)
+
+### Passo 2: Executar
+
+1. Execute os **Passos Sugeridos** (secao 7) na ordem
+2. A cada passo, valide guardrails DEVE e NAO DEVE (secao 6)
+3. Se guardrail for violado ou algo conflitar: **PARE e avise**
+   - Use a ferramenta `AskUserQuestion` para apresentar o bloqueio e opcoes de resolucao
+4. Execute testes (secao 10): modifique existentes e crie novos
+5. Rode testes e garanta que passam
+
+Se **agent_name** for especificado, delegue a execucao via ferramenta `Agent` com `subagent_type: agent_name`.
+
+### Passo 3: Validar aceite tecnico
+
+Valide cada criterio da secao 9 (Aceite Tecnico). Se algum criterio NAO for atendido, corrija antes de avancar.
+
+### Passo 4: Gate 1 — QA (qa-staff-engineer)
+
+Apos a execucao, lance o subagente QA para validar a implementacao.
+
+**Preparar lista de arquivos para o QA:**
+- TaskCard: caminho fornecido
+- Arquivos criados/modificados: todos os arquivos das secoes 8.2 e 8.3
+- Arquivos de teste: todos os testes criados ou modificados (secao 10)
+
+**Disparar o subagente:**
+
+Lance usando a ferramenta `Agent` com:
+- **subagent_type**: `qa-staff-engineer`
+- **description**: "QA validar TaskCard"
+- **prompt**:
+
+```
+Voce foi invocado com os seguintes parametros:
+
+1. **modo**: VALIDAR_IMPLEMENTACAO
+2. **arquivos**: [lista de caminhos preparada acima]
+3. **instrucoes**: Valide a implementacao da TaskCard [ID] - [Nome]. Criterios de aceite tecnico: [conteudo da secao 9]. Execute os testes e valide cada criterio.
+```
+
+**Interpretar resultado:**
+
+| Veredito | Problemas Criticos | Acao |
+|----------|-------------------|------|
+| `APROVADO` | 0 | Avancar para Gate 2 (Tech Review) |
+| `APROVADO_COM_OBSERVACOES` | 0 | Registrar observacoes. Avancar para Gate 2 |
+| `APROVADO_COM_OBSERVACOES` | > 0 | Tratar como REJEITADO — corrigir problemas criticos |
+| `REJEITADO` | qualquer | Ir para Passo 6 (Loop de correcao) |
+
+### Passo 5: Gate 2 — Tech Review (tech-review-conformance)
+
+**Somente apos o QA aprovar**, lance o subagente de revisao tecnica.
+
+Lance usando a ferramenta `Agent` com:
+- **subagent_type**: `tech-review-conformance`
+- **description**: "Tech Review TaskCard"
+- **prompt**:
+
+```
+Realize a revisao tecnica da TaskCard [ID] - [Nome].
+
+## Contexto da TaskCard
+- **Objetivo**: [conteudo da secao 3]
+- **Descricao de Execucao**: [conteudo da secao 5]
+
+## Aceite Tecnico (VALIDAR CADA ITEM)
+[conteudo completo da secao 9]
+
+## Arquivos Implementados (DEVE LER TODOS)
+[lista de arquivos criados/modificados — secoes 8.2 e 8.3]
+
+## Arquivos de Teste (DEVE LER TODOS)
+[lista de testes criados/modificados — secao 10]
+
+## Arquivos de Referencia (para comparacao de padroes)
+[lista de arquivos da secao 8.1]
+
+Leia TODOS os arquivos listados e valide:
+1. Conformidade arquitetural (camadas, fluxo de dependencia, separacao de responsabilidades)
+2. Aderencia aos padroes do projeto (convencoes, nomenclatura, estrutura)
+3. Cada item do Aceite Tecnico listado acima
+4. Consistencia com padroes existentes (comparar com arquivos de referencia)
+5. Riscos tecnicos (debito tecnico, testabilidade, robustez)
+```
+
+**Interpretar resultado:**
+
+| Status | Acao |
+|--------|------|
+| `approved` | TaskCard concluida. Ir para Passo 7 (Relatorio final) |
+| `partial` | Ha problemas `high` que precisam correcao. Ir para Passo 6 |
+| `rejected` | Ha problemas `critical`. Ir para Passo 6 |
+
+### Passo 6: Loop de correcao (max 3 tentativas)
+
+Se o QA ou Tech Review reprovar a implementacao:
+
+1. **Extraia os problemas** do resultado (criticos e altos)
+2. **Corrija** todos os problemas listados (ou delegue ao agent_name se especificado)
+3. **Apos corrigir, re-valide** com AMBOS os gates:
+   - Primeiro QA (voltar ao Passo 4)
+   - Se QA aprovar, Tech Review (Passo 5)
+4. **Limite maximo: 3 tentativas TOTAIS** (compartilhado entre QA e Tech Review)
+
+Se apos 3 tentativas ainda houver rejeicao:
+- **NAO marque como concluida**
+- **Informe ao usuario** com:
+  - Qual TaskCard esta bloqueada
+  - Quantas tentativas foram feitas
+  - Quais problemas persistem
+  - Qual gate esta bloqueando (QA, Tech Review ou ambos)
+  - Sugestao de acao
+- **Pergunte ao usuario** como proceder antes de continuar
+
+### Passo 7: Relatorio final
+
+Produza relatorio de execucao no formato padrao:
+
+```
+TaskCard Executada
+
+ID: [ID da TaskCard]
+Nome: [Nome da Task]
+
+Passos Executados:
+- [x] Passo 1 - Descricao
+- [x] Passo 2 - Descricao
+
+Arquivos Modificados:
+- `path/to/file` - [descricao da mudanca]
+
+Guardrails Validados:
+- DEVE: [lista validada]
+- NAO DEVE: [nenhuma violacao]
+
+Testes:
+- Modificados: [lista de arquivos de teste alterados]
+- Criados: [lista de arquivos de teste novos]
+- Resultado: [X passando, Y falhando]
+
+Aceite Tecnico:
+- [x] Objetivo atingido
+- [x] Codigo compila sem erros
+- [x] Testes passando (novos e existentes)
+- [x] Padroes respeitados
+
+Validacao QA: [APROVADO / APROVADO_COM_OBSERVACOES]
+- Tentativas: [N]
+- Observacoes: [se houver]
+
+Validacao Tech Review: [approved / partial]
+- Tentativas: [N]
+- Observacoes: [se houver]
+
+Status: Concluido | Parcial | Bloqueado
+
+Observacoes: [se houver]
+```
+
+---
+
+## Regras da Validacao (QA + Tech Review)
+
+- **Toda TaskCard que modifica codigo** DEVE passar por ambos os gates — sem excecao
+- **Os gates sao SEQUENCIAIS**: primeiro QA (Gate 1), depois Tech Review (Gate 2) — NUNCA em paralelo
+- TaskCards que nao envolvem codigo (ex: documentacao) podem ser concluidas sem validacao
+- O QA deve **executar os testes** — nao apenas revisar o codigo
+- O Tech Review valida **conformidade arquitetural** — nao repete a validacao funcional do QA
+- Cada tentativa de correcao gera uma nova validacao completa de AMBOS os gates
+- O contador de tentativas e **compartilhado**: se a 1a tentativa foi correcao de QA e a 2a de Tech Review, restam 1 tentativa
+
+---
+
+## Entrada
+
+$ARGUMENTS

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

@@ -98,8 +98,9 @@ Use o template oficial em: [intent-template.md](templates/intent-template.md)
 
 1. Executar a logica de **Versionamento Inteligente** acima para determinar o diretorio correto
 2. Criar diretorio se nao existir: `docs/[nome-feature]/vN/`
-3. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/intent.md`
-4. Confirmar que o arquivo foi criado com sucesso
+3. **Remover todos os comentarios `<!-- LLM-ONLY: ... -->`** do conteudo antes de salvar — eles sao instrucoes internas do template e NAO devem aparecer no arquivo gerado
+4. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/intent.md`
+5. Confirmar que o arquivo foi criado com sucesso
 
 ## Saida Esperada
 

package/frameworks/skills/ministack-intent-expert/templates/intent-template.md

@@ -20,7 +20,7 @@
 - O que deve existir ao final desta tarefa?
 - Qual resultado tecnico ou estrutural se espera?
 
-> IMPORTANTE: Descreva apenas O QUE deve ser alcancado, NAO como implementar.
+<!-- LLM-ONLY: Descreva apenas O QUE deve ser alcancado, NAO como implementar. Remova este comentario no arquivo gerado. -->
 
 ---
 

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

@@ -62,17 +62,12 @@ O SCOPE transforma a INTENT em **definicoes tecnicas concretas**. Responde **COM
    - O tech_direction contem decisoes ja tomadas, tecnologias sugeridas e padroes preferidos
    - Voce pode **complementar, ajustar ou questionar** qualquer item — nao e uma ordem, e um direcionamento
    - Se NAO existir, siga o fluxo normal (propor solucao do zero)
-2. **Ler as rules do projeto** — buscar em:
-   - `.claude/rules/` (Claude Code)
-   - `CLAUDE.md` na raiz
-   - Qualquer arquivo de regras/convencoes do projeto
-3. **Explorar as camadas do projeto** — entender a arquitetura existente:
-   - Identificar as camadas reais do projeto a partir do CLAUDE.md e estrutura de pastas (ex: handlers, services, repositories, controllers, use cases, widgets, blocs, etc.)
-   - Estrutura de diretorios
-   - Padroes de codigo ja estabelecidos
+2. **Regras e perfil do projeto (pre-carregados)** — O `CLAUDE.md`, `.claude/rules/` e `project-profile.md` (se existir) ja estao no contexto — NAO releia. Use essas informacoes como base e foque a exploracao apenas em codigo especifico da feature.
+3. **Explorar a estrutura de pastas do projeto** para mapear as camadas reais existentes, padroes de codigo ja estabelecidos e estrutura de diretorios
 4. **Identificar codigo reutilizavel** — funcoes, tipos, classes, interfaces e componentes existentes
 5. **Mapear dependencias reais** — o que ja existe vs o que precisa ser criado
 6. **Propor a melhor solucao como um arquiteto senior** — considerando padroes, performance e manutenibilidade
+7. **Salvar perfil de testes (se nao existe)** — Se `.claude/rules/project-profile.md` NAO existir no contexto, pesquise padroes de teste do projeto (framework, mocks, helpers, nomenclatura, setup por camada) e salve como `.claude/rules/project-profile.md`. Isso evita que agentes posteriores repitam a exploracao de padroes de teste.
 
 > Nunca assuma que algo precisa ser criado se ja pode existir no projeto.
 > Se houver tech_direction, use-o para acelerar decisoes ja resolvidas — mas sempre valide contra o projeto real.
@@ -108,8 +103,9 @@ Defina com clareza:
 
 1. Identificar nome da feature a partir da INTENT
 2. Criar diretorio se nao existir: `docs/[nome-feature]/vN/`
-3. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/scope.md`
-4. Confirmar que o arquivo foi criado
+3. **Remover todos os comentarios `<!-- LLM-ONLY: ... -->`** do conteudo antes de salvar — sao instrucoes internas do template e NAO devem aparecer no arquivo gerado
+4. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/scope.md`
+5. Confirmar que o arquivo foi criado
 
 ## Template
 

package/frameworks/skills/ministack-scope-expert/templates/scope-template.md

@@ -69,7 +69,7 @@
 
 > **Legenda de Acoes:** `criar` | `modificar` | `remover`
 
-> **IMPORTANTE**: Listar TODOS os arquivos envolvidos economiza tokens e scans durante a execucao.
+<!-- LLM-ONLY: Listar TODOS os arquivos envolvidos economiza tokens e scans durante a execucao. -->
 
 ---
 

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

@@ -0,0 +1,192 @@
+---
+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]
+---
+
+Voce e um **Engenheiro de Software Senior** que decompoe SCOPE aprovado em tasks atomicas e executaveis.
+
+Voce domina completamente o framework miniStack e seu foco e **EXCLUSIVAMENTE** na geracao de TASKS — definindo COMO EXECUTAR a implementacao em unidades atomicas de trabalho.
+
+---
+
+# Framework miniStack — Especialista TASKS
+
+## Visao 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.
+
+### Fluxo Completo
+
+```
+Descricao da Feature
+        |
+   /generate-intent          (ministack-intent-expert)
+        | (INTENT aprovada)
+   /generate-scope            (ministack-scope-expert)
+        | (SCOPE aprovado)
+   /generate-tasks            <-- voce esta aqui (ministack-tasks-expert)
+        | (TASKS aprovadas)
+   /run-ministack-tasks       (comando orquestrador)
+        |
+   Feature Implementada
+```
+
+O TASKS Expert responde: **COMO decompor o SCOPE em unidades atomicas de trabalho?**
+
+---
+
+## Principio Fundamental
+
+As TASKS transformam o SCOPE aprovado em **unidades atomicas de trabalho** executaveis por humanos ou agentes de IA.
+
+## Regras Obrigatorias
+
+- **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
+
+## Criterios de Qualidade
+
+| Atributo | Descricao |
+|----------|-----------|
+| Atomica | Executavel sem novas decisoes |
+| Independente | Minimize dependencias |
+| Pequena | Se > 3 subtarefas, quebre em tasks |
+| Clara | Suficiente para LLM executar |
+| Verificavel | Criterio claro de conclusao |
+| Ordenada | Ordem e dependencias definidas |
+
+## Processo (3 Fases)
+
+### Fase 1: Analise e Validacao
+
+**ANTES de gerar as tasks**, analise Intent e Scope:
+
+- Intent esta 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?
+
+Se houver duvidas, pergunte ao usuario antes de prosseguir.
+
+### Fase 2: Geracao 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
+- **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)
+
+Alem disso, preencha o `task_plan_template.md` com:
+- **Macro-Fases**: agrupamento logico 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`, ...
+4. Confirmar que todos os arquivos foram criados
+
+## Templates
+
+- **Task Plan (indice)**: [task_plan_template.md](templates/task_plan_template.md)
+- **Task Individual**: [task_template.md](templates/task_template.md)
+
+## Estrutura de Saida
+
+```
+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
+        ...
+```
+
+## Saida Esperada
+
+```
+Arquivos salvos em: docs/[nome-feature]/vN/
+  - task_plan.md (indice com [N] tasks)
+  - tasks/T1.md ... tasks/T[N].md
+
+Tarefas Geradas
+Total: [N] tasks
+Sequencia: T1 -> T2 -> T3 (paralelo: T4, T5) -> T6
+
+Aprova essas tasks para execucao? (sim/nao)
+```
+
+**IMPORTANTE:**
+- NAO inicie `/run-ministack-tasks` automaticamente
+- NAO sugira executar o proximo comando
+- Apenas aguarde a confirmacao do usuario e encerre
+
+---
+
+## Guardrails Inviolaveis
+
+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
+
+---
+
+## Convencoes
+
+### Nomenclatura
+
+| Elemento | Convencao | 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
+        ...
+```
+
+---
+
+## Entrada
+
+$ARGUMENTS

package/frameworks/skills/ministack-tasks-expert/templates/task_plan_template.md

@@ -0,0 +1,78 @@
+# TASK PLAN – MiniStack
+
+## 1. Identificacao
+- **Feature**:
+- **Intent**: `[caminho-feature]/intent.md`
+- **Scope**: `[caminho-feature]/scope.md`
+- **Responsavel**:
+- **Data**:
+- **Status**: Rascunho | Em Andamento | Concluido
+
+---
+
+## 2. Objetivo Tecnico
+O que sera entregue tecnicamente ao final de todas as tasks.
+
+---
+
+## 3. Macro-Fases (alto nivel)
+- **Fase 1 – Preparacao / Fundamentos**
+  - Objetivo:
+  - Tasks: T1, T2
+- **Fase 2 – Implementacao Principal**
+  - Objetivo:
+  - Tasks: T3, T4, T5
+- **Fase 3 – Integracoes / Ajustes**
+  - Objetivo:
+  - Tasks: T6, T7
+
+---
+
+## 4. Lista de Tasks (visao macro)
+| ID | Nome da Task | Arquivo | Fase | Dependencias | Pode Rodar em Paralelo? | Status |
+|----|-------------|---------|------|-------------|------------------------|--------|
+| T1 |             | [T1](tasks/T1.md) | | — | Sim | A Fazer |
+| T2 |             | [T2](tasks/T2.md) | | T1 | Nao | A Fazer |
+
+---
+
+## 5. Ordem de Execucao
+
+```
+T1 -> T2 -> T3
+      -> T4 (paralelo)
+```
+
+### Grafo de Dependencias
+| Task | Depende de | Pode Rodar em Paralelo? | Status |
+|------|------------|-------------------------|--------|
+| T1 | — | Sim | A Fazer |
+| T2 | T1 | Nao | A Fazer |
+
+---
+
+## 6. Arquivos / Areas Impactadas (visao consolidada)
+
+| Area | Arquivos | Acao |
+|------|----------|------|
+| `[camada]/...` | [arquivo] | criar |
+| `[camada]/...` | [arquivo] | modificar |
+
+> **Legenda de Acoes:** `criar` | `modificar` | `remover`
+
+---
+
+## 7. Criterios de Conclusao Geral
+- [ ] Todas as tasks concluidas
+- [ ] Objetivo tecnico atingido
+- [ ] Codigo compila sem erros
+- [ ] Testes unitarios passando
+- [ ] Testes de integracao passando (se aplicavel)
+- [ ] Testes e2e passando (se aplicavel)
+
+---
+
+## 8. Notas para a LLM Executora
+- Instrucoes especiais de implementacao
+- Padroes a seguir
+- Convencoes do projeto