pipeline

catálogo pessoal

Quatro pipelines,
da feature ao PR.

Feature começa com um prompt que dispara subagentes, um por skill. Depois do meu debug manual, o agente faz a segunda revisão. A interface passa por seis skills até não sobrar slop de componente e de escrita, e o fechamento vai de commits atômicos ao PR. Os quatro rodam no meu trabalho e nos meus projetos pessoais.

pipelines
—
skills
—
estágios
—
abrir pipeline

Um prompt carrega o PLAN da fase e cada subagente recebe uma das skills.

02 o que eu não terceirizo

Debug, revisão e qualidade de código não podem morrer.

O agente escreve, revisa e testa, mas a decisão continua sendo minha. Eu debugo na mão antes de pedir a segunda revisão, leio o diff antes de aprovar e confiro o que o teste cobre. São processos que eu pratico em toda tarefa, com agente ou sem.

  • debug manual
  • revisão de código
  • qualidade

03 memória

O agente precisa lembrar da sessão anterior.

Sem memória, cada sessão começa do zero e a correção de ontem volta como erro hoje. Duas ferramentas cuidam disso.

notas

Obsidian

Meu vault de notas, aberto ao agente por MCP. O que eu escrevo sobre o projeto fica lá, e o agente lê e escreve nas mesmas notas.

sessões

AI-Memory

Servidor MCP que guarda as sessões: observações, decisões e o que ficou pendente. Antes de refazer uma investigação, eu busco ali.

As duas ficam fora dos pipelines. O trabalho consulta essa memória antes de começar.

04 como funciona

O que vale para os quatro

skill

faz uma coisa

Uma competência isolada. Funciona em qualquer contexto e não sabe quando parar.

pipeline

faz na ordem

Uma sequência com dependências e critério de saída. Serve a um tipo de tarefa, e para de servir quando a tarefa muda.

  1. 01

    Cada estágio deixa algo pronto para o próximo

    Se o estágio não produz nada que o próximo usa, ele não está no pipeline. Um estágio sem entrega não tem como ser verificado.

  2. 02

    Só avanço quando o critério é cumprido

    Concluir a tarefa não quer dizer que o objetivo foi alcançado. Quem decide se o estágio fechou é o critério dele, não o tempo que passou.

  3. 03

    A ordem muda o resultado

    systematic-debugging vem antes de code-review-excellence porque revisar código que ainda falha gasta tempo com o problema errado. tdd vem antes de systematic-debugging para o bug virar teste antes de virar correção.

05 de onde vêm

O crédito é de quem escreveu cada skill.

abrir skills.sh

Eu escolho a ordem e o critério de saída. As skills vêm de repositórios públicos, e cada linha abaixo aponta para o autor. Para instalar, o catálogo fica no skills.sh.

    systematic-debugging cita a coleção superpowers no próprio texto e não registra repositório no lock local.