@fontdata/ai-harness 2.0.0 → 2.1.0

package/templates/commands/criar-rag.md

@@ -1,25 +0,0 @@
----
-description: Cria um sistema de RAG (SQLite + sqlite-vec) para capturar e reusar aprendizados.
----
-
-# Criação do sistema de RAG
-
-Leia o `SPEC.md`, o `CLAUDE.md` na raiz e o plano mais recente em `docs/plans/`.
-
-Crie um sistema de RAG para este projeto que captura aprendizados em três momentos: ao encerrar um agent, ao encerrar a sessão e ao iniciar um novo prompt.
-
-O sistema deve ter:
-
-1. **SCHEMA DO BANCO** — SQLite com `sqlite-vec`. Tabela `knowledge` com: `id`, `path`, `content`, `embedding`, `category`, `agent`, `created_at`.
-
-2. **SCRIPT DE RESUMO** (`.claude/scripts/summarize.ts`) — Recebe como input o contexto a resumir (transcript de agent ou da sessão inteira). Extrai aprendizados em 4 categorias: bugs resolvidos com causa raiz; decisões de arquitetura e o porquê; padrões adotados pelo time; o que não funcionou e por quê. Salva em `.claude/knowledge/YYYY-MM-DD-agent-slug.md`.
-
-3. **SCRIPT DE EMBEDDING** (`.claude/scripts/embed.ts`) — Lê o `.md` gerado, quebra em chunks de 200-300 tokens, gera embeddings com `all-MiniLM-L6-v2` e faz INSERT no `rag.db` com `agent` e `category`.
-
-4. **SCRIPT DE BUSCA** (`.claude/scripts/search.ts`) — Recebe a pergunta atual e o agent atual, gera o embedding da pergunta, busca os top-3 chunks mais similares, prioriza chunks da mesma categoria do agent ativo e retorna o conteúdo para injetar no contexto.
-
-5. **SUBAGENT STOP HOOK** (async, por agent) — Captura o aprendizado específico do agent que acabou de terminar uma task.
-
-6. **STOP HOOK** (async, por sessão) — Captura o aprendizado da sessão inteira como síntese.
-
-7. **USERPROMPTSUBMIT HOOK** — Busca conhecimento relevante para o prompt atual, prioriza a categoria do agent ativo e injeta os chunks encontrados no contexto.

package/templates/commands/criar-rules.md

@@ -1,31 +0,0 @@
----
-description: Cria rules incondicionais e escopadas por path em .claude/rules/.
----
-
-# Geração de rules baseadas nos agents
-
-Leia os agents em `.claude/agents/`, o `CLAUDE.md` e o `SPEC.md` do projeto.
-
-Para cada domínio coberto pelos agents, crie rules específicas que complementem o system prompt de cada agent.
-
-Crie em `.claude/rules/`:
-
-1. **Rules incondicionais** com restrições que valem para qualquer agent:
-   - `seguranca.md` (o que nunca fazer)
-   - `convencoes-gerais.md` (padrões universais)
-
-2. **Rules escopadas por path** para cada domínio:
-   - `backend/` com paths: `backend/**/*.py`
-   - `frontend/` com paths: `frontend/src/**`
-   - `tests/` com paths: `tests/**`
-
-**Não crie rule de comentários.** `.claude/rules/comentarios.md` é instalado por `/configurar-comentarios`
-(junto com o hook de enforcement e a catraca do legado). Se ele já existir, deixe-o como está; se não
-existir, sugira rodar `/configurar-comentarios` em vez de escrever uma versão paralela. Também não repita
-regra de comentário dentro de `convencoes-gerais.md` — duas fontes divergentes é pior que uma.
-
-Cada rule deve:
-- Ser concisa — máximo 30 linhas
-- Conter apenas o que o agent não descobriria sozinho lendo o código
-- Complementar o system prompt do agent, não repetir o que já está lá
-- Focar em restrições e padrões específicos do domínio — não em comportamento geral

package/templates/commands/criar-skill.md

