The example and its scope
Orbit is a separate tutorial project with index.html and three local text download fixtures. It contains no real installer. Dingding implements the page; Cheese reviews it with a read-only Agent configuration. Both use the same project files.
Use one teammate when the goal is small and you can inspect the result yourself. Split implementation and review when you want an independent check against stated acceptance criteria. For concurrent work, assign different files or a read-only review; avoid two writers changing the same file at once.
The collaboration sequence
Prepare two participants
- In Teammates, give the implementer and reviewer distinct roles and save their Agent configuration.
- Create a conversation for the independent Orbit folder, select Dingding and Cheese and choose Dingding as lead.
- Open Team in the conversation header to verify participation. The global roster and this conversation’s participant list are separate.
- Agree on the scope: Dingding may edit the page and checks; Cheese reviews without editing. Keep both requests in this conversation.
Request the implementation
Improve the Orbit download page. Show separate Apple Silicon, Intel and Windows x64 choices, each linked to its existing downloads/orbit-*.txt fixture. Clearly label these as tutorial files, not installers. Add matching notes, a responsive layout and visible keyboard focus. Work only in this project. Check the actual links and markup, then report changed files, checks performed and remaining limitations.
Select the actual recipient
Follow the real execution
Read the implementation handoff
This run changed index.html and added styles.css and verify.mjs. It passed node verify.mjs, node --check verify.mjs and git diff --check. The original download text fixtures were retained.
The implementer reported that Chrome access was denied, so it did not claim a visual browser check. It also reported a failure from the explicit message-send command; the final response still appeared in the conversation. These limitations remain part of this run’s record.
Ask for an independent review
Independently review the current Orbit changes. Check platform labels, fixture links, basic HTML accessibility, keyboard focus and narrow-screen rules. Read files and run existing checks; do not edit. Report concrete findings with file locations. If there are no findings, say so. Distinguish code inspection from browser checks actually performed.
The user chooses the next teammate
The actual review finding
A bounded follow-up
Verify the reported footer contrast in the actual CSS. If confirmed, darken only that text color to at least 4.5:1 and add a numeric check to verify.mjs. Re-run the existing checks. Do not redesign, commit or publish. Report the before/after ratio and changed files.
Inspect the repair and delivery
Accept what was actually verified
The final delivery includes index.html, styles.css, verify.mjs and the three retained text fixtures. The documentation capture independently reran the Node checks successfully. The Agent’s earlier browser-access denial remains part of the record.
If your own review finds no issue, stop at the accepted result. Do not invent a defect to make the workflow look complete. For another change, send a new request with the current facts and preserve the earlier record.
Decide from the review, then inspect files
Read the actual review before deciding on another edit. A confirmed defect calls for a narrow follow-up addressed to the implementer; a suggestion may need a product decision. If no defect is found, inspect the delivery rather than inventing a repair round.
Open Files Changed below the implementation reply and inspect the changed paths and lines. Open index.html in a browser to inspect the delivered page. A successful Run or a reviewer’s answer is not a merge or a release.
Who receives the next message?
- No explicit recipient
- Normally the lead receives it. After you explicitly address one non-lead teammate, the composer may show “Send to continue” for that teammate. Check the visible routing hint; cancel continuation to return to normal routing.
- One or several selected teammates
- Each selected recipient gets work from the same message. Multiple recipients do not establish an implementation-then-review order. If order matters, wait for the first result and send the next request yourself.
- Reply to a teammate
- Reply adds the original message reference and, while its author is an available participant, inserts that teammate as a recipient. Check all selected mentions; existing recipients can remain. If the author is unavailable, choose a replacement.
- Reply to your own or a system message
- The reference supplies context. It is not an Agent recipient; choose whom to ask and check the composer’s route.
- Default lead
- Provides a default recipient and has task-responsibility powers defined by the product. The title does not promise automatic planning or assignment of every request.
- Agent-to-agent handoff
- An Agent can use Rovai’s explicit send capability to address another present teammate with continuing work. Check the displayed recipients and the following execution. A name in ordinary narration, a thank-you or “ready for review” alone is not proof of a handoff.
Resume this work later
Reopen the same conversation, read the latest delivery and outstanding Task, and state what has changed since then. Use a new message to define the remaining work.
Save only a durable agreement as memory, such as the project’s platform naming. Temporary review instructions and this run’s completion status belong in the conversation or Task.
Open the delivered page in Rovai
