Pitch: Lisa — a CLI open source que transforma issues do seu board em pull requests · tarcisiopgs

Nos últimos meses o ecossistema de agentes de IA para código explodiu. Claude Code, Gemini CLI, Copilot CLI, Cursor Agent — opções não faltam.

E junto com eles vieram os loops autônomos: ferramentas que pegam uma spec, jogam pro agente, rodam N iterações e torcem pra dar certo. O Ralph é um bom exemplo. Você escreve um PRD em JSON, ele roda o Claude Code ou Amp em loop até completar os itens, salvando progresso num progress.txt. Se travar? Roda de novo. Se o contexto estourar? Começa uma sessão nova.

Funciona? Até funciona. Mas tem um problema: ninguém trabalha assim.

No mundo real, o trabalho não começa num arquivo JSON no repositório. Começa num card do Linear, numa issue do GitHub, num ticket do Jira. E o resultado esperado não é "código commitado num branch" — é um pull request pronto pra review, com o card movido pra "In Review" no board.

É esse gap que a Lisa resolve.

O que é a Lisa?

Lisa é uma CLI open source que conecta o board de issues onde seu time trabalha diretamente nos agentes de IA que sabem codar — e entrega PRs no final.

O pipeline é determinístico:

Card no board → Lisa pega → Agente implementa → Push → PR aberto → Card atualizado

Não é um loop que roda 10 vezes até "achar que terminou". É um pipeline estruturado: fetch, implement, validate, PR, update. Se falha, tem fallback e recovery. Se dá certo, a issue tá resolvida e o PR tá lá no GitHub.

Três comandos e pronto:

npm install -g @tarcisiopgs/lisa
lisa init
lisa run

A diferença pro Ralph (e pros loops em geral)

Não tenho nada contra o Ralph — o nome da Lisa é literalmente uma referência aos Simpsons por causa dele. Mas a abordagem é fundamentalmente diferente:

	Ralph (loops)	Lisa
Input	PRD em JSON no repo	Card no board (Linear, Jira, GitHub Issues, Trello...)
Agentes	1-2 (Amp, Claude Code)	8 (Claude, Gemini, Copilot, Cursor, Goose, Aider, Codex, OpenCode)
Output	Commits no branch	PR aberto + card movido no board
Estratégia	Loop até completar	Pipeline determinístico com fallback chain
Multi-repo	Não	Sim, com plano de execução entre repos
Concorrência	Sequencial	Paralelo (N issues simultâneas em worktrees isolados)
Infra	Manual	Auto-discovery (Docker, migrations, env)
Visibilidade	`progress.txt`	Kanban TUI em tempo real no terminal

A Lisa não tenta substituir o Ralph — ela opera numa camada acima. Onde o Ralph precisa que você prepare um PRD e rode manualmente, a Lisa puxa o trabalho direto do board e entrega o resultado onde o time espera: no GitHub/GitLab/Bitbucket.

7 trackers × 8 agentes × 3 plataformas de PR

Essa é a parte que me dá mais orgulho. A Lisa é agnóstica em todos os eixos:

Sources (de onde vêm as issues):

Linear, GitHub Issues, Jira, GitLab Issues, Trello, Plane, Shortcut

Providers (quem implementa):

Claude Code, Gemini CLI, OpenCode, GitHub Copilot CLI, Cursor Agent, Goose, Aider, Codex

Plataformas de PR (onde entrega):

GitHub (CLI ou API Token), GitLab (Merge Requests), Bitbucket

Usa Jira no trabalho e quer Claude Code? Funciona. Time usa Linear e quer testar Gemini CLI que é free? Também. A Lisa não te prende a nenhum ecossistema.

Kanban em tempo real no terminal

Quando você roda lisa run, a Lisa renderiza um kanban interativo no terminal com Backlog, In Progress e Done. Cada card mostra o ID da issue, título, output do agente em tempo real e um timer. Você navega com as setas, entra no detalhe, pausa, mata um agente travado, pula uma issue — tudo pelo teclado.

É como ter um mini Linear rodando dentro do terminal enquanto os agentes trabalham.

lisa run --demo   # veja o kanban funcionando com issues fake

Fallback chain — não desperdiça crédito

Se o Claude Sonnet bate rate limit, a Lisa automaticamente tenta o Opus. Se o Opus também falha, tenta o Haiku. Sem intervenção manual, sem loop infinito queimando token.

provider: claude
models:
  - claude-sonnet-4-6    # primário
  - claude-opus-4-6      # fallback 1
  - claude-haiku-4-5     # fallback 2

A classificação de erro é inteligente: erros transientes (429, quota, timeout) trigam fallback. Erros de código param a chain.

Multi-repo — ninguém mais faz isso

Se seu projeto tem api/ e app/ em repos separados, a Lisa entende. No modo multi-repo, ela roda um agente de planejamento que analisa a issue, identifica quais repos são afetados, gera um plano ordenado e cria um PR por repo — passando contexto de dependência entre eles.

repos:
  - name: api
    path: ./api
    match: "[API]"
  - name: app
    path: ./app
    match: "[WEB]"

Ela aprende com os erros (e com o code review do seu time)

Toda sessão que falha é registrada. Na próxima tentativa, o agente recebe esse histórico e evita repetir os mesmos erros.

Se um PR é fechado sem merge e tem review comments, a Lisa extrai o feedback e injeta nas próximas execuções. O agente aprende com o code review do seu time.

Self-healing que loop nenhum tem

Orphan recovery: Lisa interrompida no meio de uma issue? Ela recupera issues órfãs no próximo startup
Push recovery: git push falhou por pre-push hook? A Lisa re-invoca o agente com o erro e tenta de novo
Overseer: agente travou sem produzir mudanças? É morto automaticamente e o fallback assume
Validação de spec: issue sem critérios de aceitação? Lisa adiciona label needs-spec e pula — sem desperdiçar tokens

Detecção automática de infra

Antes de rodar o agente, a Lisa analisa seu repo: sobe Docker Compose, roda migrations (Prisma, Drizzle, TypeORM), copia .env.example, identifica scripts de quality, mapeia padrões de teste, detecta geradores de API client (Orval, Kubb, hey-api). Tudo isso vira contexto no prompt — o agente não entra cego.

Como testar sem risco

lisa run --once --dry-run   # valida config sem executar nada
lisa run --demo             # kanban com issues fake

Pitch: Lisa — a CLI open source que transforma issues do seu board em pull requests