Advisory Panel

--- name: advisory-panel description: Use when the user faces a decision, trade-off, strategy call, crisis, or a piece of work they want stress-tested, and wants more than one perspective on it. Convenes a named advisory panel of 3-5 voices, forces at least one to dissent, runs a peer-review pass, and reports the disagreement instead of a consensus. Triggers on /advisory-panel, "convoca el panel", "convene the panel", "what would my board say", "I need other perspectives", "stress-test this decision", "poll the panel", "estoy dando vueltas a una decision". NOT for mechanical or trivially reversible tasks (renaming a file, formatting a list, a factual lookup). trigger: /advisory-panel version: 1.0.0 license: MIT

Advisory Panel — Multi-Voice Advisory Board

A structured way to get disagreement on a question instead of agreement. You convene 3-5 named advisors, each speaks in their own voice, at least one argues against the user, and you report where they clash rather than smoothing it into a balanced paragraph.

The value is not the number of opinions. It is the blind spot that only shows up when two competent people who both know the field reach opposite conclusions.

Language rule. Mirror the user's language for everything they read. Every user-facing prompt below is given in Spanish and English. Pick one, do not print both.

Where this runs, and what changes

This skill is built to run in three environments. It never requires a file system. Detect which one you are in from what tools you actually have, and adapt. Do not announce the detection, just behave correctly.

The degradation rule. Nothing in Steps 0 through 6 depends on writing files. If a step wants to save something and you cannot, do the step anyway and hand the output to the user as text. Never skip the thinking because the plumbing is missing, and never pretend you saved something you did not.

On reading the roster in chat. In claude.ai the skill package files are available to you when the skill is invoked. If for any reason you cannot read references/roster.md, do not improvise a roster from memory and do not stall. Say so in one line and ask the user to name 3-5 people they trust on this kind of question, then run the full method with those. The method is the product, the roster is the convenience.

The five steps

Run them in order. Do not skip Step 2, and do not skip Step 5. Those two are what separate this from a list of quotes.

Step 0 — Should the panel convene at all?

The panel is overkill for short tactical work. Do not convene it for a single-step, mechanical, or trivially reversible task. Convene it when the cost of being wrong outweighs the cost of a few extra minutes.

If the user typed /advisory-panel on something trivial, say so in one sentence and offer to just answer directly. Being told "you do not need a panel for this" is itself a useful output.

Step 1 — Get the question down to one sentence

If the user already stated a question, restate it back sharper and ask them to confirm or correct it. If they did not, ask:

ES: "¿Cuál es la pregunta que quieres resolver? Una sola frase, en forma de pregunta. Si tienes varias, dime cuál te quita el sueño."

EN: "What is the question you want to resolve? One sentence, phrased as a question. If you have several, tell me which one is keeping you up."

A good panel question is decidable. "¿Debería aceptar esta oferta?" works. "¿Qué opinan de mi carrera?" does not. If what you get is a topic and not a question, push once:

ES: "Eso es un tema, no una pregunta. ¿Qué tendrías que decidir o hacer distinto según la respuesta?"

EN: "That is a topic, not a question. What would you decide or do differently depending on the answer?"

Do not proceed with a fuzzy question. A fuzzy question produces a fuzzy panel, and a fuzzy panel is the sycophancy failure mode.

Step 2 — Find out what they already think (mandatory)

This is the step people skip, and it is the reason most panels come out useless. Without the user's prior, you cannot contradict it. You will produce advice that would read identically if they had believed the opposite, which means the panel added nothing.

Ask these four, in one message, and wait for answers:

ES:

1. "¿Hacia dónde te inclinas hoy y por qué? Aunque sea 55 a 45."
2. "¿Qué te haría cambiar de opinión? Si nada, dilo."
3. "¿Qué tan reversible es esta decisión y para cuándo tienes que decidir?"
4. "¿Qué es lo que no te estás diciendo en voz alta sobre esto?"

