作者讓兩個 Claude Code 工作階段分任產品經理與工程師，自己在旁觀察

Since August, Claude Code sessions can talk to each other. The feature is called cross-session messaging and arrived in v2.1.224: a session finds your other sessions with ListAgents and sends one of them a message with SendMessage. What travels is only the text Claude writes for the other session, never the conversation history or files.

I've been using it to build rind-ui, a headless UI component library, with two sessions that have different jobs. One is the PM. The other is the engineer. This is how that went, including the parts that didn't work the first time.

Two sessions, two jobs

The repository's CLAUDE.md says it plainly: two sessions work on this repo, one writes specs and reviews, one implements.

The PM session writes each component as a spec (an OpenSpec change: the requirements, the scenarios, the tasks) and validates it before any code exists. When the engineer is done, the PM reviews the result.

The engineer session takes one spec, implements it, and when it thinks it's finished, sends a message back asking for review. That hand-off lists every file it touched, so the review knows exactly what to look at.

Neither session has the other's context. Each sees the repository and the messages it receives. I think that helps: the reviewer doesn't share the implementer's assumptions, so it reads the code more like the next person would.

Rules that make it stop

The first version allowed up to three review rounds per change. It's now down to two, with stricter rules. I see it as the slot machine problem in miniature: a reviewer asked to find problems will always find one more, so the loop has to be told where to stop. Today the rules are:

• Every finding has a severity. Critical breaks behaviour, data, security or accessibility. Error violates a requirement of the spec, or is a real bug. Warning is everything else: a weak test, an edge case, polish.
• Only critical and error get fixed now. Warnings go to a backlog file, docs/review-backlog.md, to be picked up later.
• Two passes per change, scoped to the change's own diff, never the whole repository. First a review, whose critical and error findings become tasks. Then, after the fixes, a verification pass that checks those fixes work. Anything new it finds goes to the backlog, unless it's critical for building the rest.

Then the change is approved, archived, and merged. The severity line and the cap on passes are what turned an open-ended loop into one that ends.

Where the comments live

This is the part I like most, and the reason I'm writing this on the blog of Reado, the IDE for reading the code your AI agent writes.

The PM session doesn't write its findings into a chat message. It leaves them as Reado comments, anchored to the exact lines they're about, each one typed (bug, refactor, performance…) and marked as a task. They're Markdown files in .reado/ inside the repository, so both sessions read the same list, and so do I.

The engineer fixes each one, and the task is closed with a command that proves the fix: task done with a --verify test command. Usually the engineer runs it; during verification the PM sometimes runs it itself. Reado records the task as done only if that command passes; a fix without a passing check stays visible as unverified until someone looks at it.

So far the PM has left 128 of these tasks: 115 bugs, 5 refactors, 3 performance issues and 5 notes. All 128 are closed, and every one of them was closed by a verify command that passed.

That has a side effect I didn't plan for. When I open the code in Reado, I don't need to reconstruct what the two sessions were arguing about. Each finding sits on the line it's about, with what was wrong, and the test that proved it fixed. It's easier for the session that has to fix the bug, and it's easier for me to see what's happening, where, and how it's being resolved.

And me?

Mostly, I watched them work. The two sessions pass the work back and forth on their own: spec, implementation, review, fixes, verification.

My job is the one I wrote about in my last post: deciding what's worth keeping. Each spec ends in a single change, and I review that change before it lands. Not to proofread every line (the sessions already did two passes on the diff), but to judge whether it's what I wanted, and to read the comments that explain why the code looks the way it does.

One PM, several projects

The part I didn't expect is how well the PM role scales sideways. The PM doesn't have to stay on one project: it can write three specs for one, move to the next project and write three more there, then switch again. The engineer sessions always have a spec waiting, and several projects move forward at once. The token bill goes up with it, but for the amount of work that gets done, it's a cost I find reasonable.

It works best when the project has clear edges. rind-ui is a good example: a complete headless component library, plus a library that makes it easier to test components built on top of it. The scope is defined, the agent knows what to do, and not many decisions are left open. When one is, the PM doesn't guess: it asks me.

If you want to try it: watch the tokens

One warning before you copy this. Two sessions reviewing each other's work produce good results, but they're expensive: every spec gets written, implemented, reviewed, fixed and verified, and each step reads a lot of code. I've run out of tokens more than once doing this.

What I'd do differently from the start: tell both sessions, the PM and the engineer, to use a lighter model such as Sonnet for the less complex parts, and keep the strongest model for the steps that need judgment, like writing the spec and the review itself.

Where it is now

Along the way the two sessions became three: a third one joined and built the documentation site. You can see the result at rind.watermelon-studio.it, with live examples for every component, React for now.

The library is already on npm, and it changes every day: new components land as their specs go through the loop, and many more are already specced. If it keeps working the way it has, I'll write the follow-up when there's more to show.

If you want to try the review side of this yourself, the Reado app is free and MIT-licensed: download it here.