Pular para conteúdo

workflow /reach — o grilling da fila

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

Trabalha a fila do planejamento: afia o card até dar pra construir, e só então escreve o documento.

Diagrama do comando /reach: lê a coluna Reach, faz o grilling do card (co-create interativo ou to-scout no modo auto), escreve PRD e sub-issues, e promove pra To build só no modo interativo

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

Modo Como o card é afiado Destino
interativo (default) co-create — entrevista, uma pergunta por vez, com a resposta recomendada em cada pode promover pra To build, confirmando card por card
/reach auto to-scout — a entrevista trocada por pesquisa: grafo → Sentry/PostHog → schema real → web fica em Reach

Depois do grilling, nos dois modos: to-prd → to-issues → carimbo de priority e estimate.

A diferença entre os modos é de onde vem a resposta — de você, ou de evidência. E é por isso que o destino muda: no auto, ninguém aprovou, e Reach → To build é o único gate antes de alguém gastar tempo implementando.

O PRD tem duas seções obrigatórias: critério de aceite verificável (algo que o monitor consiga checar depois — "funcionar bem" não é critério) e fora de escopo (sem ela, quem implementa preenche a lacuna com bom senso próprio).

Card que já chegou groomed — com PRD posto pela to-scout — tem outro trabalho: o grilling é sobre o que está lá, o que ficou fraco e o que o PRD decidiu sozinho. Não reescreva do zero.

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