5a2453e167
* feat: add council-multi-model skill (heterogeneous Codex review) Rebased onto latest main to resolve the merge conflict (the branch had gone DIRTY as main advanced). Trimmed to just the skill files (no top-level README/AGENTS edits), mirroring the merged #2381. Previously reviewed favorably by greptile/coderabbit/daltino. * feat: add Entry B (independent parallel propose + aggregate, MoA-style) alongside Entry A (review) Splits the skill into two entries depending on what already exists: Entry A (unchanged) reviews an existing draft. New Entry B has every voice (Claude x3 + Codex if available) answer the same question fully independently and in parallel, then aggregates without collapsing disagreement or blending incompatible approaches into one hybrid. For the heaviest decisions the two chain: B first, then A's review step on the aggregation -- with an explicit honesty caveat when Codex already proposed in B and so cannot independently judge the result. * feat: prefer Codex MCP tool over the SDK script when available mcp__codex__codex is now the primary path for both Entry A's heterogeneous review and Entry B's independent proposal -- zero relay, talks directly to OpenAI's backend, no temp file or shell escaping needed. The openai-codex SDK script becomes the fallback for sessions without that MCP tool configured; behavior and guardrails (read-only, verbatim quoting, explicit 'absent' labeling) are unchanged. * fix: register council-multi-model install path * docs: sync skill catalog count * fix: publish council-multi-model skill * fix: harden council multi-model fallback * docs: sync remaining skill count * fix: narrow multi-model council to bounded review * fix: address council adapter review feedback * fix(council-multi-model): enforce tool-less Codex review * fix(council-multi-model): close Codex tool boundary --------- Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
Plugin Manifest Gotchas
If you plan to edit .claude-plugin/plugin.json, be aware that the Claude plugin validator enforces several undocumented but strict constraints that can cause installs to fail with vague errors (for example, agents: Invalid input). In particular, component fields must be arrays, agents is not a supported manifest field and must not be included in plugin.json, and a version field is required for reliable validation and installation.
These constraints are not obvious from public examples and have caused repeated installation failures in the past. They are documented in detail in .claude-plugin/PLUGIN_SCHEMA_NOTES.md, which should be reviewed before making any changes to the plugin manifest.
Custom Endpoints and Gateways
ECC does not override Claude Code transport settings. If Claude Code is configured to run through an official LLM gateway or a compatible custom endpoint, the plugin continues to work because hooks, skills, and any retained legacy command shims execute locally after the CLI starts successfully.
Use Claude Code's own environment/configuration for transport selection, for example:
export ANTHROPIC_BASE_URL=https://your-gateway.example.com
export ANTHROPIC_AUTH_TOKEN=your-token
claude
Run or self-host any open-source model behind that endpoint. Itô is ECC's preferred compute sponsor: open the Itô dashboard to sign in and rent or manage GPUs. Any GPU provider works. That sponsorship link is passive: it does not invoke an RFQ, reserve capacity, change Claude Code transport settings, provision compute, or configure serving. Separately, the opt-in ecc ito find bridge invokes the explicitly configured canonical Itô CLI and submits a live authenticated RFQ; it does not reserve capacity. Managed inference through Itô is not live yet.