O PrumoGrid em vídeos curtos.

Esse é o PrumoGrid, um espaço de trabalho para quem desenvolve com vários terminais e agentes de IA.

Ele roda no Windows e organiza o trabalho por projeto. Cada projeto é uma pasta, e os terminais dele ficam juntos aqui no meio, seja um PowerShell, o WSL ou o Git Bash. Dá para usar só o terminal ou o seu agente de CLI, seja o Claude Code, o Codex, o Gemini ou qualquer outro da sua preferência. Os terminais não dependem da janela. Eles rodam no daemon, um serviço em segundo plano que mantém os terminais e os seus agentes de código ativos. No rodapé dá para conferir se o daemon está conectado. Por isso eu posso fechar a janela e abrir de novo, e está tudo do jeito que estava. Se o computador reiniciar, o PrumoGrid oferece reabrir os terminais e retomar as conversas do Claude e do Codex. O nome vem do prumo, o fio com um peso na ponta que o pedreiro usa para conferir se a parede está reta. A ideia é a mesma aqui: com vários agentes trabalhando ao mesmo tempo, cada terminal fica no projeto certo e dá para conferir a qualquer momento se está tudo alinhado. Na esquerda ficam os projetos. Quando eu quero ler um terminal com calma, uso o Foco. Na direita fica a Atenção, que junta os pedidos dos agentes de todos os projetos, e nesse momento ela mostra que o portal espera uma permissão. Para tarefas em sequência existe o Fluxo, que é opcional e fica para outro vídeo. No próximo eu mostro como cadastrar um projeto e abrir os terminais.

Vamos cadastrar um projeto e abrir alguns terminais nele?

Vou escolher a pasta da API da loja, e ele guarda só o caminho, sem copiar nada. Apareceu o cartão dela, com o branch main. Eu abro um PowerShell e um Git Bash. Os dois já começam dentro da pasta do projeto, então eu rodo o git status num e os testes no outro. No cartão do projeto apareceu main, duas sessões. Quando eu tenho vários projetos, eu olho ali para ver onde tem terminal aberto. Quando eu quero ler um terminal com calma, eu uso o Foco. Ele passa a ocupar uma área maior na tela, e os outros terminais ficam destacados nessa faixa embaixo. Clicando na miniatura eu troco de terminal. E na Grade eles voltam a ficar lado a lado. No próximo eu chamo um agente.

Vamos passar uma tarefa para o Claude Code?

Eu podia chamar o agente pelo terminal, como sempre. A Nova etapa é opcional. Eu uso quando quero que o PrumoGrid acompanhe a tarefa e me avise quando terminar. Eu peço para ele contar os arquivos de código e de teste, e responder só com o número, sem listar os nomes. Ele abre num terminal novo e já recebe o pedido. Ele respondeu sete, sem nomes, e são sete mesmo. Na aba Etapas a tarefa aparece como concluída. Os avisos do Windows têm três opções, quando o agente precisa de mim, quando dá falha e quando termina. Eu costumo deixar só a primeira. No rodapé fica a legenda das cores, uma para cada agente e cada shell. Do lado aparecem as sessões, a CPU e a memória. No próximo eu coloco duas tarefas em sequência para o mesmo agente.

Dessa vez são duas tarefas seguidas para o mesmo agente.

O Fluxo é opcional. Se você só usa projetos, terminais, a Grade e o Foco, pode ignorar essa parte. Eu uso quando quero deixar tarefas em fila. Crio o fluxo com a primeira etapa. Ela pede para o Claude ler o arquivo de frete e explicar quando o frete sai grátis.

A segunda etapa fica no mesmo terminal e pede dois casos de teste para essa regra. Ela está marcada para começar depois que a primeira ficar pronta. Executo, e a primeira etapa começa. Quando o Claude termina a primeira, a segunda entra em seguida, na mesma conversa. No terminal estão os dois pedidos e as duas respostas. Na segunda eu não precisei explicar o frete de novo, ele já tinha lido o arquivo. Esse botão salva o fluxo como rotina. Rotina eu mostro mais para a frente.

Agora com dois agentes, o Claude revisando e o Codex corrigindo.

A primeira etapa é do Claude Code. Ele revisa o módulo de cupom e escreve o que achar num arquivo, o REVISAO.md, sem alterar o código.

A segunda eu crio pela Nova etapa, com o Codex num terminal novo. Ele lê esse arquivo, corrige o primeiro item e roda os testes. Deixo marcado para começar depois da etapa 1. O Codex não enxerga a conversa do Claude, são programas diferentes. Por isso a primeira etapa grava o arquivo, que é o que a segunda vai ler. Executo o fluxo. O Claude começa a revisão e o Codex fica esperando.

