triangulated-build

Triangulated Build

A cross-family adversarial build pipeline for Claude Code — a single skill that composes other skills.

/triangulated-build runs one work item through a build ceremony where three independent model families participate, so that no single model is both the sole author and the sole judge of its own work. Opus orchestrates and synthesizes; Fable 5 authors the plan and the code; and a panel of Claude personas, Codex, and a Fable reviewer cross-check at the planning and code gates. A closing retrospective scores the run and tunes the pipeline itself.

It is manual-invocation only — a heavyweight ceremony you opt into deliberately for risky changes, not a default for every commit.

The idea: skills are composable

Claude Code skills aren't islands. The interesting move is treating them as components you wire together. This skill is that wiring:

• Compound Engineering (the compound-engineering plugin for Claude Code) supplies the spine — ce-brainstorm → ce-plan → ce-doc-review → ce-work → ce-code-review, the worktree-per-item discipline, and the "every learning compounds" philosophy.
• The Codex plugin for Claude Code supplies a reviewer from a different model lineage entirely.
• Triangulated Build is the orchestration layer on top: it keeps Opus in the orchestrator seat, hands authoring to a second family, and fans the review gates out across all three — then synthesizes the findings into one decision and logs what it learned.

The whole thing is ~250 lines of Markdown. The leverage isn't new code; it's the composition.

Why cross-family review (the synergy)

A model reviewing its own output shares its own blind spots. A panel of personas that authored the work — or that share a family with the author — tends to converge on the same gaps and rubber-stamp them. Agreement among similar models is corroborating evidence, never a filter.

The load-bearing catches in a triangulated build repeatedly come from the different-family engine flagging exactly the hole a same-family panel passed. The canonical shape:

An eight-persona same-family review panel — correctness, security, adversarial all included — passes a money-parsing control. The different-family engine is the one that catches the real bug.

That's the synergy this skill is built to capture. Cross-family adversarial review isn't redundancy; it's coverage of failure modes a single family is structurally blind to. The cost is more agents per item. The return is defects caught before production. So you match the ceremony to the risk — full triple-engine for schema/auth/payments/multi-file changes, a trimmed two-engine pass for tiny low-surface diffs (see Calibration).

The three roles

The locked mechanic: the session model stays Opus the entire time — there's no /model toggling, because that would make the orchestrator itself the author and collapse the role separation. Fable shows up only as model-pinned subagents.

The pipeline at a glance

Each work item gets its own worktree and its own PR:

1. Worktree + declare tier (FULL / TRIMMED)
2. Brainstorm        — /ce-brainstorm (only if scope is genuinely open)
3. Plan              — Fable writes the plan document
4. Plan review  ×3   — /ce-doc-review (Claude) + Codex + Fable grounded reviewer
5. Synthesize        — Opus merges findings → Fable fixes the plan
                       → note the feature's load-bearing invariant(s)
6. Work              — Fable implements in the worktree; Opus verifies
7. Code review  ×3   — /ce-code-review (Claude) + Codex (job-API) + Fable
                       reviewer, in parallel; invariants become Codex's focus text
8. Synthesize + ship — Opus merges → Fable fixes → re-verify → PR → merge
9. Retrospective     — score each engine's unique catches, tune the skill, log it

The full stage-by-stage spec, the synthesis rules, and the calibration thresholds live in SKILL.md.

Synthesis is the product

Stage-5 and Stage-8 synthesis is where the real saves happen. The rules that matter most:

• Invariant re-rating — a finding any engine files as a "residual risk" that nonetheless violates a load-bearing invariant named in the plan is a P-finding. Don't inherit a persona's severity when it conflicts with the safety contract.
• Minority-report rule — one engine alone flagging a safety/data/auth issue is the expected shape of a real cross-family catch, not noise. Never drop it just because the others were silent.
• No drop without verification — before dismissing any engine's finding as a false positive, verify it against the actual files.

Calibration

The pipeline is a default, not a straitjacket. Domain beats size — a 9-line auth change is small but still runs the full ceremony; a 50-line copy tweak with no new surface runs trimmed. You declare the tier before creating the worktree, with the trigger values, so the choice is deliberate rather than a silent default.

The compounding loop (retros + ledger)

A fixed pipeline is only worth having if it learns. Stage 9 isn't optional: after each item, the skill writes a dated retro (retros/<date>-<item>.md) tallying what each engine raised and — the number that actually matters — how many unique catches each engine produced (a real finding one engine raised that the others missed). It also appends one fixed-schema row to a retros/LEDGER.md so the trends become computable: per-engine hit rates, cost per tier, whether the third engine is still earning its slot. The prose retro explains why; the ledger computes whether.

Note on this repo: the retros and ledger are intentionally not published here — the real ones log private client work (bugs, business invariants, costs). The mechanism is documented above and in SKILL.md; the entries stay private. When you run the skill, your own retros/ directory accumulates locally.

Origin & caveats — Fable as the third leg

This framework is engine-agnostic, but it wasn't designed in the abstract. The reference build used a specific cast: Opus orchestrating, Fable 5 as the author/worker, and Codex + Claude personas + a Fable reviewer at the gates.

Fable was the third leg for a concrete, time-boxed reason. While Fable 5 was still inside the Claude subscription, this pipeline was the instrument for measuring what Fable actually costs — both as a builder (authoring plans and code is the token-heavy role) and as a reviewer (the cheap role). The skill captures per-role subagent_tokens on every run and projects a blended-rate dollar figure, specifically so that when Fable moved off the subscription onto separate metered billing, the monthly cost at the current cadence would be a known multiplication, not a surprise. That's why there's a whole "Token & cost tracking" section and a cost model at the head of the ledger — it's a by-product of using a subscription window to price a model before the meter started.

So read the Fable-specific parts as the reference implementation, not a requirement:

• The "author family" is a swap point — any capable different-family model can author.
• The "third reviewer" is a swap point — Codex is one choice; the principle is a model from a lineage different from the author's.
• The cost-tracking machinery only matters if your author family is billed per-token. If it's flat-rate or in-subscription, that stage is informational.

A few honest limitations:

• It's expensive. Three families, two gates, multiple subagents per item. That's the point, and it's why it's manual-invoke and tier-calibrated — don't run the full ceremony on a typo fix.
• It's not a silver bullet. It catches a class of defect (same-family blind spots) that single-model review misses. It doesn't replace tests, types, or human radius checks — it feeds them.
• It's a personal tool, published as a reference. It encodes the conventions of the codebases it grew up in. Expect to retune the calibration thresholds and the project-deferral hooks for your own stack.

Requirements

• Claude Code with access to the orchestrator + author model families used in your configuration.
• The compound-engineering plugin — provides the ce-* skills the pipeline composes.
• The Codex plugin for Claude Code — provides the different-family reviewer at the code gate (optional if you skip Codex; the skill degrades gracefully to a two-family pass).

Install

Drop the skill into your Claude Code skills directory:

git clone https://github.com/Konkag/triangulated-build.git
mkdir -p ~/.claude/skills/triangulated-build
cp triangulated-build/SKILL.md ~/.claude/skills/triangulated-build/SKILL.md

Then invoke it explicitly by name in a session:

/triangulated-build

It will only fire on an explicit, by-name request — it never auto-triggers from a generic "build X" or "ship X" prompt.

License

MIT © 2026 Konstantin Kaganovich

Built by composing the Compound Engineering and Codex plugins for Claude Code. Triangulated Build is an independent project and is not affiliated with or endorsed by Anthropic, Every, or OpenAI.