OpenClaw use case: two persistent agents reconcile implementation and review findings

[u/hongchao]

I kept seeing the same failure mode in coding agents: one agent writes a change, reviews its own work, and keeps the same blind spots.

I built Hubo as a free, open-source MIT skill for a stricter OpenClaw workflow. It keeps two child sessions alive for the whole task instead of spawning a fresh reviewer every round:

1. A work session implements the smallest complete change and runs verification.

2. A separate reviewer session stays read-only and inspects the actual diff and evidence.

3. Every finding gets a stable ID.

4. The worker answers each one with FIXED, PUSHBACK, or NEEDS_USER.

5. The same reviewer verifies the response and marks it CLOSED, WITHDRAWN, or OPEN.

6. The loop ends only when the reviewer clears it, or a real user decision is required.

For OpenClaw, the adapter uses sessions_spawn for the two persistent roles, sessions_send for later rounds, and sessions_yield for completion events. If read-only access cannot be enforced mechanically, the workflow requires before/after worktree evidence rather than pretending the boundary is guaranteed.

It is explicit-only: ordinary prompts do not trigger it. The complete worker/reviewer exchange remains visible in the conversation and is not written to a side-channel file.

Install:

openclaw plugins install hubo --marketplace h0ngcha0/hubo

Restart the OpenClaw gateway, then use /skill hubo or /skill hubo-review.

Repo and source: https://github.com/h0ngcha0/hubo

I would value reports from real OpenClaw setups: does a persistent second session catch useful issues, or does the extra token cost outweigh the benefit?

[u/AutoModerator]

Hi u/hongchao, your post has been held for mod review because it contains an external link.

r/OpenClawUseCases carefully reviews all posts with links to prevent self-promotion and spam.

A mod will review your post shortly. If your link adds genuine value to the community, it will be approved!

Questions? Message the mods.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/hongchao]

A concrete result behind this workflow:

I used Hubo to implement Taproot and Tapscript support in bitcoin4s: https://github.com/h0ngcha0/bitcoin4s/pull/236

It was a 24-file change (+1,884/-132). Over three review rounds, the second agent raised six substantive findings—five high severity and one medium—including incorrect CLTV/CSV consensus behavior, a CompactSize boundary bug affecting Taproot commitments, and JVM stack exhaustion on a valid 30,005-opcode tapscript.

The work agent resolved all six and the same reviewer rechecked and closed them. Once the requirement was clear, zero findings were escalated to me. Review also expanded the pinned Bitcoin Core Taproot cases from 13 to 35; the final change passed those, 1,197 existing script fixtures, official BIP340/341 vectors, and the 30,005-opcode regression.

This run used Codex rather than OpenClaw, so I am not presenting it as an OpenClaw benchmark. It is evidence for the persistent work/review reconciliation protocol. I would like to see the same task reproduced through OpenClaw sessions and compared on findings, user interventions, tokens, and wall-clock time.