@@ -1,22 +0,0 @@
----
-description: Sugere e cria skills do projeto em .claude/skills/ para problemas recorrentes.
----
-
-# Criação de Skill
-
-Leia o `CLAUDE.md` e o `SPEC.md` na raiz do projeto.
-
-Crie uma skill para este projeto que resolva um problema **recorrente** que os agents vão ter durante a implementação.
-
-Sugira opções de skills úteis para este projeto específico, com:
-- O que cada skill faria
-- Quando dispararia automaticamente
-- Que tipo de tarefa resolveria sem precisar repetir instruções no prompt
-
-Após minha escolha, crie a skill completa em `.claude/skills/nome-escolhido/SKILL.md`.
-
-A skill deve ter:
-1. Frontmatter com `name` e `description` bem escritos
-2. Instruções claras baseadas nas convenções do `CLAUDE.md`
-3. Exemplos de input e output esperados
-4. Critério de quando **NÃO** usar a skill

package/templates/commands/design-system.md

@@ -1,27 +0,0 @@
----
-description: Cria o agent de design system com skills e rules de conformidade da identidade visual.
----
-
-# Criação do agente de design system
-
-Crie um **agente responsável pelo design system** do projeto. Esse agente deve trabalhar em conjunto, principalmente, com o agente de frontend. Ele deve ter **skills** e **rules** referentes à guarda e à garantia da conformidade da identidade visual do projeto.
-
-Crie o agent em `.claude/agents/`, as skills em `.claude/skills/` e as rules em `.claude/rules/`.
-
-## Origem da identidade visual
-
-A fonte do design system depende de eu ter passado, ou não, uma **URL** em `$ARGUMENTS`:
-
-$ARGUMENTS
-
-- **Se eu informei uma URL** em `$ARGUMENTS`: trate-a como referência externa e rode a instrução da seção **"Extrair identidade visual de uma referência externa"** abaixo, extraindo dela cores, fontes e padrões visuais para replicar no nosso projeto.
-
-- **Se eu NÃO informei nenhuma URL** (`$ARGUMENTS` vazio): **não acesse a internet**. Extraia o design system **já existente no próprio projeto, via código** — varra o código-fonte (CSS/SCSS, tokens de tema, Tailwind/`tailwind.config`, variáveis CSS, bibliotecas de UI, componentes) e consolide cores, tipografia, espaçamentos e demais padrões visuais reais do projeto. Use isso como base do agent, skills e rules.
-
----
-
-### Extrair identidade visual de uma referência externa
-
-**Rode esta seção somente quando eu tiver informado uma URL em `$ARGUMENTS`.**
-
-Acesse o site informado e extraia dele todas as informações de cores, fontes e padrões visuais — principalmente de CSS — para replicar isso no nosso projeto.

package/templates/commands/executar-plan.md

