Workflows

Um workflow é a orquestração: quais subagentes rodam, em que ordem, com que modelo. Aqui existem duas formas dela, e a diferença é quem controla o fluxo:

Forma	Onde vive	O fluxo é decidido por
script	.claude/workflows/*.js	código — fases, paralelismo, teto e modelo carimbados no .js
comando	.claude/commands/*.md	a coluna do board — sem parâmetro, o comando pega a fila e spawna um subagente por card

O comando sem parâmetro É um workflow dinâmico. Não existe .js intermediário: a lista da coluna é o fan-out, o board é o estado compartilhado, e quem atualiza o card é o subagente que o trabalhou. É por isso que o workflow reach.js deixou de existir — ele fazia à mão o que /reach faz por construção.

É aqui que a documentação completa de cada um vive, com diagrama; a página de rotinas diz apenas quem dispara o quê (e só duas coisas disparam sozinhas).

Os workflows de comando — um por agente, um por coluna

Cada agente tem um comando, que trabalha a coluna dele:

Workflow	Coluna	Faz	Leva pra
scout	To scout	a descrição decide a skill: Bug → causa raiz · sem Bug → PRD + fatias · pergunta → grafo	Reach
reach	Reach	grilling (co-create, ou auto = pesquisa) → to-prd → to-issues	To build (interativo)
build	To build	contrato → a skill da slice → review no próprio diff → PR draft	Review
monitor	Monitoring	soak dirigido da entrega; 14 dias limpos fecham	Done

Os workflows de script

• scout-log — monitoração de produção em 6 fases: varre as fontes de log, organiza por domínio, e quatro leituras dela rodam em paralelo — três lentes de estado e a triagem, que abre as issues no In-box — e o gate comunica numa mensagem só. Com diagrama interativo.
• investigate-bug — investigação: pega os bugs parados em To scout sem projeto, investiga a causa raiz de cada um com o modelo que o risco pede, atualiza o card e move pra Reach. Com diagrama interativo.
• reach — planejamento: pega a mesma fila To scout sem a tag Bug e entrega cada issue a um subagente reach rodando a skill to-scout (research → PRD → sub-issues), deixando o card em Reach pro gate humano. Com diagrama interativo.

Os três leem a mesma coluna, e a tag decide de quem é o card. investigate-bug pega o que tem tag Bug; reach pega o que não tem. Sem esse corte, os dois pegariam o mesmo card e um sobrescreveria o trabalho do outro — bug precisa de causa, melhoria precisa de recorte.

Todo workflow tem DOIS desenhos archify, e eles respondem perguntas diferentes:

Desenho	Responde	Arquivo-fonte
do sistema	quais peças existem e quem é dona de quê — rotina, agente, skill, status Linear, mem0, externo	docs/agents/<w>.architecture.json
do grafo de agentes	quantas chamadas rodam, em que padrão e a que custo (model/effort por agente)	docs/agents/<w>.agents.architecture.json

Um não substitui o outro: a caixa "2. Planejar" do primeiro é, no segundo, N chamadas em dois degraus de modelo. Sem o de sistema ninguém sabe quem escreve onde; sem o de agentes ninguém sabe o que o run custa nem onde está a barreira.

A fonte é sempre o JSON; o .svg e o .html são derivados por comando. Mudou o workflow, regere os dois no mesmo commit — diagrama defasado contradiz o texto ao lado sem avisar.

Os dois formam um par: o primeiro constata e registra, o segundo investiga. O gate entre eles é humano — alguém promove a issue de In-box pra To scout quando decide que vale.

Três coisas que valem saber antes de escrever um

• pipeline() por padrão, parallel() só com barreira de verdade. Barreira se justifica quando a etapa seguinte precisa de todos os resultados juntos (dedup, manchete consolidada).
• Cada agent() carrega model/effort explícitos. Omitir faz herdar o modelo da sessão — e num pipeline() de 40 itens isso são 40 chamadas no degrau mais caro. Quando o degrau depende do item (risco, tamanho), decida em código: é o que o investigate-bug faz pra escolher entre Sonnet e Opus por bug.
• workflow() aninha só um nível. Um workflow pode chamar outro; o chamado não pode chamar um terceiro. Foi essa regra que fez a monitoração virar um workflow só.

O gate que nenhum workflow atravessa

Nenhum destes workflows mergeia, deploya ou conserta código. O que eles produzem é evidência, issue e parecer — e o merge continua sendo decisão humana.