Quando o REVISAO.md fica pronto, o Codex começa. Ele mexe no cupom e roda o npm test. No Fluxo as duas etapas aparecem concluídas, e dá para abrir o resultado de cada uma.

Tem mudança na API que precisa chegar no portal.

No projeto da API eu crio a primeira etapa. O Claude lê o arquivo de frete e escreve a regra num CONTRATO.md. Também preencho o campo Modelo. Cada etapa pode ter o seu.

A próxima etapa vai para outro projeto. Eu continuo o fluxo no portal. No portal quem faz é o Codex, com um modelo menor, porque a tarefa é trocar um texto. Ele lê o contrato e atualiza o banner. Por enquanto está aguardando a API.

Executo na API. Quando o contrato fica pronto, o Codex começa no portal sozinho. Dá para ver ele editando o banner.js. No Fluxo do portal a etapa aparece concluída. No próximo eu mostro as rotinas.

Vamos criar uma rotina do zero e depois usar?

Elas são opcionais, igual ao Fluxo e à Nova etapa. Já vêm algumas prontas, mas eu prefiro montar as minhas. Essa vai se chamar Revisar e corrigir. Na primeira etapa o Claude revisa o código, e na segunda o Codex corrige e roda os testes.

Na etapa do Codex eu coloco como condição a verificação do projeto, que é o npm test. Se não passar, a etapa não fica pronta. Para usar, eu escolho a rotina e escrevo só a tarefa desta vez. Os terminais já vêm sugeridos por ela. Antes de executar tem uma tela para conferir o que vai rodar. O fluxo começa com as duas etapas da rotina.

Vamos criar as regras do projeto?

Regra é aquilo que todo agente do projeto tem que saber antes de começar. No meu caso, coisas como o idioma da resposta e os arquivos que ele não pode alterar sem avisar. Ela pode valer para esse projeto, para todos os projetos, ou só para um papel ou um tipo de CLI. Nesse projeto eu escrevo uma regra com duas orientações, responder em português e não alterar o package.json sem avisar antes. Salvo, e a partir de agora ela vale para os agentes desse projeto. Na primeira etapa que eu crio, aparece um pedido para gravar as orientações no CLAUDE.md. Antes de permitir eu gosto de olhar o que vai ser gravado. É um bloco entre dois marcadores, e o resto do arquivo fica como estava. Essa permissão é por projeto, ele só pergunta uma vez.

O Claude respondeu com as duas orientações. No prompt eu só perguntei quais regras ele tinha que seguir, o resto ele leu do arquivo. Tem também uma tela que mostra tudo o que o agente recebe, com a origem de cada trecho. Essa eu abro quando ele faz algo que eu não esperava. Essa regra ficou no repositório. O git status mostra os arquivos novos, então ela vai junto no commit e quem clonar o repositório recebe também. No Fluxo tem um contador com as regras do projeto. Elas valem para o Claude e para o Codex.

Esse é sobre os papéis dos agentes.

Papel é o que o agente faz na etapa, por exemplo revisar ou implementar. Não depende da ferramenta, então o mesmo papel serve para o Claude e para o Codex. Já vêm quatro prontos, analista, implementador, revisor e verificador. Eu vou criar um de segurança. Ele procura segredo no código e entrada sem validação, anota num arquivo e não altera o código. Esse papel tem uma regra só dele, que é citar o arquivo e a linha de cada achado. Na Nova etapa eu escolho o papel em mais opções. A tarefa fica curta, só analisar a pasta de código, porque o resto já está no papel.

Ele gravou os achados no SEGURANCA.md. No git status aparecem esse arquivo e os do PrumoGrid, e nada dentro da pasta de código. No Fluxo os papéis aparecem como botões. Clicando no implementador eu já tenho uma etapa planejada com esse papel, e no cartão dá para trocar depois, em papel e sequência.

O papel também pode apontar uma pasta de skills para o agente consultar. Esse campo é opcional, eu quase não uso. No próximo eu junto tudo isso numa operação com três agentes.

Nesse vídeo eu mostro uma correção de bug do começo ao fim, com três agentes trabalhando um depois do outro.

