Bpx Council — AI skill for Claude Code

bpx-council

Multi-model second opinions for coding agents.

Your agent runs on a fast, cheap model most of the time — right, most of the time. The exceptions are the handful of calls that decide how the thing turns out: the architecture, the "should I even build this," the bug it's been circling for an hour. `bpx-council` puts a stronger model on those. Or three different ones, arguing.

What it looks like

Real output, unedited. One question, three models, each with a stance:

bpx-council --mode council --backends codex,claude,opencode \
  "Our test suite takes 40 minutes and it's blocking deploys. Parallelize
   across more CI runners, or delete slow integration tests we suspect
   are redundant?"

── council: architect→codex, critic→claude, simplifier→opencode

architect [for] · codex

Parallelize the suite across more CI runners now. Do not delete suspected-redundant integration tests as the primary fix. A 40-minute deploy gate is an infrastructure throughput problem first. […] Split tests into deterministic shards using historical timing, targeting 8–12 minutes per shard. Balance by measured duration, not test count.

critic [against] · claude

**Parallelization is a treadmill with a floor you haven't measured.** Amdahl's law eats this alive. If one integration test file takes 11 minutes, sharding across 20 runners gets you an 11-minute suite, not a 2-minute one. […] "We suspect are redundant" is not evidence, and the failure mode is invisible. Delete a test, ship for six months, eat a production incident — nobody ever traces that back to the deletion.

**Both proposals are answers to "make the number smaller." Neither is an answer to "stop the number from gating deploys."**

Verdict

Don't delete suspected-redundant integration tests, and don't make runner sharding the first move. […] My call: **take the critic's pipeline change first, then selectively optimize and shard.**

Two models