critiquelisted

# Cross-model critique A second pair of eyes from a non-Claude model (Codex) on a proposal **Claude just made** — a design, refactor, API, or fix. Goal: a genuine cross-model check. Validate what holds up, challenge what is weak, surface a better path when one exists. Not a rubber stamp, not reflexive contrarianism. ## When to use - Claude (this instance or another) proposed a solution and you want it pressure-tested before committing. - You said "not bad, right?" and actually want the honest answer. - A decision has real forks and one outside viewpoint would de-risk it. NOT for reviewing committed code against a diff — use `/codex:review` or `/codex:adversarial-review`. Those read the **git diff**; a proposal usually lives in the conversation, not on disk, so a diff-based review would miss it (and may review unrelated working-tree files instead). ## Workflow 1. **Capture the proposal — grounded.** Write to one temp file: the proposal verbatim, the problem it solves, any constraints, the questions you most want challenged, an explicit list of the **real repo file paths** it touches or depends on, and — if the user gave extra focus with the invocation — a final `## Extra focus from the user` section carrying it verbatim. Grounding in actual code is the one thing that makes the critique useful; skip it and the review drifts into generic advice. Everything user-authored goes in the file, never inline in the shell command (quotes/backticks break inlin