mikeng-io/agent-skills/deep-council

Deep Council: Council-of-Councils

Execute this skill to run a nested council across independent runtimes/toolchains. Deep Council is not merely multi-model review: it treats Claude Code, Codex, OpenCode, Gemini, and other bridges as council-capable runtimes. Each bridge runs its own local council using native strengths, then Deep Council runs cross-council debate over their reports.

Council-of-Councils Architecture

Deep Council
├─ bridge-claude
│  └─ local Agent Council / full debate-protocol when available
├─ bridge-codex
│  └─ local Agent Council optimized for diff/code/repo review
├─ bridge-opencode
│  └─ local Agent Council or Model Council if multiple models configured
├─ bridge-gemini
│  └─ local stateless debate-compatible council
└─ Cross-Council Debate
   ├─ frame comparison
   ├─ finding/proposal challenge
   ├─ shared-bias challenge
   └─ final synthesis

A finding supported by multiple models is model-confirmed. A finding supported by multiple runtimes/toolchains is runtime-confirmed. A finding supported by tests/logs/source evidence is evidence-confirmed. Record these separately; do not treat model count as the only confidence signal.

Modes

deep-council supports:

• review / audit — local councils produce findings; cross-council debate validates them.
• brainstorm / design — local councils produce competing proposals; cross-council debate challenges, merges, rejects, or selects proposals.
• research — local councils produce evidence-backed observations and contradictions; cross-council debate validates evidence and confidence.

Brainstorm Mode

Use brainstorm mode when the goal is to create candidate architectures or plans, not to validate an existing proposal. The root orchestrator sends each bridge a minimal discovery packet and asks it to generate independent proposals. Later rounds publish proposal inventories and challenge assumptions.

Brainstorm flow:

1. Round 0: Minimal discovery packet — scope, objective, constraints, output contract. No expected findings or preferred design.
2. Round 1: Local frame discovery — each bridge decides its local roster, domains, and tool strategy.
3. Round 2: Local council execution — each bridge runs local Agent/Model Council and emits a local report.
4. Round 3: Cross-council frame debate — compare investigation strategies, runtime affordances, and blind spots.
5. Round 4: Cross-council proposal/finding debate — challenge proposals or findings using debate-protocol state semantics.
6. Round 5: Final report — preserve lineage, diversity sources, accepted/rejected/parked proposals, and verdict or recommendation.

Execution Instructions

When invoked, you will:

1. Resolve scope and context — invoke preflight (if sparse) + context skill in parallel
2. Populate council context from working_scope
3. Read and inventory available bridges
4. Dispatch all available bridges in parallel via Task agents
5. Require each bridge to return a local council report, degraded-mode report, or SKIPPED/HALTED status
6. Run cross-council debate using debate-protocol logic
7. Produce a consolidated council-of-councils report with runtime/tool/model/role provenance

Dependency Check

Before executing any step, verify all required skills are present. Use Glob or ls to check each:

[skills-root]/context/SKILL.md
[skills-root]/preflight/SKILL.md
[skills-root]/bridge-commons/SKILL.md
[skills-root]/bridge-claude/SKILL.md
[skills-root]/bridge-gemini/SKILL.md
[skills-root]/bridge-codex/SKILL.md
[skills-root]/bridge-opencode/SKILL.md
[skills-root]/domain-registry/README.md

Where [skills-root] is the parent of this skill's directory (e.g., skills/ or .claude/skills/). Resolve with ls ../ from this skill's location.

If any required file is missing → stop immediately and output:

⚠ Missing required skills for deep-council:
 
  {missing-skill}
    Expected: {skills-root}/{missing-skill}/SKILL.md
 
Install the missing skill(s):
  git clone https://github.com/mikeng-io/agent-skills /tmp/agent-skills
  cp -r /tmp/agent-skills/skills/{missing-skill} {skills-root}/
 
Or install the full suite at once:
  cp -r /tmp/agent-skills/skills/ {skills-root}/

All dependencies present → proceed to Step 0.

Step 0: Scope & Context Resolution

Context (always required):

Invoke Skill("context") first. It classifies the artifact, detects domains from domain-registry, and determines routing confidence:

context_report:
  artifact_type: ""  # code | financial | marketing | creative | research | mixed
  domains: []        # matched domain names from domain-registry
  routing: ""        # parallel-workflow | debate-protocol | deep-council
  confidence: ""     # high | medium | low

Preflight (conditional — triggered by context confidence):

Invoke Skill("preflight") only if context_report.confidence == "low" OR one or more of these signals remains unresolved after context runs:

• Artifact is not clearly identified
• Intent is ambiguous (review vs. audit vs. verify vs. research)
• Domains could not be detected
• Scope is too broad to proceed

Preflight asks at most 3 targeted questions (one at a time) to fill exactly the gaps context could not resolve:

scope_clarification:
  artifact: ""       # what to analyze
  intent: ""         # review | audit | verify | research | explore
  domains: []        # inferred domains (supplements context_report.domains)
  constraints: []    # any explicit focus areas
  confidence: ""     # high | medium

If context_report.confidence == "high" → skip preflight entirely.

Post-preflight validation (only when preflight ran):

