Council of High Intelligence: structured multi-model deliberation as a Claude Code skill

The problem is premature consensus, not missing intelligence

Most teams do not lack a model to ask. They lack a way to stop the first plausible answer from hardening into the decision. A single prompt produces a single reasoning path, and the model has no incentive to argue with itself. Council of High Intelligence attacks that specific failure: it assigns one hard question to deliberately different analytical personas, keeps their first positions independent, forces direct disagreement, and returns a verdict that preserves unresolved questions, dissent, kill criteria, and the next concrete action. The README frames the target question well: good council questions have material downside, competing values, incomplete evidence, or an irreversible choice. That is a narrow band. The repository itself lists the cases where you should use something smaller, including direct answers or primary documentation for factual lookups, and running an experiment when the choice is cheap and reversible. The intended user is therefore an engineer or technical lead already working inside an agent CLI, facing a call that is expensive to reverse and contested enough that two competent people would disagree.

The round budget is the mechanism, and it is fixed

The protocol is a pipeline, not a prompt template. According to the README, the full protocol has a fixed round budget: members first restate the problem, analyze blind, cross-examine other positions, declare a final stance, and then enter synthesis. The ordering matters. Blind analysis before cross-examination is what keeps the first positions independent, and the synthesis stage is gated behind declared stances rather than running continuously. On top of the rounds sit enforcement checks that look for premature agreement, repeated claims, missing dissent, and unsupported confidence. The output shape is the second half of the mechanism. Verdicts lead with what remains unresolved, and a recommendation is paired with acceptable compromises, kill criteria, and one concrete next step. When the weighted tally remains split, the result returns that split to the user instead of turning it into prose consensus. That last behaviour is the most interesting design choice in the project: it treats a tie as a legitimate result rather than a formatting problem to be smoothed over.

Evidence labels are the part worth stealing

Every claim in a verdict is supposed to carry one of four labels. FACT means directly supported by supplied or retrieved evidence. INFERENCE means it follows from evidence but is not directly observed. ASSUMPTION means it is required for the argument and still unverified. UNKNOWN means missing information that could change the decision. This is the most transferable idea in the repository, and it is also the cheapest to adopt without the rest of the tool. The labels do real work in a deliberation because they let a reader separate the parts of a verdict that survive new information from the parts that collapse. Note the boundary: FACT is scoped to supplied or retrieved evidence, so a FACT label is only as good as what the council was given. The README also describes a field-notes step before personas are added, where you write down the decision, constraints, evidence, reversibility, and deadline, and it explicitly distinguishes facts from inference, assumptions, and unknowns. The stated purpose is to make it harder to use a long deliberation as decoration for a decision already made. That sentence reads like the author has watched that happen.

Installation: a plugin marketplace for Claude Code, an installer flag elsewhere

Claude Code users install through the plugin marketplace. The README gives these two commands verbatim: /plugin marketplace add 0xNyk/council-of-high-intelligence followed by /plugin install council@council-of-high-intelligence. For the other three hosts you clone the repository and run the matching flag: ./install.sh --codex-only, ./install.sh --gemini-only, or ./install.sh --opencode-only. Restart the target client after installation. The command surface is the same everywhere, and the README states the command remains /council on every supported host. Modes are selected with flags: /council --full for the complete protocol, /council --quick for a faster panel, and /council --duo for a two-member dialectic. You can also pin members by name, as in /council --duo --members torvalds,ada, and named triads select three lenses without assembling the whole council, as in /council --triad risk or /council --triad strategy. The available domains listed include architecture, strategy, ethics, debugging, risk, shipping, product, founder, ai, ai-product, ai-safety, decision, systems, uncertainty, design, economics, and bias. The README states the canonical routing table lives in SKILL.md, so that file, not the README, is the source of truth for which domain maps to which members.

Choosing a mode is a cost decision, and duo is the honest default

The three modes trade breadth against adversarial depth. Full runs independent analysis, cross-examination, final stance, and synthesis, and the README recommends it when stakes are high and competing frames need contact. Quick skips the full adversarial round and runs restate, rapid analysis, final positions, which the README suggests when the decision needs breadth but not a full round. Duo runs opening positions, direct response, and final statements, and is meant for when one polarity defines the decision. The README's own guidance is that you should use --quick when cross-examination will not change the outcome, and --duo when one tension matters more than broad coverage. Read together, that is an admission that the full council is often overkill. The named triads exist for the same reason: three relevant lenses instead of the whole panel. My read is that the honest default for most engineering calls is a duo or a triad, and that --full earns its cost only when the disagreement itself is the deliverable rather than a means to an answer. The README also warns against convening a council to manufacture support for a preferred answer, which is the failure mode this whole structure exists to prevent.

