PrumoGrid in short videos.

This is PrumoGrid, a workspace for developers working with multiple terminals and AI agents.

It runs on Windows and organizes your work by project. Each project is a folder, and its terminals sit together here in the middle, be it PowerShell, WSL or Git Bash. You can use just the terminal or your CLI agent, like Claude Code, Codex, Gemini or any other you prefer. The terminals don't depend on the window. They run in the daemon, a background service that keeps your terminals and coding agents running. The status bar shows whether the daemon is connected. So I can close the window, open it again, and everything is just as it was. If the computer restarts, PrumoGrid offers to reopen the terminals and resume your Claude and Codex conversations. The name comes from prumo, which is what builders here in Brazil call a plumb line: a string with a weight at the end, used to check that a wall is straight. That's the idea here: with several agents working at once, every terminal stays in the right project, and you can check at any time that everything is aligned. Projects are on the left. When I want to read one terminal carefully, I use Focus. On the right is Attention, which collects requests from agents across all projects, and right now it shows that the portal is waiting for permission. For tasks in sequence, there's Flow, which is optional and gets its own video. In the next one, I'll show you how to add a project and open its terminals.

Shall we add a project and open a few terminals in it?

I'll pick the store API folder. It only saves the path and doesn't copy anything. Here's the card for it, on the main branch. I open a PowerShell and a Git Bash. Both start inside the project folder, so I run git status in one and the tests in the other. The project card now shows main and two sessions. When I have several projects, I look there to see which ones have terminals open. When I want to read one terminal carefully, I use Focus. That one takes up a bigger part of the screen, and the other terminals stay in this strip at the bottom. Clicking a thumbnail switches to that terminal. And in the Grid they're side by side again. In the next one, I'll call an agent.

Shall we hand a task to Claude Code?

I could call the agent from the terminal, as usual. New stage is optional. I use it when I want PrumoGrid to follow the task and let me know when it's done. I ask it to count the code and test files, and to answer with just the number, without listing the names. It opens in a new terminal and gets the request right away. It said seven, with no names, and there really are seven. In the Stages tab, the task shows as done. Windows notifications have three options: when I'm needed, when something fails, and when work finishes. I usually leave only the first one on. The status bar has the color legend, one color for each agent and each shell. Next to it are the sessions, the CPU and the memory. In the next one, I'll put two tasks in sequence for the same agent.

This time it's two tasks in a row for the same agent.

Flow is optional. If you only use projects, terminals, the Grid and Focus, you can skip this part. I use it when I want to line up tasks. I create the flow with the first stage. It asks Claude to read the shipping file and explain when shipping is free. The second stage runs in the same terminal and asks for two test cases for that rule. It's set to start once the first one is done. I run it, and the first stage starts. When Claude finishes the first one, the second one starts right after, in the same conversation. The terminal shows both requests and both answers. For the second one, I didn't have to explain the shipping rule again, because Claude had already read the file. This button saves the flow as a routine. I'll show routines later on.

Now with two agents: Claude reviewing and Codex fixing.

The first stage goes to Claude Code. It reviews the coupon module and writes what it finds to a file, REVISAO.md, without changing the code. I create the second one from New stage, using Codex in a new terminal. It reads that file, fixes the first item and runs the tests. I set it to start after stage 1. Codex can't see Claude's conversation, because they're separate programs. That's why the first stage writes the file, which is what the second one will read. I run the flow. Claude starts the review, and Codex waits.

When REVISAO.md is ready, Codex starts. It edits the coupon module and runs npm test. In Flow, both stages show as done, and you can open the result of each one.

There's a change in the API that needs to reach the portal.

In the API project, I create the first stage. Claude reads the shipping file and writes the rule to a CONTRATO.md file. I also fill in the Model field. Each stage can have its own. The next stage goes to another project. I continue the flow in the portal. In the portal, Codex does the work, with a smaller model, because the task is just to change some text. It reads the contract and updates the banner. For now, it's waiting for the API.

I run it from the API project. When the contract is ready, Codex starts in the portal on its own. You can see it editing banner.js. In the portal's Flow, the stage shows as done. In the next one, I'll show you routines.

Shall we create a routine from scratch and then use it?

They're optional, just like Flow and New stage. Some come ready-made, but I prefer to build my own. This one will be called Review and fix. In the first stage, Claude reviews the code, and in the second, Codex fixes it and runs the tests. For the Codex stage, I set the condition to the project verification, which is npm test. If it doesn't pass, the stage isn't marked done. To use it, I pick the routine and just type the task for this time. The terminals are already suggested by the routine. Before running, there's a screen to review what will run. The flow starts with the two stages from the routine.

Shall we create the project's rules?

