council

name	council
description	Get second opinions from competing AI models (OpenAI, Google, Anthropic, Qwen, etc.) via OpenRouter, without leaving Claude Code. This skill takes priority when the user asks to consult, ask, or get a perspective from another AI model. Trigger phrases: "get a second opinion", "ask Gemini", "ask GPT", "ask Codex", "consult", "get a few opinions", "what would Gemini say", "what would GPT think", "council audit", "run a council". Uses the council.py script via OpenRouter - never call Gemini or OpenAI APIs directly.
argument-hint	[optional: specific question or category like frontend, bug_fix, architecture]

Council

Route questions to specialist AI models via OpenRouter for second opinions, then synthesize the best approach.

Setup

1. Get an API key at https://openrouter.ai/keys
2. Set OPENROUTER_API_KEY in your environment, ~/.env, or project .env

Invocation Modes

1. Auto-routed: "Get a second opinion"

User says something like "get a second opinion on this bug" without naming a model.

Workflow:

1. Analyze the current conversation context
2. Classify the task into a category using keywords from the config: !cat "${CLAUDE_SKILL_DIR}/council_config.json" | python -c "import sys,json; cfg=json.load(sys.stdin); [print(f' {k}: {v[\"keywords\"]}') for k,v in cfg['categories'].items()]" 2>/dev/null || echo " (config not loaded)"
3. Resolve the category to the default model from config
4. Tell the user the plan before executing: "I'll consult [Model Name] regarding [Category/Topic]..."
5. Wait for user confirmation
6. Run: python "${CLAUDE_SKILL_DIR}/scripts/council.py" consult --category [category_name] --context "FULL CONTEXT HERE"

2. Manual routing: "Ask [Model Name]"

User specifically names a model (e.g., "ask Gemini", "ask GPT").

Workflow:

1. Map the requested name to the provider/model in config
2. Tell the user the plan
3. Run: python "${CLAUDE_SKILL_DIR}/scripts/council.py" consult --model [model_id] --context "FULL CONTEXT HERE"

3. Multi-model audit

User asks for opinions from multiple models (e.g., "send frontend to Gemini and copy to GPT").

Workflow:

1. Identify each model and what context to send
2. Tell the user the plan
3. Run multiple consult commands, one per model
4. Synthesize all responses together

Context Packaging Rules

When sending context to another model, you MUST include:

• The specific question or problem statement - what exactly do you want reviewed?
• Relevant code snippets - keep it focused, not the entire codebase. Send the actual code being discussed.
• What has already been tried - summarize approaches attempted and their outcomes
• What kind of answer is needed - diagnosis, code fix, design opinion, copy review, etc.

DO NOT send the entire conversation history. Extract and summarize the relevant parts.

Synthesis Rules

After receiving a response from the council:

1. Present the raw response clearly labeled with the model name in a section header like "## Gemini 2.5 Pro Response" or "## GPT-4o Response"
2. State your agreement or disagreement - do NOT just parrot the response. Use your own judgment as lead engineer.
3. If disagreeing, explain why with specific reasoning
4. If agreeing, note any additions or refinements you'd make
5. Propose an action plan - prioritize changes into "must fix", "worth testing", and "nice to have"
6. Ask the user if they want you to implement the changes
7. Execute the best approach - pick the path of least resistance, even if it wasn't your original idea

Model Discovery

To check available models on OpenRouter:

python "${CLAUDE_SKILL_DIR}/scripts/council.py" models --provider google
python "${CLAUDE_SKILL_DIR}/scripts/council.py" models --provider openai
python "${CLAUDE_SKILL_DIR}/scripts/council.py" models --provider anthropic
python "${CLAUDE_SKILL_DIR}/scripts/council.py" models --provider qwen

Important Rules

• NEVER call Gemini, OpenAI, or any external model API directly. Always go through the council.py script via OpenRouter.
• Always confirm the plan with the user before making API calls.
• Always package context properly - no lazy "here's everything" dumps.
• Always synthesize - don't just relay. You are the lead engineer making the final call.