Pular para conteúdo

workflow /build — a produção da fila

Este workflow é um comando, não um .js. /build sem parâmetro pega a lista da coluna To build e vira um workflow dinâmico: spawna um subagente por card, em paralelo, e cada um atualiza o próprio card no fim. Com um card (/build DEV-123), roda um só — mesma lógica, lote de 1.

Trabalha a fila aprovada. Antes de qualquer linha, três coisas na ordem — e essa ordem é o que evita retrabalho.

Diagrama do comando /build: lê a coluna To build, fixa o contrato de interface, implementa com a skill que a slice pede, revisa o próprio diff e abre PR draft movendo o pai pra Review

Clique no diagrama para a versão interativa (build.html): tema claro/escuro, pan/zoom, busca, três views guiadas e export PNG/SVG. A fonte é o JSON (docs/agents/build.architecture.json), nunca o .svg.

O conteúdo do card decide a skill

O comando não tem "uma skill". Ele lê o card e escolhe a da cesta do agente-build que aquele card pede:

Antes de codar Por quê
CLAUDE.md do app cada app do monorepo tem convenção própria (DDD, camadas, nomes)
régua criticidade fluxo crítico tem teste obrigatório e piso Sonnet
contrato de interface pública é o que permite testar e implementar em paralelo sem divergir
A slice é… Skill
implementação planejada to-build
a suíte da slice, isolada e paralela test-writer
tela/componente ou ajuste de UI frontend-builder
polir/endurecer/animar impeccable (lentes de produção)
documentação do que entrou to-wiki
ticket pequeno e autocontido backlog-scout (EXECUÇÃO, em worktree)

Antes do PR, o build roda review no próprio diff (Standards + Spec) e a suíte de verdade. Isso não substitui o gate de merge — quem decide se entra é o monitor com pr-guardian; a revisão própria existe pra não gastar o gate com o que o build mesmo pegaria: teste que não roda, any novo, escopo que cresceu sem PRD.

PR sempre draft. Ele nunca mergeia e nunca faz deploy. Subtasks andam To build → Spec → Building; o pai vai pra Review quando o PR abre (Monitoring é pós-merge — quem lê aquela coluna é a rotina ci-monitoring).

O grafo de agentes

O desenho acima é o sistema; este é o grafo de agentes — quantas chamadas rodam e a que custo.

Grafo de agentes do comando /build: um subagente por card da coluna To build, com o degrau de modelo escolhido pelo risco do card, e os dois destinos possíveis

O degrau de modelo sai do card, não do comando (régua skill-modelo-effort): risco sobe (crítico · P0/P1 · L/XL) → Opus; trabalho mecânico e volumoso → Haiku; o meio é o dia a dia → Sonnet.

Fan-out sem barreira: nenhum card espera o outro, porque nenhum depende do resultado do outro. E não existe consolidador de estado — o board é o estado, e quem atualiza o card é o subagente que o trabalhou. O relato do fim é leitura, não decisão.

Dois destinos, sempre

Desfecho Vai pra
fechou Review
não fechou fica em Blocked, com o motivo escrito no card

Resultado parcial declarado vale mais que conclusão inventada — e é o que permite alguém desbloquear em vez de refazer o trabalho do zero.

Regras que valem no run inteiro

  • Produção é READ-ONLY. Ler Sentry/PostHog/Railway/Supabase e o código, sim; mutar env, fila, banco, deploy ou prompt, nunca.
  • Nunca chamar API de parceiro pra testar — em débito, uma chamada de teste pode gerar cobrança real. Nunca mandar mensagem pela Ju ou pelo Abel — chega no WhatsApp de cliente real.
  • A skill é a autoridade. Onde o comando e o SKILL.md discordarem, manda o SKILL.md — senão o comando vira uma segunda verdade sobre o método.

Todo workflow tem os dois desenhos — o do sistema (quais peças existem e quem é dona de quê) e o do grafo de agentes (quantas chamadas rodam, em que padrão, a que custo). É a regra da skill to-wiki.