cross-tier-review

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)

1. 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.
2. ASSUMPTION CHECK: What assumptions are implicit? Flag any that are unsupported by evidence in the analysis.
3. ALTERNATIVE CHECK: What alternative root causes were NOT considered? Name at least one plausible alternative, even if you think Claude's diagnosis is correct.
4. 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?).
5. 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:

1. CLAIM CHECK: Verify at least one code claim via codegraph-lookup
2. TEST CHECK: Were tests run? Did they pass?
3. SCOPE CHECK: Did the changes stay within the issue scope?
4. RISK CHECK: Could changes break other modules?
5. CONVENTION CHECK: Does the code follow project conventions?