@@ -1,36 +0,0 @@
----
-description: Orquestra a execução do plano com sub-agents em paralelo, fase a fase, com gates e TDD.
----
-
-# Execução do plano com sub-agents
-
-Leia o `SPEC.md` e o `CLAUDE.md` na raiz e o **plano mais recente em `docs/plans/`** (a spec correspondente está em `docs/specs/`). O scaffold está completo e os testes de smoke passam.
-
-Sua função é de **ORQUESTRADOR**. Você não implementa nada diretamente — você lê o plano e delega cada task para sub-agents independentes, respeitando as dependências entre fases. **Sempre relate no chat qual agent está ativo**, principalmente nos gates.
-
-## Regras de orquestração
-
-1. **LEIA O PLANO COMPLETO** — Antes de qualquer delegação, leia todas as fases, tasks, inputs, outputs e testes críticos. Monte internamente o grafo de dependências.
-
-2. **EXECUTE FASE POR FASE** — Nunca inicie uma fase antes que todas as tasks da fase anterior estejam concluídas e os testes passando.
-
-3. **DENTRO DE CADA FASE — PARALELO** — Para cada fase, dispare sub-agents simultâneos para todas as tasks marcadas como paralelas. Cada sub-agent recebe: o contexto da task (Input, Output, Testes críticos), a instrução de escrever os testes ANTES de implementar, a instrução de seguir as convenções do `CLAUDE.md` e a instrução de marcar o checkbox da task no plano ao concluir.
-
-4. **INSTRUÇÃO PARA CADA SUB-AGENT** — Ao delegar, passe exatamente este contexto:
-
-   > "Você é responsável pela [NOME DA TASK] do plano em `docs/plans/...`.
-   > Input: [INPUT DA TASK]
-   > Output esperado: [OUTPUT DA TASK]
-   > Testes críticos:
-   > - [TESTE 1]
-   > - [TESTE 2]
-   > Siga as convenções do `CLAUDE.md`. Escreva os testes primeiro (RED), confirme que falham, implemente o mínimo para passar (GREEN), e marque o checkbox no plano ao concluir.
-   > Comentários: o padrão é não comentar (bloco <= 3 linhas, docstring pública <= 5, cabeçalho de arquivo proibido). **Não** escreva no código o número da task, a fase, o plano, a data nem o que você investigou — isso vai na mensagem de commit. Ver `.claude/rules/comentarios.md`."
-
-5. **GATE ENTRE FASES** — Após todos os sub-agents de uma fase reportarem conclusão, execute o critério de gate da fase. Só avance se o gate passar. Se falhar, sinalize o erro e aguarde instrução — não tente corrigir automaticamente.
-
-6. **RELATÓRIO DE PROGRESSO** — Após cada fase, exiba: tasks concluídas e testes passando, tasks que bloquearam e o motivo, gate da fase (passou/falhou) e a próxima fase.
-
-7. **RESTRIÇÕES** — Não modifique `SPEC.md`, `CLAUDE.md` ou os planos. Não implemente nada fora do escopo do plano. Não avance se um gate falhar. Se uma task bloquear por mais de 2 tentativas, sinalize e aguarde — não invente solução alternativa.
-
-Inicie lendo o plano e apresentando o plano de execução completo antes de disparar qualquer sub-agent. Aguarde minha confirmação para começar.

package/templates/commands/gerar-claude-md.md

@@ -1,66 +0,0 @@
----
-description: Gera o CLAUDE.md (context file) na raiz a partir do SPEC.md.
----
-
-# Geração do CLAUDE.md
-
-Leia o `SPEC.md` na raiz do projeto e gere o **Context File** do projeto, salvando como `CLAUDE.md` **na raiz**.
-
-Gere o arquivo exatamente nesta estrutura, sem adicionar nem remover seções:
-
-```markdown
-# [NOME DO PROJETO]
-> [1 frase: o que o sistema faz e qual problema resolve]
-
-## Stack
-| Camada | Tecnologia |
-|--------|------------|
-[preencha com a stack do SPEC]
-
-## Estrutura de pastas
-[árvore de pastas do projeto com comentário em cada pasta]
-
-## Como rodar localmente
-[comandos exatos de instalação e execução, separados por backend e frontend]
-
-## Padrões de código
-- Nomenclatura de arquivos: [regra]
-- Nomenclatura de variáveis e funções: [regra]
-- Estrutura de endpoints: [regra]
-- Estrutura de componentes: [regra]
-- Tipagem: [regra]
-
-## Comentários em código
-[Se o projeto já tiver o bloco "Comentários em código" no CLAUDE.md atual, copie-o INTEGRALMENTE aqui,
-incluindo a linha `@.claude/rules/comentarios.md`. Se não tiver, escreva apenas:
-"Rode `/configurar-comentarios` para instalar o padrão de comentários deste projeto."]
-
-## TDD
-- Framework backend: [nome]
-- Framework frontend: [nome]
-- Onde ficam os testes: [caminho]
-- Regra: [cobertura mínima exigida]
-- Testes críticos deste projeto:
-  - [ ] [teste 1 extraído do SPEC]
-  - [ ] [teste 2 extraído do SPEC]
-  - [ ] [teste 3 extraído do SPEC]
-
-## Nunca fazer
-- Nunca [proibição específica deste projeto]
-- Nunca [proibição específica deste projeto]
-- Nunca [proibição específica deste projeto]
-- Nunca [proibição específica deste projeto]
-- Nunca [proibição específica deste projeto]
-
-## Decisões em aberto
-- [ ] [decisão 1 não resolvida no SPEC]
-- [ ] [decisão 2 não resolvida no SPEC]
-```
-
-Preencha apenas os campos entre colchetes. Não invente nada que não esteja no SPEC. Se uma informação não existir no SPEC, escreva "a definir".
-
-> Preserve, se possível, a seção de filosofia/fluxo do harness já presente no `CLAUDE.md` atual (orquestração, TDD, gates, modelo de arquivos `docs/specs` e `docs/plans`).
-
-> **Nunca descarte** o bloco "Comentários em código" nem a linha `@.claude/rules/comentarios.md` que já
-> existirem no `CLAUDE.md` atual — eles são instalados por `/configurar-comentarios` e regenerar o arquivo
-> sem eles desliga o padrão de comentários do projeto inteiro.

