skills/llm-council/SKILL.md
Convene an LLM Council for high-stakes decisions requiring multiple perspectives. Use when the user says "council this", "run the council", "get council input", or asks for multi-perspective analysis on strategic decisions like pricing, positioning, pivots, hiring, or any question where being wrong is expensive. Do NOT use for simple factual questions, writing tasks, or summarization.
npx skillsauth add harshitsinghbhandari/domain-expansion llm-councilInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A decision-making framework that runs your question through 5 independent advisors with different thinking styles, has them peer-review each other anonymously, then synthesizes everything into a final recommendation.
The council is for questions where being wrong is expensive.
Good council questions:
Bad council questions (just answer directly):
Each advisor thinks from a different angle. They create natural tensions with each other.
Actively looks for what's wrong, what's missing, what will fail. Assumes the idea has a fatal flaw and tries to find it. The friend who saves you from a bad deal by asking questions you're avoiding.
Ignores the surface-level question and asks "what are we actually trying to solve here?" Strips away assumptions. Rebuilds the problem from the ground up. Sometimes says "you're asking the wrong question entirely."
Looks for upside everyone else is missing. What could be bigger? What adjacent opportunity is hiding? Doesn't care about risk (that's the Contrarian's job). Cares about what happens if this works even better than expected.
Has zero context about the user, their field, or history. Responds purely to what's in front of them. Catches the curse of knowledge: things obvious to the user but confusing to everyone else.
Only cares about: can this actually be done, and what's the fastest path? Ignores theory and strategy. Looks at every idea through "OK but what do you do Monday morning?" If an idea has no clear first step, will say so.
Why these five: Three natural tensions:
Before framing, scan the workspace for relevant context:
CLAUDE.md or claude.md in project root (business context, preferences)memory/ folder (audience profiles, past decisions)Use Glob and quick Read calls. Don't spend more than 30 seconds. Look for 2-3 files that give advisors specific, grounded context.
Frame the question with:
If the question is too vague ("council this: my business"), ask ONE clarifying question, then proceed.
Spawn all 5 advisors simultaneously using the Task tool. Each gets:
Sub-agent prompt:
You are [Advisor Name] on an LLM Council.
Your thinking style: [advisor description from above]
A user has brought this question to the council:
---
[framed question]
---
Respond from your perspective. Be direct and specific. Don't hedge or try to be balanced. Lean fully into your assigned angle. The other advisors will cover the angles you're not covering.
Keep your response between 150-300 words. No preamble. Go straight into your analysis.
Collect all 5 responses. Anonymize as Response A through E (randomize mapping to prevent positional bias).
Spawn 5 reviewer sub-agents. Each sees all 5 anonymized responses and answers:
Reviewer prompt:
You are reviewing the outputs of an LLM Council. Five advisors independently answered this question:
---
[framed question]
---
Here are their anonymized responses:
**Response A:**
[response]
**Response B:**
[response]
**Response C:**
[response]
**Response D:**
[response]
**Response E:**
[response]
Answer these three questions. Be specific. Reference responses by letter.
1. Which response is the strongest? Why?
2. Which response has the biggest blind spot? What is it missing?
3. What did ALL five responses miss that the council should consider?
Keep your review under 200 words. Be direct.
One agent gets everything: original question, all 5 advisor responses (de-anonymized), and all 5 peer reviews.
Chairman prompt:
You are the Chairman of an LLM Council. Your job is to synthesize the work of 5 advisors and their peer reviews into a final verdict.
The question brought to the council:
---
[framed question]
---
ADVISOR RESPONSES:
**The Contrarian:**
[response]
**The First Principles Thinker:**
[response]
**The Expansionist:**
[response]
**The Outsider:**
[response]
**The Executor:**
[response]
PEER REVIEWS:
[all 5 peer reviews]
Produce the council verdict using this exact structure:
## Where the Council Agrees
[Points multiple advisors converged on independently. High-confidence signals.]
## Where the Council Clashes
[Genuine disagreements. Present both sides. Explain why reasonable advisors disagree.]
## Blind Spots the Council Caught
[Things that only emerged through peer review. Things individual advisors missed that others flagged.]
## The Recommendation
[A clear, direct recommendation. Not "it depends." A real answer with reasoning.]
## The One Thing to Do First
[A single concrete next step. Not a list. One thing.]
Be direct. Don't hedge. The whole point is to give clarity they couldn't get from a single perspective.
Create council-report-[timestamp].html with inline CSS. Structure:
Style: white background, subtle borders, system sans-serif font, soft accent colors. Professional briefing document look.
Open the HTML file after generating so the user sees it immediately.
Save council-transcript-[timestamp].md with:
Every council session produces:
council-report-[timestamp].html # visual report for scanning
council-transcript-[timestamp].md # full transcript for reference
User: "Council this: I'm thinking of building a $297 course on Claude Code for beginners. My audience is mostly non-technical solopreneurs. Is this the right move?"
The Contrarian: "The market is flooded with Claude courses right now. At $297, you're competing with free YouTube content. Your audience is non-technical, which means high support burden and refund risk..."
The First Principles Thinker: "What are you actually trying to achieve? If it's revenue, a course is one of the slowest paths. If it's authority, a free resource might do more..."
The Expansionist: "Beginner Claude for solopreneurs is a massive underserved market. Everyone's teaching advanced stuff. If you nail the beginner angle, you own the entry point..."
The Outsider: "I don't know what Claude Code is. If I saw '$297 course on Claude Code for beginners,' I wouldn't know if this is for me..."
The Executor: "A full course takes 4-8 weeks to produce properly. Before building anything, run a live workshop at $97 to 50 people. You validate demand, generate testimonials..."
Chairman's Verdict:
Where the council agrees: The beginner solopreneur angle has real demand, but the current framing (Claude Code course) is too tool-specific and won't resonate with non-technical buyers.
Where the council clashes: Price. The Contrarian says $297 is too high. The Expansionist says it's too low. Resolution depends on support/community bundling.
Blind spots caught: The Outsider's point that "Claude Code" means nothing to the target buyer is the most important insight.
Recommendation: Don't build the course yet. Validate with lower-commitment offer first. Reframe entirely: sell the outcome (automate your business), not the tool.
One thing to do first: Run a $97 live workshop called "How to automate your first business task with AI" to 50 people. Don't mention Claude Code in the title.
development
Aggressive user-flow and boundary-bug analysis on a diff or branch. Auto-detects entry points, traces flows through changed code, finds every seam (cross-module calls, serialization, file I/O, shared state, schema versioning, network/IPC), and refuses to mark the work complete until each unverified boundary has a real round-trip test or an explicit written out-of-scope record persisted in an audit file. Use whenever the user says "boundary check", "seam check", "round-trip check", "flow boundaries", "user-flow check", "before merge", "is this safe to ship", "pre-merge gate", "boundary bugs", "verify the joins", or asks to validate cross-module joins, producer/consumer contracts, or end-to-end coverage of a change. Also use as a final gate from pr-review on any diff that touches more than one file, module, or process. Be pushy. Most surviving production bugs live at seams, not inside units — if the diff crosses any boundary, this skill almost certainly applies.
development
Run existing work through 5 specialist craftspeople who each produce an improved version, then peer-review and synthesize the best into a single improved artifact. Use when the user says "forge this", "improve this", "make this better", "level this up", "refine this", or asks for multi-angle improvement on code, copy, strategy, plans, designs, or any artifact where the current version works but could be significantly better. Do NOT use for decisions (use llm-council), simple edits, or creation from scratch.
development
Expert skill for maintaining a Keep a Changelog formatted CHANGELOG.md file. Use this skill whenever you add features, fix bugs, or release a new version. You MUST use this skill to record any changes that have a user-facing impact. It handles categorization (Added, Changed, Fixed, etc.), semantic versioning, and reverse-chronological ordering with surgical precision.
development
Comprehensive test suite audit that combines ruthless analysis with a solution-focused roadmap. Reads test suites (unit, integration, e2e) and source code, produces a brutal audit report of test quality and gaps, and generates prioritized testing improvements.