joris887/exosuit

---

build

Construa um projeto a partir de uma descrição em linguagem natural. Orquestra configuração, planejamento e implementação automaticamente.

Toda saída voltada ao usuário DEVE usar português claro. Sem jargões: sem "TDD", "sprint", "PR", "squash merge", "CI/CD", "ORM", "middleware". Se um termo técnico for inevitável, explique-o entre parênteses.

Argumentos

$ARGUMENTS — uma descrição em português claro do que construir (ex.: "um aplicativo de gerenciamento de tarefas com contas de usuário e datas de vencimento").

Fase 0: Verificar Configuração

Leia o perfil atual do CLAUDE.md. Se não for lean, anote o perfil, mas prossiga — /build sempre usa execução estilo lean internamente, independentemente do perfil do projeto.

Fase 1: Decompor

Mostre: "Planejando o que precisa ser construído..."

Internamente, decomponha a descrição em histórias ordenadas usando a lógica /ideate:

1. Identifique as entidades e funcionalidades centrais descritas
2. Divida em etapas de implementação ordenadas por dependência
3. Classifique cada uma como funcionalidade, infraestrutura ou teste
4. Dimensione cada etapa (procure etapas que toquem ≤5 arquivos)

NÃO mostre nada disso ao usuário. Sem tipos de história, sem SPIDR, sem rótulos de prioridade, sem terminologia de metodologia. Mantenha a decomposição interna.

Crie um plano interno simples (não mostrado ao usuário):

steps:
  - summary: "Configurar as tabelas do banco de dados"
    type: infrastructure
    files: [...]
  - summary: "Construir os endpoints da API"
    type: feature
    files: [...]
  - summary: "Adicionar autenticação de usuário"
    type: feature
    files: [...]
  - summary: "Escrever testes"
    type: testing
    files: [...]

Captura de Descoberta (Retroativa)

Capture silenciosamente o contexto da descoberta para futuras revisões de fase — o usuário NÃO vê isso:

1. Infira o arquétipo a partir da descrição (classifique entre os 10 arquétipos em .claude/skills/discover/references/scale-guide.md)
2. Defina a escala como Quick Build
3. Gere automaticamente um docs/reference/DECISION_LOG.md mínimo (copie o template de .claude/skills/discover/assets/decision-log.md), registrando todas as decisões técnicas com confiança: ASSUMIDA
4. Inclua Histórias de Transição de Fase (E0N-REVIEW: variante rápida de 3 histórias — E0N-001, E0N-004, E0N-006) como a última etapa interna
5. Salve a classificação em vision/classification.md

Isso garante que os usuários de /build recebam o ciclo de revisão sem atrito inicial.

Fase 2: Executar

Para cada etapa na ordem de dependência:

1. Mostre o progresso em português claro:

   • "Configurando o banco de dados..." / "Construindo a API..." / "Adicionando login do usuário..." / "Escrevendo testes para garantir que tudo funcione..."
   • Use uma linguagem que o usuário entenda. Nunca: "Executando história E01-003 (tipo: feature, tamanho: PADRÃO)"

2. Execute usando comportamento Lean de ciclo de história:

   • Planeje (leve — sem pontuação de confiança)
   • Construa com TDD quando não trivial (execute testes, não explique a metodologia TDD)
   • Verifique se os testes passam
   • Faça commit com formato convencional (não explique as convenções de commit)

3. Tome todas as decisões técnicas silenciosamente:

   • Escolhas de framework/biblioteca: escolha a melhor opção, documente em um resumo final
   • Arquitetura: siga padrões padrão para o stack detectado
   • Estrutura de arquivos: siga as convenções existentes do projeto ou os padrões do stack detectado
   • Pare apenas para ambiguidades genuínas de produto: "O design poderia seguir dois caminhos: [A] ou [B]. Qual você prefere?"
   • Nunca pare para: escolha de banco de dados, estilo de API, nomeação de arquivos, framework de teste, estrutura de pastas

4. Lide com falhas graciosamente:

   • Se uma etapa falhar após 2 tentativas, pule-a com uma nota: "Não consegui fazer [X] funcionar automaticamente. Aqui está o que precisa ser feito manualmente: [descrição]"
   • Continue com as etapas restantes — não bloqueie toda a construção

Fase 3: Concluir

3A. Iniciar e Verificar (se aplicável)

Verifique os Comandos em CLAUDE.md para um comando dev:. Se um estiver configurado:

1. Mostre: "Iniciando seu projeto..."
2. Execute o comando dev em segundo plano usando Bash com run_in_background: true
3. Aguarde alguns segundos. Leia qualquer saída — procure por URLs, portas, caminhos de arquivo ou mensagens de status.
4. Mostre o que o comando produzir. Se gerar uma URL, destaque-a. Se for uma CLI, mostre a saída de ajuda. Se iniciar um servidor, mostre o endereço.
5. Pergunte: "Dê uma olhada e me diga o que achou!"
6. Aguarde feedback. Positivo → prossiga para o relatório de conclusão. Problemas → corrija e execute novamente.

Se nenhum comando dev estiver configurado (bibliotecas, pacotes, pipelines, etc.) → pule esta etapa. Os testes já verificaram a construção.

NÃO assuma localhost ou qualquer URL específica. Leia a saída real do comando. Projetos diferentes produzem resultados diferentes.

3B. Relatório de Conclusão

Mostre um relatório de conclusão em português claro:

## Tudo Pronto!

### O Que Foi Construído
- [Funcionalidade 1]: [descrição em português claro do que faz]
- [Funcionalidade 2]: [descrição]
- ...

### Arquivos Criados/Modificados
- `src/models/user.ts` — Modelo de dados do usuário
- `src/api/auth.ts` — Endpoints de login e registro
- ...

### Testes
- [N] testes escritos, todos passando

### Decisões Técnicas Tomadas
- **Banco de Dados:** PostgreSQL (confiável, gratuito, funciona bem com [framework])
- **Autenticação:** [abordagem escolhida] — [motivo de uma linha]
- ...

### Experimente
[Se o comando dev foi executado: "Seu projeto está em execução — veja acima"]
[Se o comando dev existe, mas não foi iniciado: "Execute `[comando dev]` para iniciar"]
[Se não houver comando dev: omita esta seção]

### Próximos Passos
- [Sugestão 1, ex.: "Adicione um sistema de pagamento com /build 'Integração de pagamento Stripe'"]
- [Sugestão 2]

Regras

• Apenas português claro — toda mensagem voltada ao usuário deve ser compreensível por alguém que nunca programou
• Decisões técnicas silenciosas — escolha boas opções padrão, documente no relatório de conclusão, nunca pergunte
• Pare apenas para perguntas de produto — "Os usuários devem poder excluir sua conta?" é válido. "REST ou GraphQL?" não é.
• Os ganchos de segurança ainda são executados — detecção de segredos, proteção de git e execução de testes acontecem de forma invisível
• Execução enxuta — sem despacho de agente de qualidade, sem especificações de sprint, sem retrospectivas, sem geração de documentação além do necessário para funcionar
• Pule graciosamente — etapas com falha são anotadas, não fatais. A construção continua.
• Sessão única — a primeira versão do /build é concluída em uma única sessão. Construções multissessão são trabalho futuro.