package/templates/commands/gerar-ignore.md

@@ -1,37 +0,0 @@
----
-description: Gera .claudeignore e .gitignore conforme a stack do projeto.
----
-
-# Geração de arquivos de exclusão de contexto
-
-Analise a estrutura do projeto e gere os arquivos de exclusão de contexto adequados para o Claude Code.
-
-Se a stack não estiver clara, leia o `CLAUDE.md`/`SPEC.md` ou me pergunte antes.
-
-Stack do projeto: $ARGUMENTS
-
-Gere o arquivo `.claudeignore` com estas seções obrigatórias, nesta ordem:
-
-```
-# Dependências
-[liste os diretórios de dependências da stack]
-
-# Build e arquivos gerados
-[liste os diretórios de build e arquivos gerados]
-
-# Segredos e variáveis de ambiente
-[liste todos os padrões de arquivos com credenciais]
-
-# Banco de dados local
-[liste arquivos de banco de dados de desenvolvimento]
-
-# Uploads e mídia
-[liste diretórios de arquivos enviados pelo usuário]
-
-# Cache e logs
-[liste diretórios de cache e arquivos de log]
-```
-
-Gere também um `.gitignore` reforçado cobrindo as mesmas categorias acima.
-
-Regra: seja conservador. Em caso de dúvida, exclua. Nunca exclua arquivos de código fonte, testes ou documentação.

package/templates/commands/gerar-spec.md

@@ -1,33 +0,0 @@
----
-description: Conduz uma entrevista de requisitos e gera o SPEC.md principal na raiz.
----
-
-# Geração do SPEC.md principal
-
-Você vai me ajudar a criar o **SPEC.md principal** do projeto — a definição completa e única, gravada na **raiz** do projeto (`SPEC.md`). Vale tanto para projeto novo quanto existente. Não quero escrever o spec manualmente — conduza uma entrevista de requisitos comigo.
-
-## Fase 1 — Entrevista
-
-Faça perguntas para entender o projeto a fundo. **Uma pergunta por vez.** Cubra obrigatoriamente: problema real que resolve, quem são os usuários, funcionalidades essenciais vs. nice-to-have, módulos e suas responsabilidades, stack técnica, constraints e o que está fora do escopo. Quando tiver informação suficiente, avise que está pronto para gerar o SPEC.
-
-## Fase 2 — Geração do SPEC.md
-
-Quando eu confirmar, gere o arquivo `SPEC.md` **na raiz do projeto** com esta estrutura, sem adicionar nem remover seções:
-
-```markdown
-# SPEC.md
-
-## Problema
-## Usuários
-## Funcionalidades
-### Essenciais
-### Fora do escopo
-## Módulos
-## Stack
-## Constraints técnicas
-## Critérios de aceitação
-```
-
-Não invente informações que não surgiram na entrevista. Se algo ficou ambíguo, registre como decisão em aberto.
-
-> Observação: este SPEC é a definição **principal** do projeto. O "start" inicial e cada nova tarefa geram specs **complementares** em `docs/specs/` (via `/nova-tarefa`).

package/templates/commands/harness.md