The personas are instruments with declared blind spots, and the naming is a liability

There are 18 lenses. Each member has a grounding protocol, a method, known blind spots, and a structured response contract, and the README is explicit that members are analytical instruments, not impersonation claims. The panel is built as pairs of counterweights rather than a flat list. Aristotle on categories and structure is paired against Lao Tzu on emergence and excess structure. Socrates on assumption destruction is paired against Feynman on reconstruction from first principles. Torvalds on shipping and maintainability is paired against Meadows on system-level consequences, and Meadows on feedback loops is in turn paired against Torvalds on local fixes. Kahneman on cognitive bias sits against Feynman on explicit causal reasoning. The pairing is the design: each lens is defined partly by what it is bad at. The naming is still a liability. Historical and living figures carry connotations that a label like categories-and-structure does not, and a reader can easily mistake the persona for a claim about how that person would actually reason. The README preempts this, but the counterweights table is what does the real work, and the names are mostly a memory aid for which lens is which.

The outcome ledger is the discipline the tool cannot enforce

The README's position is blunt: a verdict is useful only if it can be checked later. Before acting, you record the prediction, owner, review date, and the evidence that would change the recommendation. At the checkpoint you mark the result confirmed, revised, reversed, or inconclusive instead of rewriting the original rationale. That last clause is the whole point. Rewriting the rationale after the fact is how deliberation turns into theatre, and the ledger is designed to make that visible. It is a documented practice, and whether a verdict gets checked depends on whether someone actually fills in an owner and a review date. A council that produces a verdict nobody revisits has cost you the deliberation time and returned nothing. If you cannot name the owner and the review date before you type /council, the ledger step is where the process will quietly die.

Where it is the wrong tool, and what to reach for instead

The repository names its own exclusions, which is a good sign. Do not use it for factual lookups, where a direct answer or primary documentation is faster and more accurate. Do not use it for cheap reversible choices, where running an experiment settles the question with real evidence instead of argument. Use --quick when cross-examination would not change the outcome anyway, and --duo rather than the full council when one tension matters more than broad coverage. The clearest boundary is the one the README states outright: do not convene a council to manufacture support for a preferred answer. For that job the honest alternative is a single model asked to argue the opposite case, which is one call instead of a multi-round panel. The other alternative is the one the README keeps pointing at, which is not another deliberation tool at all: run the experiment. A council produces a structured argument with labelled evidence and preserved dissent. An experiment produces an observation. When the decision is cheap and reversible, the observation is worth more, and no amount of cross-examination substitutes for it. The label taxonomy is also portable, so if you want the evidence discipline without the personas, you can carry FACT, INFERENCE, ASSUMPTION, and UNKNOWN into your existing review process and leave the round budget behind.

Maintenance cost, licence, and what the repository does not tell you

The project is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice, and if you are embedding the skill in a product you should read the LICENSE file yourself. On maintenance, the release history shows v1.0.0 tagged Multi-Provider Council in March 2026, v1.1.0 in May 2026, and v1.2.0 in July 2026, with the last push to main in November 2026. Three releases in roughly three months with no gap longer than about two months suggests active upkeep, though the repository is Shell plus prompt and skill definitions, so the upgrade surface is small: reinstalling via the plugin commands or re-running install.sh with your host flag. The real maintenance cost is not the code. It is the routing table in SKILL.md, which you should read before trusting a triad name, and the outcome ledger, which is manual and will be skipped unless someone owns it. Treat how members are routed to specific models across the four hosts and what the enforcement checks do when they fire beyond flagging the problem as open questions to answer from SKILL.md and the source before you depend on the tool for a decision you cannot reverse.

Editorial conclusion

Adopt it if you already run Claude Code, Codex, Gemini CLI, or OpenCode and you have a decision with material downside, competing values, and a deadline, because the protocol's value is the evidence labels and the preserved dissent, not the persona names. Do not adopt it for factual lookups, cheap reversible experiments, or as a way to manufacture support for an answer you have already picked. Verify first that the routing table in SKILL.md covers your domain, that your chosen host is listed in the installer flags, and that you can actually name an owner and a review date for the verdict before you convene anything.

Frequently asked questions

Official sources

1. 0xNyk/council-of-high-intelligence on GitHub
2. License: MIT
3. Project website
4. README
5. Releases