leandrocfe Dev Pipeline
Orquestra o ciclo de vida de uma feature reutilizando as skills existentes. Você não implementa as fases aqui — você localiza o estado atual, aplica as regras de decisão, executa o que é seu, e diz ao usuário o comando exato da próxima fase.
O issue tracker e vocabulário de triage labels devem ter sido fornecidos a você — rode /setup-leandrocfe-skills se não.
Skills user-invoked (to-spec, to-tickets, wayfinder, triage, implement, handoff) só o usuário roda: seu papel é dizer quando e por quê. Skills model-invoked (grilling, tdd, code-review) você invoca diretamente na fase certa.
1. Localize o estado
Antes de propor qualquer coisa, descubra em que fase o trabalho está. Explore, não pergunte:
- Argumento do usuário descreve ideia nova? → fase de dimensionamento.
- Existe spec no tracker sem tickets derivados? → fase de decomposição.
- Existem issues abertas sem brief/labels de triage? → fase de triage.
- Existem issues prontas (com brief) sem branch? → fase de despacho.
- Existe branch em andamento? → fase de implementação ou review (olhe o diff).
Anuncie a fase detectada em uma frase e siga dali. Nunca reinicie o pipeline do zero se há trabalho em voo.
2. Dimensione (fase 0)
Uma feature nova passa primeiro pelo dimensionamento. Três saídas possíveis:
| Tamanho | Critério | Rota |
|---|---|---|
| Trivial | < ~1h, 1–2 arquivos, zero ambiguidade | Sem artefato. Implemente direto nesta sessão (branch + PR se repo usa PRs). |
| Pequeno | Cabe em 1 sessão e 1 PR, escopo claro | Sem spec. Escreva spec curta (uma issue única no tracker, ou .md se tracker é markdown local) e vá direto a implementação. |
| Médio/Grande | > 1 sessão, ou > 1 agente em paralelo, ou ambiguidade real de escopo | Pipeline completo (seção 3). |
| Enorme/nevoento | O caminho até o destino ainda não é visível — greenfield, ou feature grande demais para uma sessão sequer planejar | "Rode /wayfinder" para traçar o mapa e resolver a névoa em decisões. Ele reentra no pipeline em /to-spec quando o caminho ficar claro. |
Regra de ouro: > 1 sessão de trabalho OU > 1 agente em paralelo → issues no tracker. Senão, o mínimo possível. Na dúvida entre pequeno e médio, pergunte uma única pergunta ao usuário; não infle escopo por precaução.
O corte para wayfinder não é tamanho, é visibilidade: se você consegue enunciar o que construir, é pipeline completo por maior que seja; se você ainda não sabe o que decidir primeiro, é wayfinder.
3. Pipeline completo (médio/grande)
Cada fase termina num gate: artefato produzido, usuário revisa, você indica o próximo comando.
| Fase | Quem executa | Artefato | Gate — próximo passo |
|---|---|---|---|
| Esclarecer | Você, via skill grilling (invoque direto) |
Entendimento compartilhado na conversa | "Rode /to-spec para consolidar" |
| Especificar | Usuário: /to-spec |
Spec enxuta no tracker | "Rode /to-tickets sobre a spec" |
| Decompor | Usuário: /to-tickets |
Tickets em vertical slices, cada um com suas blocking edges | "Rode /triage para classificar e escrever briefs" |
| Triar + rotear | Usuário: /triage; você aplica a tabela da seção 4 durante a triage |
Issues com brief + label agent:* |
"Rode /implement na issue #N" (indique a primeira da frontier — a que não tem blockers abertos) |
| Implementar | Usuário: /implement; use tdd nos seams acordados |
Branch + commits + PR | Invoque code-review |
| Revisar | Você, via skill code-review (invoque direto) |
Achados sobre o diff, em dois eixos (Standards + Spec) | Aprovado → merge. Problemas → volta a implementar. |
| Continuar | — | — | Mais tickets na mesma sessão → próximo ticket. Nova sessão → "Rode /handoff". Fim → feche a spec. |
4. Roteamento de agente e runtime
Dois eixos independentes, decididos na triage, gravados como dois labels na issue.
Eixo 1 — role. Três perguntas, na ordem; a primeira resposta "sim" decide:
- Há decisão de design ou trade-off em aberto? →
agent:architect - Caminho conhecido, mas exige julgamento? →
agent:builder - Mecânico, sem ambiguidade? →
agent:runner
Advisor atua só antes do código (grilling, escopo). Reviewer só depois (fase de review).
Eixo 2 — runtime. Qual ferramenta/modelo executa. Tabela default (ajuste ao seu setup; o mapeamento role→runtime default vive aqui, a exceção vive no label):
| Role | Runtime default | Racional |
|---|---|---|
agent:architect |
Claude Code, modelo top | Raciocínio profundo, trade-offs |
agent:builder |
Claude Code modelo médio, ou Codex | Implementação padrão |
agent:runner |
O mais rápido/barato disponível (Codex mini, Grok fast, Haiku) | Mecânico, volume |
Label runtime:* só quando foge do default (ex.: runtime:codex num architect). Regra de review: autor e reviewer de runtimes/vendors diferentes sempre que possível — cross-model review pega mais defeito que auto-review.
Os labels vão na issue para que o despacho nunca seja re-decidido.
Despacho entre runtimes
O brief autocontido é a interface — qualquer CLI pega a issue sem contexto extra. Dois modos:
- Manual: usuário abre o runtime indicado pelo label num worktree da issue e aponta para o brief (
gh issue view N). - Headless: uma sessão orquestradora despacha via shell — ex.
codex exec --full-auto "implemente a issue #N; brief em: gh issue view N"dentro do worktree; equivalente para outros CLIs. Orquestrador só despacha e coleta; não implementa em paralelo ao worker.
Em ambos os modos o resultado volta pelo mesmo canal: branch + PR referenciando a issue. O pipeline não sabe nem precisa saber qual runtime produziu o diff.
5. Contexto e paralelismo
Agentes stateless, artefatos stateful. Contexto nunca vive em memória de conversa:
- O brief da issue é autocontido — quem pega a issue não precisa de mais nada. Um agente prepara trabalho para outro escrevendo o brief.
- A spec carrega o porquê; a issue linka para ela.
- A descrição do PR carrega o que foi feito, para o review.
/handoffsó para trabalho interrompido no meio de uma issue — nunca como substituto de brief.
Paralelismo sem conflito:
- 1 issue = 1 branch = 1 agente. Paralelo local → git worktrees.
- O brief lista os arquivos que a issue toca. Não despache em paralelo issues com interseção de arquivos.
- Dependências são as blocking edges que
/to-ticketsjá gravou — nativas no tracker onde ele suporta, texto no corpo onde não. Despache apenas a frontier: tickets cujos blockers estão todos fechados.
6. Git
- Branch:
feat/<n>-slug-curto(número da issue no nome). - Conventional commits;
Closes #Nno corpo do PR. - PR pequeno (~alvo: revisável em uma sentada), merge incremental.
Anti-padrões
- Não crie spec para trabalho pequeno — dimensionamento existe para isso.
- Não escreva specs em
.mdsoltos quando o tracker está configurado — artefato órfão não tem estado nem dono. - Não pule a triage "porque a issue é óbvia" — o label
agent:*e o brief são o que permite despacho sem re-análise. - Não acumule fases numa resposta só — um gate por vez; o usuário revisa o artefato antes da fase seguinte.