@@ -1,34 +0,0 @@
----
-description: Comando-mestre — conduz a sequência de setup do harness em ordem, validando entre etapas.
----
-
-# /harness — setup guiado do projeto
-
-Conduza a configuração completa do harness deste projeto executando as etapas **em ordem**, parando para validar comigo antes de avançar de uma para a outra. Em cada etapa, use o slash command correspondente como referência de instrução.
-
-Contexto inicial (opcional): $ARGUMENTS
-
-## Antes de começar: novo ou existente?
-
-Pergunte se este é um **projeto novo** ou um **projeto existente** (se eu não tiver dito).
-
-- **Projeto novo** → execute todas as 8 etapas.
-- **Projeto existente** → **pule as etapas 1, 5, 6 e 8** (validar ideia, gerar plano do start, scaffold e executar o plano). Execute apenas as etapas **2, 3, 4 e 7** — documentar o projeto (SPEC/CLAUDE/ignores) e montar o harness sobre o código que já existe. Nas etapas 2 e 3, leve em conta o código atual ao gerar o SPEC.md e o CLAUDE.md.
-
-## Sequência
-
-1. **Validar ideia** (`/validar-ideia`) — confirme que o escopo cabe em ~4h com multi-agents. Se o veredito for AJUSTAR ou REPROVAR, pare e ajuste comigo antes de seguir.
-2. **Gerar SPEC principal** (`/gerar-spec`) — entrevista de requisitos → `SPEC.md` na raiz. Valide comigo.
-3. **Gerar CLAUDE.md** (`/gerar-claude-md`) — context file na raiz a partir do SPEC.
-4. **Gerar ignores** (`/gerar-ignore`) — `.claudeignore` e `.gitignore`.
-5. **Gerar plano do start** (`/nova-tarefa`) — derive o start inicial do `SPEC.md`: spec complementar em `docs/specs/` + plano em `docs/plans/`. Valide comigo. Não dispare o orquestrador ainda — o scaffold vem antes.
-6. **Scaffold** (`/scaffold`) — estrutura inicial, rota `/health` e testes de smoke. Confirme que o servidor sobe.
-7. **Montar o harness** — nesta ordem: `/configurar-comentarios` (**primeiro**: instala o padrão de comentários, o hook e a catraca, para que os agents já nasçam com a regra no system prompt), `/criar-skill` (skills antes dos agents, que dependem delas), depois `/criar-agents`, `/criar-code-reviewer`, `/criar-rules`, `/criar-hooks` e, por fim, `/configurar-orquestrador` (configura o Claude Code como orquestrador dos agents) — sugira pular o que não fizer sentido.
-8. **Executar o plano** (`/executar-plan`) — só depois da minha confirmação, orquestre a implementação com sub-agents.
-
-## Regras
-
-- **Não avance de etapa sem minha confirmação explícita.**
-- Sempre relate qual etapa/agent está ativo.
-- Respeite TDD e os gates entre fases.
-- Se uma etapa não se aplicar a este projeto, proponha pulá-la e siga só com meu OK.

package/templates/commands/nova-tarefa.md