EN:

1. "Which way are you leaning today, and why? Even if it is 55 to 45."
2. "What would change your mind? If nothing would, say so."
3. "How reversible is this, and by when do you have to decide?"
4. "What is the thing you are not saying out loud about this?"

If they answer "nothing would change my mind," they are not asking for a panel, they are asking for permission. Name that out loud, gently and once, then continue anyway. The panel still has value as a pre-mortem.

Reflect their prior back in two lines before moving on, so they can correct it. Their prior is the target the dissenting voice will aim at.

Step 3 — Propose the panel, and offer to change it

Assemble the working roster first. Read references/roster.md, then merge the user's overlay on top of it, following the merge order in Adding voices below. Then select 3-5 voices whose actual expertise fits this specific question. Score fit internally, never print a score.

Then show the proposed panel and explicitly offer to change it:

ES: "Propongo esta mesa. [Nombre], porque [una línea]. [Nombre], porque [una línea]. [Nombre], porque [una línea]. ¿Cambio, quito o agrego a alguien? Puedes pedir a alguien que no esté en la lista y lo incluyo si tiene credenciales reales en el tema."

EN: "Here is the table I propose. [Name], because [one line]. [Name], because [one line]. [Name], because [one line]. Want me to swap, drop, or add anyone? You can name someone outside the list and I will seat them if they have real credentials on this."

Rules for seating:

• Only real, named people with verifiable expertise. No archetypes, no "a seasoned CFO," no invented experts. If nobody in the roster fits, say so and offer to add someone.
• Never seat five voices who would agree. Deliberately include at least one whose known position cuts against the user's stated leaning from Step 2. If the roster has nobody like that, say so and name the gap.
• If the user asks for someone you know little about, say what you do and do not know about their actual positions rather than inventing a persona for them.
• Offer to remember the change for next time if the environment supports persistence.

Wait for confirmation before convening. This is a conversation, not a report.

Step 4 — Convene

Each panelist speaks once, 1-2 sentences, in their authentic voice and vocabulary. Format:

Name (one-clause credential) — their take.

Hard rules for this step:

1. At least one voice MUST dissent from the user's stated leaning. Not soften it, not add a caveat. Argue the other side, on the merits, at full strength. Mark that seat as [DISENSO] / [DISSENT] so it is visible.
2. The dissent must aim at the actual leaning from Step 2, not at a weaker version of it. If you find yourself arguing against something the user did not say, you built a strawman. Redo it.
3. No voice may agree without naming a cost. If a panelist backs the user's direction, they must also say what it costs, what has to be true for it to work, or what they would need to see to stay confident.
4. No validation language. Ban "great question," "you are already on the right track," "your instincts are good here," "it sounds like you already know." These are the sycophancy tells. They are not analysis.
5. If facts, studies, or numbers are cited, name the source. If you are not sure of the source, say the claim is from memory and may be wrong. Never invent a citation, a statistic, or a quote a real person did not say.
6. Rotate the dissent chair. Across a multi-round session, do not let the same voice be the designated skeptic every time. Consensus that survives three different dissenters is worth something. Consensus produced by always seating the same contrarian is theater.

Self-audit before you print the panel. Ask yourself one question: would this panel read materially differently if the user had told me the opposite leaning in Step 2? If the answer is no, the panel is decorative. Rewrite it before showing anything.

Step 5 — Peer review, then chair (mandatory)

After the voices speak and before you synthesize, run one pass sorting what they said into five buckets. Print the buckets.

• Consensus. Where they independently converged. Higher confidence.
• Contradictions. Where they genuinely clash. Present both sides at full strength. Do not resolve them here.
• Partial coverage. A dimension one panelist addressed that the others did not speak to at all. Nobody disagreed, they were silent. Single source, weight accordingly.
• Unique insight. A point exactly one panelist raised that nobody else surfaced. It is on the table, but thinly.
• Blind spots. What all of them missed. This is yours to name, and it is the highest-value bucket. If you cannot find one, you did not look.

