Pular para conteúdo

workflow /scout — o inventário da fila

Este workflow é um comando, não um .js. /scout sem parâmetro pega a lista da coluna To scout 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 (/scout DEV-123), roda um só — mesma lógica, lote de 1.

Trabalha a fila de investigação. Para cada card, a descrição decide a skill — e é isso que substitui os dois workflows que existiam antes pra isso.

Diagrama do comando /scout: sem parâmetro ele lê a coluna To scout, spawna um subagente por card com a skill que o conteúdo do card pede, e leva o resolvido pra Reach — o que não fechou fica em To scout com o motivo

Clique no diagrama para a versão interativa (scout.html): tema claro/escuro, pan/zoom, busca, três views guiadas e export PNG/SVG. A fonte é o JSON (docs/agents/scout.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-scout que aquele card pede:

O que o card é Skill Só avança com
tem tag Bug diagnosing-bugs + codebase/graphify causa com arquivo:linha + sinal de reprodução
sem tag Bug to-scout research + PRD + sub-issues, com priority/estimate/labels
é pergunta/levantamento codebase/graphify a resposta comentada no card
toca banco/schema + MCP do Supabase (read-only) o schema real — a tabela ganha do código

Bug precisa de causa; melhoria precisa de recorte. Trocar os dois é o erro que faz um card chegar no dev parecendo pronto e sem nada acionável dentro.

Não fechou não avança. Falta de acesso, não reproduz, relato vago demais: o card fica em To scout com a pergunta que desbloqueia escrita nele. Inconclusivo honesto é informação; causa inventada é armadilha pro próximo.

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 /scout: um subagente por card da coluna To scout, 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 Reach
não fechou fica em To scout, 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.