Proposal: trinity / trinity-ultra — multi-provider consensus review skills for .codex/skills

Open 💬 0 comments Opened Jul 17, 2026 by lotar

Proposal

Two repo-scope skills for .codex/skills/, following the existing dogfood pattern (babysit-pr, code-review): a multi-provider consensus review gate.

  • trinity — standard tier. A change is gated through three independent reviewer lanes at two checkpoints: three lanes critique the plan before code is written (Phase B), then three lanes validate git diff <base>...HEAD against the plan before it lands (Phase C). Lanes: a Codex host subagent (xhigh reasoning), the Grok CLI (grok-4.5 --reasoning-effort xhigh), and the Claude CLI (claude -p --model sonnet). Any single BLOCK fails the gate.
  • trinity-ultra — maximum tier: host as gpt-5.6-sol at reasoning effort ultra, grok-4.5 at xhigh, claude -p --model opus.

Design properties:

  • Strict single-line JSON verdict contract with a full-schema jq check (object type, allowed verdicts, array-typed fields, blockers-empty-unless-BLOCK, ERROR-only fallback fields) — schema violations route through a retry → ERROR → fallback ladder, never a silent pass.
  • An unavailable/failed external CLI degrades to a visibly labeled Codex host fallback lane (fallbackFor provenance, conductor-applied); a degraded run never claims full three-provider diversity.
  • Bounded revision loop (2 passes) that escalates unresolved 3-way disagreement to the user instead of auto-picking a side.
  • User-invoked only (policy.allow_implicit_invocation: false in the agents/openai.yaml sidecars) — it is an expensive gate and never fires implicitly.
  • Self-contained single-file skills: prompt templates inline, no sidecar prompt files, no hardcoded user paths, $HOME-only PATH bootstrap.

Ready-made implementation

Branch (4 files, +~530 lines, no code changes outside .codex/skills/):
https://github.com/lotar/codex/tree/feat/trinity-consensus-skills

Verified against this repo's loader (v0.144.3): frontmatter uses exactly the SkillFrontmatter fields (core-skills/src/loader.rs:59-73), sidecars match SkillMetadataFile, and codex debug prompt-input confirms discovery — including that the allow_implicit_invocation: false policy correctly keeps the skills out of implicit prompt injection (verified by flipping the flag both ways).

Proof of worth

We ate the dog food: the skill pack itself was gated through the same consensus process before this proposal — three reviewer lanes (Claude Fable at max effort, gpt-5.6-sol at ultra via codex exec, grok-4.5 at xhigh via the Grok CLI) validated the diff against a written plan across 8 checksum-pinned iterations. The gate surfaced and forced fixes for 11 real defects before publication, including: a documented pipeline that validated an unset shell variable, a heredoc delimiter-collision that could execute payload as shell, a fallback that would have critiqued the plan instead of validating the diff in Phase C, and a schema check that accepted null-typed fields. Final verdicts on the published SHA: Fable AGREE; Sol and Grok-4.5 lanes hit provider timeouts on the last confirmation pass and were replaced by labeled fallback lanes per the skill's own contract (CONCERNS, non-blocking) — an honest live demonstration of the degraded-mode design working as specified.

Happy to adjust naming, placement, or scope, split the two skills, or park this as a community example — whatever fits the roadmap. Per the contributing policy, no PR has been opened; the branch is ready if the team wants to invite one.

---
Contributed by Mladen Lotar (@lotar); implementation and validation orchestrated by Claude (Fable 5, Claude Code).

View original on GitHub ↗