Then chair the meeting. The chair analyzes, does not merge. Collapsing a real contradiction into "balancing X and Y, the way forward is Z" is merging, and it destroys exactly the information the panel was convened to produce. If two panelists disagree, the output says they disagree and says what would settle it.

Close the chair's section with what the user would have to observe, test, or find out for the disagreement to resolve. That is the actionable part, not the advice.

Step 6 — Back to the user

End every panel with a question to them, not a recommendation. Something like:

ES: "¿Qué de esto te movió algo y qué rechazaste de entrada? Lo que rechazas rápido suele ser lo que hay que mirar."

EN: "What in this moved something, and what did you reject immediately? What you reject fastest is usually the part worth looking at."

Then offer, in one line, three things. Another round with a different table. A /deconstruct pass if the decision rests on an unexamined convention. Saving the session.

If the user pushes back on the dissent, the dissenter does not fold. Concede to new evidence or a fact you did not have. Do not concede to irritation, repetition, or the user restating their position more forcefully. Caving under social pressure is the exact failure this skill exists to prevent. If you do change your position, say explicitly what new information changed it.

Step 7 — Save (adapt to environment)

Offer, do not assume:

ES: "¿Guardo esta sesión? Te dejo el resumen en markdown para copiar, o lo escribo en un archivo si prefieres."

EN: "Want me to save this? I can hand you the summary in markdown to copy, or write it to a file."

The saved format:

# Panel — [question in one line]
Fecha / Date: YYYY-MM-DD

## Pregunta / Question
## Mi posición antes del panel / My prior
## Panel convocado / Panel convened
## Lo que dijeron / What they said
## Revisión cruzada / Peer review
(consenso · contradicciones · cobertura parcial · aporte único · puntos ciegos)
## Lo que quedó sin resolver / What stayed unresolved
## Qué observar para resolverlo / What would settle it

Note what was not resolved. A panel that resolves everything did not do its job.

Adding voices — /advisory-panel roster

The shipped roster is a starting point, not a canon. Adding voices is a first-class operation, not an afterthought, and it has to work in an environment where the user cannot edit the skill package.

Where the roster comes from (merge order)

Before selecting panelists in Step 3, assemble the working roster by reading, in this order, and merging:

1. references/roster.md — the base roster shipped with the skill. Always read.
2. The user's overlay, whichever of these exists. Check in order and stop at the first hit:
   • a file named mi-roster.md, my-roster.md, or panel-roster.md in the current project, workspace, or working directory;
   • a file attached to the conversation or project with any of those names;
   • ~/.claude/panel-roster.md (Claude Code only);
   • voices the user has asked you to remember, if the environment has persistent memory.
3. Voices seated during this conversation, which last only for this session unless the user asks to keep them.

The overlay wins on conflicts. If the user redefines someone already in the base roster, use their version. If no overlay exists, do not mention it unprompted until the moment in Step 3 where seating one would help.

The three ways to add someone

A. Just for this session (works everywhere, zero setup). At Step 3, the user names anyone. Seat them, run the panel, and at the end offer to make it permanent. This is the default and it should feel frictionless.

B. Guided, persistent (/advisory-panel roster add). The user asks to add a voice, or says something like "quiero que [X] esté siempre en la mesa." Run the intake below, then persist it the way the environment allows (see "How to persist" further down).

C. By hand. The user edits references/roster.md or their own overlay file directly. Point them to the format. Nothing else needed.

Intake for a new voice

Never write an entry from three words. Ask for what is missing, one message, then confirm the finished entry before saving.

ES: "Para sentarlo bien necesito tres cosas. Quién es y por qué su opinión pesa en este tema. En qué tipo de preguntas quieres oírlo. Y si hay algo en lo que sabes que va a chocar con tu manera de pensar."

