06-reference/research

gbrain adopt port build tradeoff

2026-07-14·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
harness-engineeringgbrainskill-registryadopt-vs-buildgarry-tan

GBrain: Adopt, Port, or Build — the Skill-Registry Verification Path for RDCO's Harness

The question

Should RDCO adopt Garry Tan's GBrain directly, port concepts to our existing skill registry, or build our own equivalent from scratch — what's the maintenance-burden + dependency-risk tradeoff across the three options, and which of the 8 missing checklist steps (unit tests, integration tests, LLM evals, resolver eval, check-resolvable, DRY audit, E2E smoke, brain filing rules) does each option ship fastest? Context: the skillify-it brief flags this as a "decision worth making explicitly"; RDCO sits at steps 1-2 of Tan's 10-step gating, and the path choice sets the next 4-8 weeks of L5-unhobbling harness work.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Recommendation: PORT (hybrid), don't adopt, don't fully build. The maintenance-burden × dependency-risk matrix is decisive. Adopt directly is the worst fit despite being "meaningfully faster" on paper: GBrain's checklist layer is coupled to OpenClaw/Hermes + a Postgres/Bun substrate RDCO doesn't run, so the "30-minute install" becomes weeks of MCP wiring, and you inherit a fast-moving, breaking-change dependency whose scope has already drifted away from skill-quality toward memory. High ongoing maintenance (track upstream breaks, run a DB) + high dependency risk (external roadmap + runtime mismatch) for a payoff most of which we can get elsewhere free. Build from scratch is the opposite failure: lowest dependency risk but highest upfront cost, and it reinvents what Anthropic's native skill-creator and RDCO's own brigade already give us — a classic not-invented-here tax on the L5 roadmap.

Port threads the needle: take GBrain's transferable concepts — check-resolvable's reachability/MECE test, the DRY audit, resolver-eval discipline (both the deterministic table-presence check and the LLM routing check) — and re-implement them on RDCO's existing Claude Code substrate (rdco-doctor + the skill-dev brigade + the graph.duckdb reingest). For the eval-family steps, wire the native skill-creator rather than either building or importing them. Net maintenance burden: medium (small surface, our runtime, no DB); dependency risk: low-medium (Anthropic-native path + our own thin code, no Hermes coupling).

Which of the 8 steps each option ships fastest:

Sequencing for the 4-8 week window: (1) turn on native skill-creator evals across the current ~22-40 skills (steps 3/5/7 — LLM evals, integration, resolver eval), (2) extend rdco-doctor with a check-resolvable + DRY axis ported from gbrain's semantics (step 8), (3) add unit + E2E smoke via the brigade's test-author station (steps 3/9), (4) codify brain filing rules against vault conventions + graph reingest (step 10). GBrain becomes a reference to read, not a dependency to run.

Why this is in the vault

This brief resolves the explicit adopt/port/build fork the skillify-it brief left open, setting RDCO's L5-unhobbling harness roadmap for the next 4-8 weeks: it commits the skill-registry to a port-plus-native-eval path on the existing brigade-house/rdco-doctor substrate rather than importing an OpenClaw/Hermes-coupled external dependency.

Open follow-ups

Related

Sources