Review your agents’ work

When agents finish a task in a layer, check what they changed before it goes anywhere. This page shows how to review a layer, spot clashes with other layers, commit the work and open a pull request.

Figure: From a layer’s changes to a pull request. The review also warns about files other layers changed too.

You review, commit and open pull requests from the layer chip at the top left of the canvas. These actions work on task layers, not on Base. To learn about layers, see Projects and layers.

Review a layer

1. Switch to the layer you want to check.
2. Click the layer chip and choose Review changes.

Cuewire adds two things to the canvas, wired together:

• A review note, named after the layer (for example Review: Fix login). It lists what the layer changed.
• A Reviewer agent. It reads the changes and writes its findings into the note.

Figure: A review. The note lists collisions with other layers, then the changes, riskiest first. The Reviewer adds its findings at the end.

What the review note shows

The note starts with the totals: the commit the layer started from, the number of files, and the lines added and removed. It also counts changes that are not committed yet.

Then it has these sections:

• Collisions with other layers: files that another layer changed too. See below.
• Changes, riskiest first: every changed file, with how it changed and its line counts. Files that deserve a closer look come first, with the reason. For example: “changes CI”, “changes the database schema”, “changes locked dependencies”, “touches authentication”, “touches environment settings”, “deletes a file” or “a large change”.
• Findings: empty at first. The Reviewer writes here.

The note counts everything the layer changed since it began: commits, changes not yet committed, and new files.

The Reviewer agent

The Reviewer is held to read-only: it can read files and run git diff and git log, but it can’t change files. It gets the built-in Reviewer role. Cuewire uses an agent you already have on the canvas, if that agent can be held to read-only. Otherwise it uses Claude Code.

Cuewire types a short brief into the Reviewer. The brief asks it to read the diff. Then it adds to the note what must change before merging, with file and line. It also lists risks, missing tests and a one-line verdict.

Note

Sometimes Cuewire can’t tell whether the agent is ready for the brief. Then it types the brief but does not send it, and says The review brief is typed into Reviewer; press Enter there to start. Click into the Reviewer’s terminal and press Enter.

You can run a review again at any time. Each review adds a new note and a new Reviewer.

Collisions with other layers

Two layers that change the same file may not merge cleanly. The review compares the layer with every other layer that is not archived. It also compares it with your project folder (Base) since the layer began.

In the Collisions with other layers section:

• ⚠ … on the same lines; merging will likely conflict: another layer changed the same lines, or lines right next to them. Git will most likely stop with a conflict.
• … on other lines: another layer changed the same file, but in other places. Git can most likely merge both.

Tip

A likely conflict is cheaper to fix now. Ask one of the agents to rebase on the other layer’s branch, or merge one layer first and then review the other again.

Commit the work

1. Switch to the layer.
2. Click the layer chip and choose Commit all changes.

Cuewire stages everything in the layer’s folder, new files included, and makes one commit on the layer’s branch. The message is the layer’s name, for example Fix login: changes from Cuewire. The canvas then says, for example, Committed 3 files in Fix login (1a2b3c4). If there is nothing to commit, it says Nothing to commit in Fix login.

Note

Your git hooks run first, such as pre-commit, as with any commit. While they run, the canvas says Committing Fix login…. If a hook fails, nothing is committed, and the canvas shows the end of what the hook said. Fix the problem, or ask an agent to, and commit again.

To pick files one by one instead, stage them in a file node and commit from a terminal. See Files and the editor.

Open a pull request

Cuewire opens pull requests with the GitHub CLI (gh) or the GitLab CLI (glab). It uses your own sign-in in that tool, and never sees your tokens.

Before the first time:

1. Install gh (for GitHub) or glab (for GitLab).
2. Sign in once in a terminal: gh auth login or glab auth login.

Then, for each layer:

1. Commit the layer’s work (see above). Cuewire refuses to open a pull request while there are uncommitted changes.
2. Click the layer chip and choose Open pull request. The canvas says Pushing Fix login and opening a pull request….
3. Cuewire pushes the layer’s branch and opens the pull request. It opens the page in your browser and says Opened with its address.

Figure: The pull request is open. Cuewire shows its address and opens it in your browser.

What the pull request contains:

• Into: your repository’s default branch, for example main.
• Title: the commit’s message if the layer has one commit. With more commits, the layer’s name.
• Description: a list of the layer’s commits, then “Opened from a Cuewire layer.”

On GitLab, Cuewire opens a merge request instead. If a pull request for the branch is already open, Cuewire says A pull request was already open: with its address, and opens it.

If it does not work

Cuewire pushes to the remote named origin. Without one, it uses the first remote it finds.

Note

Reviews, commits and pull requests run on your own computer. They don’t work for remote projects.

What’s next

• Files and the editor: read a file’s diff and stage files one by one.
• Projects and layers: archive a layer once its pull request is merged.
• Agents working together: hand the review’s findings back to the builder.