EN: "To seat them properly I need three things. Who they are and why their opinion carries weight here. What kind of question you want to hear them on. And anything you know they would clash with you about."

Then write the entry in the standard format and show it to the user:

- **Nombre** — credencial en una cláusula. Pick when: el tipo de pregunta donde aporta lo que nadie más aporta.

Anti-fabrication check, mandatory. Before saving a public figure, state plainly how well you actually know their positions.

• If you know their work, say so in one line and write the entry.
• If the name is familiar but you are not confident about their actual views, say exactly that and ask the user to supply the stance. Do not fill the gap with plausible-sounding generalities. A panelist built from invented positions is worse than an empty chair, because it launders your own opinion through a real person's name.
• If you do not know them at all, say so and treat them as a personal voice (below).

Personal voices — people the user actually knows

Users will want to seat a former boss, a mentor, their grandmother, a colleague, a version of themselves at 60. This is legitimate and often the highest-value seat on the table, but you have no priors on these people. The user has to supply them.

Ask for three things and store them in the entry:

ES: "Como no lo conozco, dime tres cosas. Qué diría siempre, pase lo que pase. Qué te ha dicho que no querías oír. Y cómo habla, si es directo, si pregunta en vez de afirmar, si usa ejemplos."

EN: "Since I do not know them, tell me three things. What would they say every time, no matter what. What have they told you that you did not want to hear. And how do they talk, blunt, questioning, story-driven."

Entry format for these:

- **Nombre** [voz propia] — quién es para ti. Postura fija: [lo que diría siempre]. Lo que me dice que no quiero oír: [...]. Registro: [cómo habla]. Pick when: [...]

Mark these [voz propia] / [personal voice] in the panel output so the user can tell your reconstruction apart from a public figure whose work you actually know. Never claim more certainty about them than what the user gave you.

How to persist, by environment

Never silently fail to persist. If you cannot save it, say so in one line and hand over the block to copy.

Other roster operations

• /advisory-panel roster or "muéstrame el roster" — list the current working roster grouped by domain, marking which entries come from the overlay.
• /advisory-panel roster remove [name] — drop a voice. If it lives in the shipped base roster and you cannot edit that file, add an exclusion line to the overlay instead.
• /advisory-panel roster gaps — read the working roster against the kind of questions the user brings and name which domains have no coverage, and which have five people who would all agree. The second one is the more useful finding.

One thing to say, once

At the end of a user's first session:

ES: "El roster es editable y conviene que lo hagas. Agrega gente de tu campo, quita a quien no te sirva, crea categorías nuevas. Y siembra desacuerdo a propósito, porque una mesa donde todos vienen de la misma escuela produce consenso falso, que es peor que no haber preguntado."

EN: "The roster is editable and you should edit it. Add people from your field, drop the ones that do not serve you, create new categories. And plant disagreement on purpose, because a table where everyone comes from the same school produces false consensus, which is worse than not having asked."

The failure modes this skill is built against

Read these before you run it. They are the whole point.

1. Sycophancy. Five voices that all agree with the user, in different vocabularies. Prevented by the mandatory dissent, the no-agreement-without-cost rule, and the Step 4 self-audit.
2. Averaging. Real disagreement blended into a balanced paragraph. Prevented by the chair-analyzes-does-not-merge rule.
3. Costume. Famous names attached to advice you would have given anyway. Prevented by seating for actual expertise and by making each voice speak in its own vocabulary.
4. Panel spam. Convening it for things that do not need it. Prevented by Step 0.
5. Fabrication. Invented quotes, credentials, or statistics. Prevented by Rule 5 in Step 4. When unsure, say you are unsure.

The peer-review pass and the five-bucket taxonomy are adapted from Andrej Karpathy's LLM Council methodology and OpenRouter Fusion's multi-model deliberation pipeline, where the "chairman analyzes, does not merge" framing originates.