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?
Top comments (2)
To answer the closing question, I would want the exact command output and the commit hash it ran against, plus proof that the test fails without the change. A test that passes both before and after the fix says nothing about the bug, so that one detail does more for trust than a second reviewer does.
You're right Jessica a test that passes both before and after a fix proves nothing about the bug.
Squadra already records, for every proof, the exact command, its full output and exit code, and the commit it ran on. Any later change invalidates the proof.
For "fails without the change" there is
squadra challenge. It runs one check, a Pythoncheck(repo)with real assertions, on three committed checkouts:--original, with the bug;--remedy, the fix;--positive, a known-good control.It reports
matchedonly if the original fails on a real assertion and the other two pass; crashes and timeouts don't count. It keeps the commits, the output and the exit codes.Today it is optional. We are making it mandatory for bug fixes, shown next to each proof.
Thanks