Developer splits Claude Code sessions into PM and engineer roles that trade specs and reviews

How the two-role setup works

Claude Code sessions have been able to communicate with each other since August through a feature called cross-session messaging, which shipped in version 2.1.224, according to a post on dev.to. A session finds its peers with a ListAgents call and sends them text via SendMessage. Only the text Claude composes for the other session travels — never the conversation history or files.

The post's author applied this to rind-ui, a headless UI component library, by assigning two sessions different jobs defined in the repository's CLAUDE.md. One session plays the PM: it writes each component as a spec — an OpenSpec change with requirements, scenarios and tasks — and validates that spec before any code exists. The other plays the engineer: it implements a single spec and, once it considers the work complete, messages the PM to request a review, listing every file it touched.

Neither session holds the other's context; each sees the repository plus whatever messages it receives. The author considers that an advantage: because the reviewer never sees the implementer's reasoning, it approaches the code cold, closer to how a future maintainer would.

Rules that make the loop end

The workflow's first version allowed three review rounds per change. The author has tightened that to two, on the grounds that a reviewer told to hunt for problems will keep finding them indefinitely, so the loop needs an explicit endpoint.

Findings now carry one of three severities: critical (breaks behaviour, data, security or accessibility), error (violates a spec requirement, or a real bug) and warning (everything else, from weak tests to polish). Only critical and error findings are fixed immediately; warnings land in a backlog file, docs/review-backlog.md. Each change gets two passes, both scoped to the change's own diff rather than the whole repository — a review whose critical and error findings become tasks, then a verification pass after the fixes. New issues surfaced during verification go to the backlog unless they are critical to building the rest.

Findings anchored to lines

The post appears on the blog of Reado, an IDE positioned as a tool for reading agent-written code, and that product sits at the centre of the workflow. Rather than posting findings in chat, the PM leaves them as Reado comments anchored to exact lines, each typed (bug, refactor, performance) and marked as a task. They are stored as Markdown files in a .reado/ directory inside the repository, giving both sessions — and the human — one shared list.

The engineer closes each task with a task-done command paired with a --verify test command, and Reado records the task as complete only if that check passes; an unproven fix stays flagged as unverified. The author reports 128 tasks so far — 115 bugs, 5 refactors, 3 performance issues and 5 notes — all closed by a passing verify command.

The human's own role has narrowed accordingly: the sessions cycle through spec, implementation, review, fixes and verification on their own, while the author judges whether each finished change should actually land.

Costs, scope and sideways scaling

Two caveats accompany the pattern. The first is cost. Every spec gets written, implemented, reviewed, fixed and verified, and each step reads a lot of code; the author reports running out of tokens more than once. The retrospective advice is to route less demanding steps to a cheaper model such as Sonnet and reserve the strongest model for judgment-heavy work like writing specs and performing reviews.

The second is scope. The setup reportedly works best on projects with well-defined scope — rind-ui qualifies as a complete component library plus a testing companion — because few decisions stay open. When one does, the PM asks the human rather than guessing.

The PM role also stretched sideways beyond expectation: a single PM session can write specs for several projects in turn, keeping multiple engineer sessions supplied with work. A third session eventually joined the original two to build the documentation site, and the library is published on npm.

Why it matters

Cross-session messaging turns Claude Code from a single agent into something resembling a small team with assigned roles. This is one developer's account rather than a benchmark, and it comes from an author publishing on Reado's own blog, but it sketches a concrete governance pattern for multi-agent coding: separated context for unbiased review, severity rules that force review loops to terminate, and fixes proven by commands rather than self-reported claims. The token bill the author repeatedly ran into is the practical limit on how widely the pattern can spread.