@@ -1,60 +0,0 @@
----
-description: Gera a spec complementar + o plano de implementação em docs/specs e docs/plans (start inicial ou nova tarefa) e, se confirmado, dispara o orquestrador.
----
-
-# Planejamento de tarefa (start inicial ou nova tarefa)
-
-Este comando transforma um recorte de trabalho em **spec complementar + plano de implementação** prontos para a orquestração com sub-agents. Serve tanto para o **start inicial** do projeto quanto para **cada nova tarefa** do dia a dia.
-
-Tarefa / recorte: $ARGUMENTS
-
-## 1. Defina o recorte
-
-Antes de tudo, leia o `SPEC.md` principal e o `CLAUDE.md` na raiz (e a spec/plano mais recentes em `docs/`, se já existirem).
-
-- **Start inicial** (não há nada em `docs/plans/` ainda, ou eu pedi "start" / "primeira fatia"): derive o recorte direto do `SPEC.md` — a primeira fatia vertical a construir. **Não precisa entrevista**, mas confirme comigo o recorte escolhido antes de gerar.
-- **Nova tarefa**: faça de **2 a 3 perguntas** (uma por vez, mais se necessário) para entender a fundo o que deve ser feito. Ao final, resuma o que foi **entendido e planejado** e aguarde minha aprovação.
-
-**Nunca grave `PLAN.md` na raiz.** Use sempre a convenção de pastas do projeto.
-
-## 2. Spec complementar
-
-Quando eu aprovar o recorte, grave a spec em `docs/specs/AAAA-MM-DD-breve-descricao.md` (data atual + descrição curta derivada do recorte). Descreva de forma enxuta o que será implementado e os critérios de aceite. Valide comigo.
-
-## 3. Plano de implementação
-
-Grave o plano em `docs/plans/AAAA-MM-DD-breve-descricao.md` (use o **mesmo nome** da spec complementar), com esta estrutura, sem adicionar nem remover seções:
-
-```markdown
-# Plano — [breve descrição]
-
-## Sprint [n] — [critério de conclusão em 1 frase verificável]
-
-### Fase [n] — [nome]
-> Dependências: [fases anteriores ou "nenhuma"]
-> Paralelismo: [quais tasks desta fase rodam em paralelo]
-
-#### Task [n.n] — [nome]
-- Agent: [papel do agent responsável]
-- Input: [o que precisa estar pronto para iniciar]
-- Output: [entregável específico com assinatura ou estrutura]
-- Testes críticos:
-  - [ ] [comportamento esperado — input válido]
-  - [ ] [caso de erro tratado]
-```
-
-Regras obrigatórias:
-
-1. Toda task tem pelo menos 2 testes críticos definidos antes de qualquer código — os testes são escritos primeiro.
-2. Nenhum output pode ser vago — descreva o arquivo, função ou estrutura exata que será entregue.
-3. Tasks na mesma fase são genuinamente independentes — não tocam os mesmos arquivos nem dependem uma da outra.
-4. A ordem das fases respeita dependências reais — nenhuma task de integração antes das tasks base existirem.
-5. Use os nomes de módulos definidos no `SPEC.md` — sem criar nomenclatura nova.
-6. Cada fase tem um critério de conclusão verificável por um comando de terminal.
-
-## 4. Validação e execução
-
-Ao terminar, informe o caminho dos dois arquivos gravados e liste quais tasks rodam em paralelo e quantos agents serão necessários no total. Valide comigo se é isto que desejo.
-
-- **Start inicial (fluxo `/harness`):** o próximo passo normalmente é `/scaffold` antes de implementar — **não dispare o orquestrador automaticamente**, aguarde minha instrução.
-- **Nova tarefa:** se eu confirmar, **chame o orquestrador** (`/executar-plan`) para realizar todo o plano aprovado, com sub-agents em paralelo e TDD obrigatório.

package/templates/commands/resolver-bug.md

@@ -1,25 +0,0 @@
----
-description: Investiga, planeja em docs/bugs e corrige um bug passo a passo, com aprovação.
----
-
-# Resolver bug
-
-Trate o bug descrito abaixo (se eu não tiver descrito, peça os detalhes antes de começar).
-
-Bug: $ARGUMENTS
-
-Faça o seguinte, **sem pular nenhuma etapa** e pedindo minha confirmação nos momentos críticos:
-
-1. **Investigue** onde está o bug e o que ele afeta.
-2. **Monte um plano de conserto** dividido em etapas e grave-o em `docs/bugs/<yyyy-mm-dd>-<slug>.md`, onde `<yyyy-mm-dd>` é a data atual e `<slug>` é uma descrição resumida do bug.
-3. **Peça minha aprovação** antes de mexer em qualquer coisa.
-4. **Execute o conserto passo a passo**, verificando se cada etapa funcionou.
-5. **Revise a qualidade** do que foi feito ao final de cada etapa.
-6. **Sugira uma regra nova** no projeto (`.claude/rules/`) para esse bug nunca voltar.
-
-## Bug ou investigação?
-
-Só use `docs/bugs/` se a apuração fechar os três: sintoma reproduzível, causa-raiz identificada e
-correção a aplicar. Se concluir que não há defeito — é auditoria, paridade com legado, medição ou
-levantamento — grave em `docs/investigacoes/<yyyy-mm-dd>-<slug>.md` e me avise, em vez de registrar
-como bug.

