When an agent says done, which files did it test?

Stefano Dago — Tue, 13 Oct 2026 09:54:54 +0000

A passing test belongs to one version of your code. So does a review.

That sounds obvious until two coding-agent windows are working on the same project. One window reports that tests passed. Another reviews the change. Then a small edit lands before you merge. The chat still contains two reassuring messages, but neither tells you whether the files in front of you are the ones that were checked.

I'm the author of Squadra, an MIT-licensed skill and local Python toolkit for coordinating Claude Code, Codex and interactive Cursor windows. Keeping those steps connected is one of its main design choices.

A small example

Imagine a task to fix an empty-state bug. This is an illustrative workflow, not a benchmark or a recorded customer session.

Step	What happened	What it establishes
1	Claude changes the empty-state handling	There is a candidate to check
2	The agreed test command passes on that candidate	Those checks passed on those files
3	A different Codex window reviews the frozen candidate	A non-author has reviewed that version
4	Someone edits the checked files	The candidate has changed
5	Tests and review are repeated for the new candidate	Closure can be considered against current evidence

Step four is easy to underestimate. The edit might be harmless. That is a reason to use proportionate checks; it doesn't make the earlier result describe the new files.

What needs to survive outside the chat

For this handoff, a useful record answers a few concrete questions: who owns the task, what command actually ran, what result it returned, which files were checked, and who reviewed them.

Squadra keeps assignments, acknowledgments, proof, reviews and decisions in a shared local registry. The agents follow a skill and use a CLI; a browser dashboard makes the task history visible to the person coordinating the work.

Its prove command records the check and file fingerprints. deliver creates an immutable packet for review. Before a task can close, the candidate, proof and review are checked together again. Changes to the source invalidate the earlier proof and review for closure.

That last check matters even if the dashboard already looks reassuring.

A second window is only part of a review

The reviewer must have an identity different from the author. Giving the same window another alias does not make it independent.

There is still a judgment call: did the tests cover the failure the task was meant to fix? A passing command can be inadequate. A separate reviewer can miss something. Recording the handoff makes it inspectable; it does not prove the software is correct or ready for production.

The same principle applies to scope. Ignored dependencies need their own evidence. A source fingerprint does not establish everything about the environment in which the code will run.

Trying the workflow

Start with a small change that has a clear check, then follow one task through assignment, proof, review and closure. That gives you a way to judge whether the extra record helps before applying it to a larger project.

The repository includes installation instructions, screenshots and an 80-second animated tour.

The toolkit requires Python 3.12+ and Git; Node.js is needed for the dashboard checks in the self-test. macOS/POSIX is the tested environment. Cursor works interactively. There is no Squadra account, and your coding agents retain their usual costs.

If you use several coding agents, what do you need in the handoff before you trust a review: the diff, the command output, a separate reproduction, or something else?

DEV Community: Stefano Dago

When an agent says done, which files did it test?

A small example

What needs to survive outside the chat

A second window is only part of a review

Trying the workflow