| name | cross-tier-review |
| description | Cross-tier review protocol — chain of verification for REVIEW REQUEST messages from Claude Code (Tier 2). Includes 5-step checklist and REVIEW_JSON output format. |
| allowed-tools | Bash |
| user-invocable | false |
| metadata | {"openclaw":{"always":true}} |
Cross-Tier Review Protocol — Chain of Verification
When you see "REVIEW REQUEST:" in an infra room, Claude Code (Tier 2) is asking you
to review its work because its confidence was below 0.7. You MUST perform a structured
verification before giving your verdict.
Verification Checklist (execute ALL steps)
- CLAIM CHECK: What factual claims does the analysis make? Use the
exec tool to
independently verify at least ONE claim (e.g., check a service status, query YT issue,
look up a host in NetBox). Do NOT just read and agree.
- ASSUMPTION CHECK: What assumptions are implicit? Flag any that are unsupported
by evidence in the analysis.
- ALTERNATIVE CHECK: What alternative root causes were NOT considered? Name at
least one plausible alternative, even if you think Claude's diagnosis is correct.
- RISK CHECK: Could the proposed action cause secondary failures? Check for
dependencies (e.g., will restarting X affect Y? Does draining node Z displace SeaweedFS pods?).
- RECURRENCE CHECK: If this host/alert has a knowledge base entry, does the proposed
fix address the root cause or just patch the symptom again?
Verdict
After verification, reply with ONE of:
- REVIEW: AGREE — brief reason why the analysis looks correct after verification
- REVIEW: DISAGREE — specific issue found (wrong root cause, unsafe action, missing evidence)
- REVIEW: AUGMENT — additional context to add (things Claude missed, alternative causes)
After your verdict line, output a structured JSON block so the gateway can parse it:
REVIEW_JSON:{"verdict":"AGREE|DISAGREE|AUGMENT","confidence":0.X,"reason":"one-line reason","issueId":"IFRNLLEI01PRD-XXX","claims_verified":1,"alternatives_considered":1}
Rules
- ALWAYS verify at least one claim via exec before giving your verdict
- If confidence was < 0.5, pay extra attention to hallucinated fixes
- If you find the proposed action could cause secondary failures, ALWAYS DISAGREE
- Do NOT escalate review requests. This is YOUR job as independent critic.
Dev Task Reviews (CUBEOS/MESHSAT)
For development review requests, adjust the checklist:
- CLAIM CHECK: Verify at least one code claim via codegraph-lookup
- TEST CHECK: Were tests run? Did they pass?
- SCOPE CHECK: Did the changes stay within the issue scope?
- RISK CHECK: Could changes break other modules?
- CONVENTION CHECK: Does the code follow project conventions?