A rule is something every agent in the project needs to know before it starts. In my case, things like what language it answers in, and the files it can't change without telling me. It can apply to this project, to every project, or only to a role or a type of CLI. For this project, I write one rule with two instructions: answer in English, and don't change package.json without telling me first. I save it, and from now on it applies to the agents in this project. When I create the first stage, I get a request to write the guidance to CLAUDE.md. Before allowing it, I like to look at what will be written. It's a block between two markers, and the rest of the file stays as it was. This permission is per project, so it only asks once. Claude answered with both instructions. In the prompt, I only asked which rules it had to follow; it read the rest from the file. There's also a screen that shows everything the agent receives, and where each part comes from. I open that one when the agent does something I didn't expect. This rule lives in the repository. git status shows the new files, so the rule goes into the commit, and anyone who clones the repository gets it too. In Flow, there's a counter for the project's rules. They apply to both Claude and Codex.

This one is about agent roles.

A role is what the agent does in a stage, like reviewing or implementing. It doesn't depend on the tool, so the same role works for both Claude and Codex. Four come ready-made: analyst, implementer, reviewer and checker. I'm going to create a security one. It looks for secrets in the code and for unvalidated input, writes what it finds to a file, and doesn't change the code. This role has a rule of its own: cite the file and line for each finding. In New stage, I pick the role under More options. The task itself is short, just analyze the code folder, because the rest is already in the role. It wrote its findings to SEGURANCA.md. git status shows that file and the PrumoGrid ones, and nothing inside the code folder. In Flow, the roles show up as buttons. Clicking implementer gives me a planned stage with that role right away, and on the card I can change it later, under Role and sequence.

A role can also point to a skills folder for the agent to look at. That field is optional; I hardly ever use it. In the next one, I'll put all of this together in an operation with three agents.

In this video, I show a bug fix from start to finish, with three agents working one after another.

The bug is in the first-purchase coupon: with two items in the cart, the discount is applied twice. To fix it, I use my usual flow, with three stages: analysis, fix and review. For analysis, Claude reads the code, finds the cause and writes a plan to a file, without changing anything. For the fix, Codex follows that plan and changes the code. For the review, Claude checks what was done. Each stage opens its own terminal and has its own role. The project rules apply to all three: answer in English, don't touch package.json without telling me, and every change needs a test. The Done when line says when each stage finishes. The analysis is automatic, the fix is only done if npm test passes, and the review waits for my approval. I run the flow and go back to the Grid.

The analyst is reading the coupon and the cart. When it wants to write ANALISE.md, it asks for permission, and the request shows up in the terminal, on the card, in Attention and in the status bar. The request shows which terminal and which stage it came from. I answer it in the terminal.

ANALISE.md has the cause, the plan and a case that reproduces the bug. That's the file Codex will read. With the analysis done, the fix starts on its own. I switch to Focus to watch Codex. It reads the analysis, changes how the coupon calculates the discount and adds a test for the two-item case. Now it runs npm test, and all the tests pass, including the new one. The stage counts as done because npm test passed. The agent saying it's finished isn't enough. View result shows the command, the output and the verdict.

Then the reviewer comes in. It reads what changed and writes its findings to REVISAO.md. Before approving, I read the findings. If there were a problem, I'd send it back for correction with an instruction. This time, I approve it. The Stages tab keeps the log, with the instructions sent and the time of each step. All three stages are done. I stepped in twice, for the permission and the approval. The agents did the rest on their own.

I'll show you how I organize my work when I have three or more projects that are related, or that depend on each other.

On the left are the three projects: the store API, the portal and payments. I add one project for each repository, because terminals, stages and rules are tied to the project. When I click payments, the Grid and the sidebar switch together. In Flow, I make one flow for each goal. This one is for fixing the coupon, and in the selector there's another one for updating the documentation. I keep them apart because each one has its own stages, and I prefer to look at one thing at a time. To follow several agents, I stay in the Grid, with the terminals side by side. When I need to read a long answer, I switch to Focus. That terminal takes up the center, and the others stay in the strip at the bottom. When two agents are going to work in the same repository, I create a worktree, which is a second folder of the repository, on a separate branch. Each agent gets its own copy of the files. The card shows the line cupom-fix, worktree, one session. I choose the model based on the task. I asked Codex for something short, to explain what the test script is for, and a smaller model handles that. A bigger model is slower and more expensive, so I save it for tasks like finding the cause of a bug. For the stages that matter, I don't rely only on the agent's answer. The card has the line Verification, npm test, detected. If a stage has that verification and the tests fail, it isn't marked done, even if the agent says it's finished. When I keep repeating a flow, I save it as a routine. This one, Review and fix, has Claude reviewing and Codex fixing. And whatever applies to every agent in the project, like answering in English, I write once in the rules. In the next one, I'll show what day-to-day work looks like with more than one project.

Now, day-to-day work with more than one project.

I'm in the store API, with a flow running. Meanwhile, the portal's agent has asked for permission, and Attention shows it at the end of the list, labeled In another project. Clicking there takes me to the terminal that asked. I answer, and then I go back to the API. The Stages tab shows the stages of the selected project. I usually filter by Needs you, and there's also the Results filter. The Usage tab shows each terminal's CPU and memory, adding up all the processes it started. If a terminal is using too much, I can set a memory and CPU limit, from this row or from the Tools menu. This PowerShell in payments is idle, so I end it. The search at the top finds terminals, stages and rules by name. Thank you so much for watching the series.