if scope_clarification.confidence == "medium":
  # Preflight completed but scope still contains assumptions
  emit_warning: |
    ⚠ Preflight returned confidence: medium — scope may contain unverified assumptions.
    Assumptions made: {scope_clarification.assumptions}
    Proceeding with available context. Findings may be scoped more narrowly than intended.
  # Record warning in synthesis_notes of final report
  # Do NOT block — proceed with the available working_scope

If scope_clarification.confidence == "high" after preflight → proceed normally.

Merge into working scope:

working_scope:
  artifact: ""            # from context signals + scope_clarification if preflight ran
  intent: ""              # from context or scope_clarification
  domains: []             # from context_report (authoritative), supplemented by preflight
  constraints: []         # from scope_clarification (empty if preflight skipped)
  context_summary: ""     # combined description for agent prompts
  intensity: ""           # from routing signals and any explicit user request

Use working_scope throughout this skill. Do not re-extract context from conversation after Step 0.

Step 1: Populate Council Context

Using working_scope from Step 0, populate the council context:

council_context:
  review_scope: ""        # from working_scope.artifact
  context_summary: ""     # from working_scope.context_summary
  artifact_type: ""       # from working_scope context_report.artifact_type
  domains: []             # from working_scope.domains
  intensity: "standard"   # from working_scope.intensity (quick | standard | thorough)
  review_id: ""           # Generate a unique ID: council-{YYYYMMDD-HHmmss}
  task_type: "review"     # from working_scope.intent — defaults to "review"

Optional: enrich with DeepWiki (if configured)

If the review involves a GitHub repository and mcp__devin__* tools are available, invoke the deepwiki skill to supplement context_summary with architectural intent before dispatching bridges. Bridges with richer context produce better-targeted findings.

Skill("deepwiki")
→ ask_question: "What are the primary architectural concerns and component relationships relevant to: {review_scope}?"
→ Append answer to context_summary before Step 4 bridge dispatch

Falls back gracefully if DeepWiki is not configured. Non-blocking.

Read domain-registry to confirm domain selection:

Read: [skills-root]/domain-registry/domains/technical.md
Read: [skills-root]/domain-registry/domains/business.md
Read: [skills-root]/domain-registry/domains/creative.md

Step 1B: Model Discovery & Settings

Before dispatching bridges, discover what models and providers are configured and confirm with the user. This step runs once per project — results are cached in .bridge-settings.json.

Load or Discover

# Check for existing settings
cat .bridge-settings.json 2>/dev/null

If .bridge-settings.json exists and is current → load settings and proceed to Step 2 (skip user prompt unless user passes --reconfigure).

If not found or --reconfigure → run discovery:

# Codex: list available models
codex models list 2>/dev/null
 
# OpenCode: list authenticated providers
opencode auth list 2>/dev/null
 
# Gemini: check availability
which gemini 2>/dev/null && echo "available"

Present to User

Show discovered configuration:

Available bridges for this review:
 
  [claude]     ✓ Task tool accessible
  [gemini]     ✓ CLI found           Model: {gemini default}
  [codex]      ✓ MCP configured      Models: {from codex models list}
  [opencode]   ✓ Providers: {list}   Dispatch: {single-model | multi-model (N models)}
                                     Models: {models array from settings, or "default"}
 
Reasoning level (applies to Codex):  medium / high / xhigh  [medium]
 
OpenCode multi-model: add/remove models, or press Enter to accept current settings.
  Current: {bridges.opencode.models or "default (single model)"}
  Format:  provider/model  e.g. glm/glm-4-7, kimi/moonshot-v1-8k, qwen/qwen-plus
 
Enable/disable bridges, select models, or press Enter to accept defaults.

Wait for user input. Accept Enter to use defaults.

Save Settings

// .bridge-settings.json — suite-owned config, separate from any CLI tool's own config
{
  "bridges": {
    "claude":    { "enabled": true },
    "gemini":    { "enabled": true },
    "codex":     { "enabled": true, "model": null },
    "opencode":  {
      "enabled": true,
      "model":   null,
      "models":  []
    }
  },
  "reasoning_level": "medium",
  "updated": "{ISO-8601}",
  "ttl_hours": 24
}

opencode.models — controls multi-model dispatch:

• [] or missing → single invocation with OpenCode's default model
• ["glm/glm-4-7", "kimi/moonshot-v1-8k"] → two parallel invocations, mini-synthesis within bridge
• ["glm/glm-4-7", "kimi/moonshot-v1-8k", "qwen/qwen-plus"] → three models, bridge-opencode acts as its own mini-council

model (singular) is a legacy single-model override — ignored when models has entries. See bridge-commons for the full bridge settings schema and the two-layer debate architecture.

On load, if (current_time - updated) > ttl_hours → force re-discovery even without --reconfigure.

Apply these settings when dispatching bridges in Step 4.

Step 2: Read Bridge Reference Docs

Use the Read tool to load each bridge's reference document:

Read: [skills-root]/bridge-claude/SKILL.md
Read: [skills-root]/bridge-gemini/SKILL.md
Read: [skills-root]/bridge-codex/SKILL.md
Read: [skills-root]/bridge-opencode/SKILL.md

These files define exactly how each bridge executor should operate. Their instructions will be embedded verbatim into Task agent prompts.

Step 3: Check Bridge Availability

For each bridge, determine availability:

bridge_claude:
  status: available_via_task_tool   # Available when Task tool is accessible (default in Claude Code; may be unavailable in other executors)
 
bridge_gemini:
  check: "which gemini"
  status: available | unavailable