review-duo
Skill255 starsChanged 17 days agoMITView on GitHub
Review a defined code change with two Thread members independently checking standards, quality and requirements. Applies to the initiator and invited reviewer through the final report; excludes solo review, undefined scope and implementation-only requests.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- analyze-agent-codebaseSkill
- campfireSkill
- cli-operationsSkill
- diagnosing-bugsSkill
- grill-duoSkill
- grill-duo-with-docsSkill
- member-studioSkill
- memory-stewardshipSkill
- tddSkill
- worktreeSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Read Snapshot. Freeze the code range, requirements/acceptance sources, repository rules and coverage limits.
- Distinctive: line 38
Keep a successfully invited partner unless unavailable or delivery fails.
- Distinctive: line 40
No partner: disclose solo review on both axes if the user permits it.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Review Duo
Review the same fixed input on two independent axes: the partner owns Standards and quality; the initiator owns Spec compliance. Use the user's language for reports and template headings.
Review is read-only by default. It does not itself authorize fixes, Tasks, commits, pushes or PR updates. If the user also requested fixes, finish the report first.
Establish the review
Use trusted Core/Runtime identity and direct request/reply relationships. Choose one available Thread partner other than yourself and address their trusted Agent ID. Accept only their direct reply to the current valid request with the identical fixed scope. Titles and scope text do not prove sender identity. One initiator may run one unfinished Review Duo per Thread.
Read Snapshot. Freeze the code range, requirements/acceptance sources, repository rules and coverage limits. Missing requirements make Spec not_assessed; missing stable code input requires a commit range or shared fixed patch before a full duo review.
Independent axes
- Standards: repository rules, correctness, error handling, consistency, concurrency, retry, security, APIs, databases, migrations, lifecycle, material test gaps and maintenance cost. Do not judge product requirement coverage.
- Spec: missing, partial or incorrect requirements, acceptance conditions, unrequested behavior and conflicting/insufficient requirement sources. Do not invent requirements from implementation or treat style as a Spec defect.
The request contains no initiator conclusions. Finish and publish Spec before incorporating the partner's findings. Use Findings for bounds and report shape.
Four messages
- Initiator sends the fixed scope, sources, limits and Standards assignment to the partner with
rovai send --to <partner-agent-id> --body <request>, then independently reviews Spec in the same Run. - Initiator publishes the complete Spec result and identical scope with
rovai send --public-only --body <spec-result>, then ends while waiting. - Partner returns one complete Standards result and identical scope to the trusted requester with
rovai send --to <requester-agent-id> --body <standards-result>. - Initiator verifies partner, direct reply, scope and assignment, then publishes one final report with
rovai send --public-only --body <report>.
Inspect actual recipients. Escape or fence literal @ code/quotes. Only successful messages can support later steps; success does not mean the recipient has finished. Process other current batch inputs normally.
Preserve each axis's finding content, IDs, severity and order. The same behavior may appear on both axes. Present Standards before Spec, with no combined score.
Completion and fallback
Keep a successfully invited partner unless unavailable or delivery fails; after replacement, accept only the new partner's direct reply to the new request. Old results are supplementary.
- No partner: disclose solo review on both axes if the user permits it; stop if two members are required.
- Partner cannot read the snapshot: replace once or stop; do not switch to live branch content.
- Missing requirements: continue Standards and mark Spec
not_assessed. - Code or source scope changes: mark the old report
stale; start a new review if current results are needed. - User cancels/replaces the objective: close the old review.
The final report closes this review. Duplicate, old-partner and late results do not trigger another final report.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