O bug é no cupom de primeira compra: com dois itens no carrinho, o desconto sai em dobro. Para corrigir, eu uso o fluxo de sempre, com três etapas: análise, correção e revisão. Na análise, o Claude lê o código, encontra a causa e escreve um plano num arquivo, sem alterar nada. Na correção, o Codex segue esse plano e muda o código. Na revisão, o Claude confere o que foi feito. Cada etapa abre o seu terminal e tem o seu papel. As regras do projeto valem para as três: responder em português, não mexer no package.json sem avisar, e toda mudança vir com teste. A linha Pronta diz quando cada etapa termina. A análise é automática, a correção só fica pronta se o npm test passar, e a revisão espera a minha aprovação. Executo o fluxo e volto para a Grade.

O analista está lendo o cupom e o carrinho. Quando quer gravar o ANALISE.md, ele pede permissão, e o pedido aparece no terminal, no cartão, na Atenção e no rodapé. No pedido dá para ver de qual terminal e de qual etapa ele veio. Eu respondo no terminal.

No ANALISE.md fica a causa, o plano e um caso que reproduz o erro. É esse arquivo que o Codex vai ler. Com a análise pronta, a correção começa sozinha. Eu passo para o Foco para acompanhar o Codex.

Ele lê a análise, altera o cálculo do desconto no cupom e acrescenta um teste para o caso dos dois itens. Agora ele roda o npm test, e todos os testes passam, inclusive o novo. A etapa só fica pronta porque o npm test passou. Não basta o agente dizer que terminou. Em Ver resultado aparece o comando, a saída e o veredito.

Aí entra o revisor. Ele lê o que mudou e grava os achados no REVISAO.md. Antes de aprovar, eu leio os achados. Se tivesse algum problema, eu devolvia para a correção com uma instrução. Dessa vez, eu aprovo. Na aba Etapas fica o registro, com as instruções enviadas e o horário de cada coisa. As três etapas terminaram. Eu entrei duas vezes, na permissão e na aprovação. O resto os agentes fizeram sozinhos.

Vou mostrar como eu organizo o trabalho quando tenho três ou mais projetos que se relacionam, ou que são dependentes entre si.

Na esquerda estão os três projetos, a API da loja, o portal e os pagamentos. Eu cadastro um projeto para cada repositório, porque os terminais, as etapas e as regras ficam ligados ao projeto. Quando eu clico nos pagamentos, a Grade e a lateral trocam juntas. No Fluxo eu faço um fluxo para cada objetivo. Esse é o de corrigir o cupom, e no seletor tem o de atualizar a documentação. Separo os dois porque cada um tem as suas etapas, e eu prefiro olhar um trabalho de cada vez. Para acompanhar vários agentes eu fico na Grade, com os terminais lado a lado. Quando eu preciso ler uma resposta longa, passo para o Foco. O terminal fica grande no centro, e os outros continuam na faixa embaixo. Quando dois agentes vão mexer no mesmo repositório, eu crio um worktree, que é uma segunda pasta do repositório, num branch separado. Cada agente fica com a sua cópia dos arquivos. No cartão aparece a linha cupom-fix, worktree, uma sessão. O modelo eu escolho pela tarefa. Para o Codex eu pedi uma coisa curta, explicar para que serve o script de teste, e um modelo menor resolve. Um modelo maior é mais lento e mais caro, então eu deixo para tarefas como achar a causa de um bug. Nas etapas que importam eu não fico só com a resposta do agente. No cartão tem a linha Verificação, npm test, detectado. Se uma etapa tem essa verificação e os testes falham, ela não fica pronta, mesmo que o agente diga que terminou. Quando um fluxo se repete, eu salvo como rotina. Essa, Revisar e corrigir, tem o Claude revisando e o Codex corrigindo. E o que vale para todos os agentes do projeto, por exemplo responder em português, eu escrevo uma vez nas regras. No próximo eu mostro como é o dia a dia com mais de um projeto.

Agora o dia a dia com mais de um projeto.

Eu estou na API da loja, com um fluxo rodando. Enquanto isso o agente do portal pediu permissão, e a Atenção mostra no fim da lista, em outro projeto. Clicando ali eu vou para o terminal que pediu, respondo, e depois volto para a API. A aba Etapas mostra as etapas do projeto selecionado. Eu costumo filtrar pelo que precisa de mim, e tem também o filtro de resultados. Em Consumo aparecem a CPU e a memória de cada terminal, somando todos os processos que ele abriu. Se um terminal estiver pesado, dá para colocar limite de memória e de CPU, por essa linha ou pelo menu Ferramentas. Esse PowerShell dos pagamentos está parado, então eu encerro.

A busca lá em cima acha terminais, etapas e regras pelo nome. Muito obrigado por acompanhar a série.