Menu
Shared protocol for review-shaped actions, authorization scope, defect routing, L2 audit handling, and local-only capture.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when the user asks to "test TPC-H", "check compliance", "review architecture", "run quality checks", "check binaries", "test dialect translation", "compare implementations", "run live platform tests", or "plan and execute" a benchmark feature.
Use for "commit code", "review code", "fix lint/type error", "improve performance", "compare code", "shrink code", "generate spec from code", "investigate code", "debug an error", "triage a bug", "iterate to green", or "create handoff prompt".
Use when the user asks to "create documentation", "build docs", "review docs", "compare documents", "compress docs", "adversarial review docs", or "commit docs".
Use when the user asks to "sync skills", "set up skill-sync", "check skill status", "validate skills", "preview skill changes", "diagnose skills", "pin a skill", "unpin a skill", "prune skills", or "promote skill changes".
Use when the user asks to "run tests", "create tests", "fix failing test", "add test coverage", "fix slow tests", or "commit test changes".
Consolidate accumulated permission grants across Claude Code, Codex, and Gemini: move trusted commands into project settings, clean garbage entries, verify cross-agent consistency, commit project-level configs.
| name | review-protocol |
| description | Shared protocol for review-shaped actions, authorization scope, defect routing, L2 audit handling, and local-only capture. |
Governs code reviews, audits, research, compare, to-spec, security reviews, and L2 blind-spot audits. If a wrapper conflicts with this file, this file wins.
Review-shaped actions are read-only plus local capture. They may read code, run analyses, produce findings, and write capture files to designated TODO/blind-spot/audit/decision/handoff locations.
They must not, as a side effect:
make pr-open / gh pr create.A later request to fix/address review findings is write authorization; follow the normal project commit/PR flow.
Capture authorizes only the local file write. Final terminal action is a chat line such as Recorded: <path>; the user decides whether to PR.
For findings specifically: the only authorized capture write is the append-only draft file under ~/.benchbox/finding-drafts/; writing a finding straight into the hosted tracker DB during review is forbidden (it lands with no PR cycle). todo finding sync is a separate, user-authorized landing step, never part of the review.
For verification, run only commands the review scope demands. Long output goes to a temp log; cite paths/lines, do not paste large source blocks or command output.
Before classifying a finding, ask: if left as-is, will the observed code behave incorrectly, leak data, or miss a performance budget?
If yes, it is a defect. Defects belong in the severity table/action items and may become a TODO/fix only after authorization. They do not belong in blind-spots. Treat uncertain cases as defects; over-capturing TODOs is safer than degrading blind-spot signal.
Layer 2 asks what class of issue the review framework failed to catch. It captures framework gaps, not the instance-level defects already found.
Projects provide storage locations/specs and sweep workflows. This protocol governs behavior; project docs govern storage format. Do not duplicate behavior rules in storage docs.