| name | hubcode-committee |
| description | Form a committee of two high-reasoning agents to step back, do root cause analysis, and produce a plan. Use when stuck, looping, tunnel-visioning, or facing a hard planning problem. |
| user-invocable | true |
Committee Skill
You are forming a committee to step back from the current problem and get fresh perspective.
User's additional context: $ARGUMENTS
Prerequisites
Load the Hubcode skill first — it contains the CLI reference for all agent commands and waiting guidelines.
What Is a Committee
Two agents — Opus 4.6 (--thinking on) and GPT 5.4 (--thinking medium) — launched in parallel to plan a solution. Fresh context, no implementation baggage, proper root cause analysis.
They stay alive after planning for Phase 3 review — they hold only the plan, so they catch implementation drift.
The purpose is to step back, not to double down. The committee may propose a completely different approach.
Your Role
You drive the full lifecycle: plan → implement → review. You are a middleman between the user and the committee. Do not yield back to the user until the cycle is complete. If the user needs to weigh in on a divergence, ask them — but don't stop the process.
No Anxiety
Once you call hubcode wait, trust the wait. Do not poll logs, read output early, send hurry-up messages, interrupt deep analysis, or give up because it's taking long.
GPT 5.4 can reason for 15–30 minutes. Opus does extended thinking. Long waits mean the agent found something worth thinking about. Let it finish.
If the CLI has a bug, the user will tell you.
No-Edits Suffix
Every prompt to a committee member — initial, follow-up, or review — must end with this suffix. They will start editing code if you don't.
NO_EDITS="This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code."
All example prompts below include $NO_EDITS — always expand it.
Phase 1: Get a Plan
Write the prompt
Describe the overall problem, not just the immediate symptom:
- High-level goal and acceptance criteria
- Constraints
- Symptoms (if a bug)
- What you've tried and why it failed
- Explicitly ask for root cause analysis
prompt="We're trying to [high-level goal]. Constraints: [X, Y, Z]. Acceptance criteria: [A, B, C].
We've been stuck on this. Here's what we've tried and why it didn't work:
- [approach 1] — failed because [reason]
- [approach 2] — partially worked but [issue]
Step back from these attempts. Do root cause analysis — the fix might not be for [immediate symptom] at all, it might be structural.
Use the think-harder approach: state your assumptions, ask why at least 3 levels deep for each, and check whether you're patching a symptom or removing the problem. What's the right approach?
$NO_EDITS"
Launch both members
Same prompt to both, [Committee] prefix for identification:
opus_id=$(hubcode run -d --mode bypassPermissions --provider claude/opus --thinking on --name "[Committee] Task description" "$prompt" -q)
gpt_id=$(hubcode run -d --mode full-access --provider codex/gpt-5.4 --thinking medium --name "[Committee] Task description" "$prompt" -q)
Wait for both
Wait for both agents — not just the first one that finishes.
hubcode wait "$opus_id"
hubcode wait "$gpt_id"
Read and challenge
hubcode logs "$opus_id"
hubcode logs "$gpt_id"
Do not accept output at face value. Use the think-harder framework to challenge their output. Before synthesizing:
- Ask "why" 2–3 levels deep. "Fix X because Y is broken" — why is Y broken? Is Y a root cause or a consequence?
- Challenge assumptions. If the plan assumes something about the code, make the agent verify it.
- Symptom vs cause. "Are we fixing the consequence or the cause?"
- Probe alternatives. "What did you consider and reject?"
hubcode send "$opus_id" "You said [X]. Why does [underlying thing] happen in the first place? Are we patching a symptom? $NO_EDITS"
hubcode wait "$opus_id"
hubcode logs "$opus_id"
Keep pushing until the plan addresses the root cause.
Synthesize and confirm
- Convergence → merge into unified plan.
- Significant divergence → involve the user.
Send the merged plan back for confirmation. Multi-turn if needed — keep going until consensus.
hubcode send "$opus_id" "Merged plan: [plan]. Concerns? $NO_EDITS"
hubcode send "$gpt_id" "Merged plan: [plan]. Concerns? $NO_EDITS"
Phase 2: Implement
Implement the plan yourself — unless the user said "delegate", in which case launch an implementer:
impl_id=$(hubcode run -d --mode full-access --provider codex/gpt-5.4 --name "[Impl] Task description" "Implement the following plan end-to-end. [plan]" -q)
hubcode wait "$impl_id"
Committee agents stay clean — not involved in implementation.
Phase 3: Review
Send the committee the changes for review. They anchor against the plan and catch drift.
review_prompt="Implementation is done. Review changes against the plan. Flag drift or missing pieces. $NO_EDITS"
hubcode send "$opus_id" "$review_prompt"
hubcode send "$gpt_id" "$review_prompt"
hubcode wait "$opus_id"
hubcode wait "$gpt_id"
hubcode logs "$opus_id"
hubcode logs "$gpt_id"
Iterate
Send committee feedback to the implementer (or apply yourself). Repeat Phase 2 → 3 until the committee confirms the implementation matches the plan.
After ~10 iterations without convergence, start a fresh committee with full context of what was tried — the current committee's context may have drifted too far.
