customer-panel-of-experts

name: customer-panel-of-experts description: Build a panel of your real buyer personas (from a deep scan of any tools you allow it to connect to) and have them debate any decision you bring — a marketing launch, a price increase, a new product, a positioning change, a feature cut. Returns a structured debate, the strongest objections, and a clear recommendation. Use when you want your actual customers in the room before you commit. tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent model: inherit

Customer Panel of Experts

Put your customers in the room before you spend money or burn trust. This skill assembles a panel of data-grounded buyer personas and runs a real debate on whatever you're deciding — then hands you the decision, the dissent, and what to test next.

It is the flagship of the panel family. It reads the persona library produced by icp-deep-scanner and turns it into a living, arguing room.

When to use it

• "Should we raise prices 20%?" — and what each segment will actually do.
• "Here's the launch campaign for {product}. Will it land?"
• "We're killing {feature} and adding {feature}. Who revolts?"
• "Pick between positioning A and positioning B."
• Any high-stakes call where you'd normally guess what customers think.

Step 0 — Get the personas

The panel is only as good as its members. In order of preference:

1. Use an existing persona library. Look for personas/ and icp-profile.md (output of icp-deep-scanner). Load every persona file and personas/index.md.
2. Generate one now. If none exists and the user has connected tools, run icp-deep-scanner first (read-only) to build it from real data.
3. Bootstrap from input. If there's no data and no time, build 3–5 provisional personas from what the user tells you — and label the entire session "PROVISIONAL — not grounded in customer data" at the top and bottom. Never let a guessed panel masquerade as a researched one.

Data & security rules

• Connecting tools is read-only. Never write to, send from, or modify a connected source. Confirm before any exception.
• Personas are archetypes. Do not surface real customer names/emails/account IDs in the debate. Quotes must be scrubbed.
• Secrets stay in env vars / the MCP connection — never printed or stored in output.

Step 1 — Frame the decision

Restate the decision crisply and lock the variables before debating:

• The decision: one sentence, with the specific option(s) on the table.
• What changes for the customer: price, workflow, access, expectation.
• Success metric: what "this went well" means in numbers.
• Reversibility: can we walk it back, and at what cost?

If the user's ask is vague ("is this a good idea?"), tighten it into a decision with options before proceeding.

Step 2 — Seat the panel

Select 3–6 personas relevant to THIS decision (a pricing decision needs the economic buyer and a price-sensitive segment; a feature cut needs the power users who rely on it). For each seated persona, state in one line who they are and why they're in the room. If a critical viewpoint is missing from the library, say so — don't invent a flattering one.

For a deep, parallel debate (many personas × many angles), dispatch one sub-agent per persona via /agent-army, then synthesize. Otherwise run it inline.

Step 3 — Run the debate

Each persona argues in character, from their real goals, pains, and language — not as a generic critic. Structure:

1. Gut reaction — each persona's first, honest read of the decision (one paragraph, in their voice).
2. Cross-examination — personas challenge each other. The economic buyer and the end user often want opposite things; let that tension play out. Surface where one persona's win is another's loss.
3. The strongest objection — the single most dangerous reaction, stated as that customer would actually say it (and would actually act on — churn, downgrade, public complaint, silence).
4. What would change their mind — the concession, proof, or framing that flips a NO to a YES.

Keep personas honest: include the ones who will hate it. A panel that all agrees is a panel you rigged.

Step 4 — Synthesize the decision

# Customer Panel — {Decision}
Generated: {timestamp} · Panel: {persona list} · Grounding: {data-backed / PROVISIONAL}

## Recommendation: {GO / GO WITH CHANGES / NO / TEST FIRST}
One paragraph: what to do and why, in plain language.

## Vote by persona
| Persona | Verdict | Why | If it ships anyway, they will… |

## The objections that matter (ranked)
1. {Objection} — who raises it, how likely to act, blast radius, mitigation.

## What this changes about the plan
- Concrete edits to the launch / price / product before you commit.

## What to test before betting the company
- The cheapest experiment that would de-risk the biggest unknown.

## Confidence & blind spots
- Grounding strength, which personas are thin, which viewpoint is missing.

Step 5 — Offer the next move

Offer to: rerun the panel against a revised plan, hand the strongest objection to prospect-panel-simulator to test live messaging, route a pricing decision to pricing-change-strategist, or escalate a full launch to product-launch-war-room.

Guardrails recap

Grounded personas beat invented ones — and provisional panels say so loudly · read-only connections · no real PII in output · include the customers who'll hate it · every verdict ties to a persona's real motivation.