package/templates/commands/review-por-task.md

@@ -1,16 +0,0 @@
----
-description: Enforça o fluxo implementação → review isolado → correção em cada task da fase.
----
-
-# Orquestrador com review obrigatório por task
-
-Leia o **plano mais recente em `docs/plans/`** e execute a fase indicada (por padrão a próxima fase pendente) seguindo este fluxo **obrigatório** para cada task:
-
-1. Despache o agent de implementação correto (ex: `@backend-agent`) para implementar a task.
-2. Aguarde o retorno confirmando conclusão.
-3. Despache o `@code-reviewer` para revisar o que foi implementado — **em contexto isolado**.
-4. Aguarde o veredicto do reviewer.
-5. Se houver item **BLOQUEANTE**: corrija antes de avançar para a próxima task.
-6. Se não houver bloqueantes: avance.
-
-Não pule o step de review em nenhuma task. O orquestrador despacha cada agent separadamente — o reviewer nunca vê a conversa de implementação, só o output final. É o contexto mais limpo possível. **Relate no chat qual agent está ativo a cada passo.**

package/templates/commands/scaffold.md

@@ -1,25 +0,0 @@
----
-description: Cria a estrutura inicial do projeto (pastas, configs, rota /health, testes de smoke).
----
-
-# Geração de Scaffold
-
-Leia o `SPEC.md` e o `CLAUDE.md` na raiz do projeto, e o plano mais recente em `docs/plans/`.
-
-Gere o scaffold completo do projeto seguindo estas regras:
-
-1. **ESTRUTURA DE PASTAS** — Crie todos os diretórios e subdiretórios definidos na seção de estrutura do `CLAUDE.md`. Adicione um `README.md` de uma linha em cada pasta descrevendo sua responsabilidade.
-
-2. **ARQUIVOS DE CONFIGURAÇÃO** — Crie todos os arquivos de configuração da stack: `requirements.txt`, `package.json`, `tsconfig.json`, `tailwind.config.js`, `.env.example`, `.gitignore` e qualquer outro necessário. Instale as dependências após criar os arquivos.
-
-3. **PONTO DE ENTRADA MÍNIMO** — Crie um `main.py` (ou `index.ts`, `server.js` — conforme a stack) com apenas o servidor inicializado e uma rota `/health` que retorna status 200. Nenhuma lógica de negócio.
-
-4. **SETUP DE TESTES** — Configure o framework de testes definido no `CLAUDE.md`: crie a pasta de testes espelhando a estrutura do projeto e um teste de smoke que verifica se o servidor sobe.
-
-5. **O QUE NÃO FAZER**
-   - Não implemente nenhuma lógica de negócio
-   - Não crie modelos de dados
-   - Não crie endpoints funcionais além de `/health`
-   - Não crie componentes de UI além do layout base
-
-6. **CRITÉRIO DE CONCLUSÃO** — Ao terminar, execute os comandos de verificação definidos no `CLAUDE.md` e confirme que o servidor sobe sem erros antes de encerrar.

package/templates/commands/validar-commands.md

@@ -1,24 +0,0 @@
----
-description: Audita a pasta .claude — valida os modelos dos agents, aponta commands redundantes/pouco úteis e sugere novos commands úteis.
----
-
-# Auditoria do harness (.claude)
-
-Analise a pasta `.claude` do projeto (commands, agents, skills, rules, hooks) e produza uma auditoria em três frentes. **Explique o motivo** de cada avaliação — nada de veredito sem justificativa.
-
-## 1. Agents — modelo adequado
-
-Para cada agent, diga se o **model** escolhido (Haiku/Sonnet/Opus) está correto para o trabalho dele. Aponte **sub** ou **superdimensionamento** (ex.: Opus para uma task mecânica, Haiku para arquitetura) e recomende o ajuste.
-
-## 2. Commands — uso e redundância
-
-- Diga quais slash commands tendem a ser **mais usados** neste projeto e quais são **pouco úteis** no contexto dele.
-- Aponte **sobreposições de escopo** entre comandos — candidatos a remoção ou fusão.
-
-## 3. Novos commands sugeridos
-
-Sugira **novos slash commands** úteis para este projeto específico. Para cada um: o que faria, quando seria usado e qual **dor recorrente** ele eliminaria.
-
-## Fechamento
-
-Consolide tudo em quatro listas — **manter / ajustar / remover / criar** — e **pergunte o que devo aplicar** antes de mexer em qualquer arquivo.

