Rekkkt Make sure your using a second model to review when vibe coding. I’ll write my response with Claude lol. This would be a skill for Claude to trigger codex review, the skill might be using terra though you can change it to use Sol. If you use codex to code your just make the inverse skill basically to trigger Claude. ——- “Second model catches what the first one missed — no shared blind spots, and it’s not defending its own code. Read-only is the key part. It reads the diff, that’s it. Can’t write, commit, or “helpfully fix” anything. Checks correctness and security first, style last, and every finding needs a file:line — so no page of naming nits while a real bug sits there. Second opinion that can’t touch anything” You can tell it to loop until approved, be safe have fun. ——— Here’s the skill, hope you understand skills and aren’t that big of a fish. If you aren’t using GitHub and just using local then edit the skill however you want this is just the one I made and tweaked over half a year --- name: codex-readonly-review description: Perform a strictly read-only review of a codebase, diff, or PR. Use when the user invokes /codex-readonly-review, or asks for a code review, audit, or second opinion where nothing should be modified. Never edits, stages, commits, or runs mutating commands. --- # Codex Read-Only Review ## Hard constraints Read-only means read-only. Allowed: `ls`, `cat`, `rg`, `git log`, `git diff`, `git show`, `git status`, test runners in report-only mode. Forbidden, without exception: - Any file write, create, move, or delete - `git add`, `commit`, `checkout`, `stash`, `reset`, `push`, `rebase` - Package installs, migrations, formatters, linters with `--fix` - Anything touching a remote or a database If a fix requires a change, describe the change. Do not make it. If the user later asks for edits, say the skill is read-only and offer to proceed outside it. ## Scope Determine the target before reading: 1. Explicit path or PR the user named 2. Otherwise `git diff` against the base branch (ask which if ambiguous) 3. Otherwise the working tree, most-recently-changed files first State the scope in one line before reviewing. Don't review the whole repo when the user meant one diff. ## Review passes Run these in order. Stop early if a pass finds a blocker. 1. **Correctness** — logic errors, off-by-one, null/undefined paths, unhandled error branches, race conditions, incorrect async handling. 2. **Security** — injection, unvalidated input, secrets in source, authz gaps, unsafe deserialization, dependency risk. 3. **Data safety** — destructive operations without guards, missing transactions, migrations that lose data. 4. **Interface** — breaking API/signature changes, backward compatibility, error contracts. 5. **Tests** — coverage of the changed paths, tests asserting nothing, tests that would pass on a broken implementation. 6. **Maintainability** — duplication, dead code, naming, complexity. Lowest priority. Never lead with style. ## Output ``` SCOPE: VERDICT: ship | ship with fixes | do not ship BLOCKERS - — → SHOULD FIX - — → CONSIDER - — NOT REVIEWED - ``` Every finding needs a concrete file and line. Drop any bullet you can't anchor. If a pass turns up nothing, omit its findings rather than padding with generic advice. ## Calibration - No blockers is a valid result. Say so plainly. - Flag uncertainty as uncertainty: "this looks wrong if `x` can be null — I couldn't confirm the caller." - Don't invent severity to seem thorough. - Don't restate what the code does. Reviews say what's wrong.

989

Christoph · Aug 19, 2026 · 4:43 PM UTC

Christoph

@ChrisOnCodeAug 19

Replying to @elonmusk @grok @bot

One of the biggest advantages of using Claude and Codex together is having one review the other’s work. It makes it much easier to run longer autonomous loops without constantly checking in. Can Grok bot support a second model like Claude or Codex as an independent reviewer? In my experience, single-model loops tend to let more bugs slip through.

101

Patrick Leonard 🫡 · Aug 17, 2026 · 8:37 PM UTC

Christoph retweeted

Patrick Leonard 🫡

@padspokerAug 17

I think one of the most important skills you can have in poker is being really good at changing your mind. Poker players spend so much time trying to be right. We debate hands, defend our lines, argue about strategies and sometimes attach way too much of our ego to whether our original opinion was correct. But I think the best players I've been around are almost the opposite. They can passionately believe something on Monday, see better evidence on Tuesday and by Wednesday they've completely abandoned the idea. No ego. No trying to justify why they were kind of right. No moving the goalposts. Just "yeah, I was wrong." I think that's an incredibly powerful skill. Poker changes so quickly and there's so much information that it's almost impossible for everything you believe today to still be correct in a few years. I've had strategies that I was absolutely convinced were good, probably taught them to other people with huge conviction, and then six months later realised I was completely wrong. I don't think that's embarrassing. I actually think being able to do that is one of the reasons I've managed to keep improving. The dangerous player isn't the one who gets things wrong. Everybody gets things wrong. The dangerous player is the one who needs to keep being right after the evidence has changed. Your job isn't to defend the player you were yesterday. Your job is to make the player you are tomorrow better. So have conviction in what you believe. Argue your side. Try to prove it. Challenge other people's ideas. But when somebody shows you something better, don't fight to protect your old opinion. Steal theirs. Being wrong for one day costs you nothing. Being too stubborn to change your mind can cost you years.

408

43,956