package/templates/commands/validar-ideia.md

@@ -1,36 +0,0 @@
----
-description: Valida se a ideia do projeto cabe na janela de tempo com multi-agents (entrevista + diagnóstico honesto + veredito acionável).
----
-
-# Validação de ideia de projeto
-
-Você é um **arquiteto de software sênior**, especialista em dimensionar escopo de projetos construídos com Claude Code e orquestração de multi-agents. Sua função é dar um diagnóstico **honesto e acionável** sobre se a ideia abaixo cabe na janela de tempo disponível — sem otimismo de wishful thinking. Prefira errar para o lado pessimista.
-
-## Contexto
-
-- **Ideia:** $ARGUMENTS
-- **Janela de tempo:** se eu não informei explicitamente em `$ARGUMENTS`, assuma **~4 horas** (formato imersão) e **diga que assumiu isso**.
-- **Modo de execução:** TDD obrigatório + sub-agents especializados implementando módulos independentes em paralelo (o harness deste projeto).
-
-Se eu **não descrevi a ideia** ou descrevi de forma vaga demais para avaliar, **pare e faça as perguntas mínimas** necessárias — uma pergunta por vez — antes de qualquer avaliação. Não avalie no escuro.
-
-## Como avaliar
-
-Percorra os critérios abaixo. Para cada um, dê um veredito curto com a **evidência ou o risco concreto** — nada de respostas genéricas.
-
-1. **Decomposição em módulos** — Quebre a ideia em 2 a 4 módulos que agents separados implementariam de forma **genuinamente independente** (não tocam os mesmos arquivos, não dependem um do outro para começar). Se não der para quebrar assim, isso já é um sinal de alerta sobre o escopo.
-2. **Fatia vertical entregável** — Descreva o menor caminho ponta-a-ponta que estaria **funcionando** ao fim da janela, mesmo que simples ou feio. Se não existe uma fatia demonstrável, o escopo está errado.
-3. **Complexidade oculta / risco de explosão** — Aponte dependências que costumam estourar o tempo: autenticação de terceiros, pagamentos, uploads, real-time/websockets, integrações externas, processamento pesado, mobile nativo, infra/deploy. Para cada uma presente, diga como **cortar, mockar ou adiar** no dia.
-4. **Stack** — A stack está clara e é dominada? Se precisa ser decidida antes de começar, sinalize como pré-requisito bloqueante.
-5. **Testabilidade (TDD)** — Para pelo menos 2 módulos, quais seriam os **testes críticos** (um de input válido + um de caso de erro) escritos ANTES do código? Se o comportamento essencial é difícil de testar, explique por quê.
-6. **Estimativa realista** — Dê uma estimativa grosseira de esforço por módulo, some e compare com a janela. Seja pessimista onde houver incerteza.
-
-## Veredito
-
-Feche com **um** dos três, justificando em até 3 linhas com base na análise acima:
-
-- ✅ **APROVADO** — cabe na janela. Pode seguir para `/gerar-spec`. Liste em 1 linha os módulos e a fatia vertical alvo.
-- ✂️ **AJUSTAR** — boa ideia, grande demais. **Reescreva a ideia já recortada em 2–3 frases**, preservando a essência e o "uau", pronta para virar SPEC. Diga explicitamente o que ficou de fora (backlog para depois).
-- ❌ **REPROVAR** — inviável mesmo recortada na janela dada. Explique o porquê e **proponha uma ideia alternativa no mesmo domínio** que caiba, mantendo a mesma estrutura de módulos.
-
-Responda em português do Brasil.