--- name: experts description: Assemble a panel of experts to assess a problem from multiple professional perspectives, surface agreement and disagreement, and deliver a chaired recommendation with clear tradeoffs. Use when the user wants multi-expert judgment, a second opinion, design critique, option comparison, or a recommendation backed by distinct expert viewpoints. metadata: name: Experts description: Assemble a focused panel of experts to assess a problem, surface tradeoffs, and deliver a chaired recommendation. author: Flcă‚› created: 2026-03-27T10:42:23Z --- # Experts Assemble a focused panel of experts around one problem and produce a chaired recommendation. This is a cross-domain expert panel skill for complex decisions. It is not limited to one industry or problem class, but every expert seat must still meet the same expert-grade standard. This skill is for expert judgment first. It is not a generic task router. ## Operating Mode - Use this skill when the user wants expert advice, a multi-angle assessment, a second opinion, or a recommendation with explicit tradeoffs. - Treat explicit invocation of `$experts` as permission to assemble a panel of subagents when the environment supports it. - Prefer domain experts over generic worker roles. - Require each expert to form an independent view before seeing other experts' conclusions. - Treat disagreement as useful output, not failure. - Keep the final answer focused on judgment, rationale, tradeoffs, and boundaries. - When the environment supports subagents and parallel delegation, prefer true multi-expert execution with independent opinions gathered in parallel where safe. - When the environment does not support subagents or parallel delegation, simulate the same panel structure in one thread by producing clearly separated expert viewpoints before synthesis. - Do not collapse the panel into one blended answer just because execution is single-threaded. ## Resource Map Read [references/roles-index.md](references/roles-index.md) first. Then load only the expert cards that match the problem. Common expert cards: - [references/role-chair.md](references/role-chair.md) - [references/role-architect.md](references/role-architect.md) - [references/role-frontend-expert.md](references/role-frontend-expert.md) - [references/role-backend-expert.md](references/role-backend-expert.md) - [references/role-product-expert.md](references/role-product-expert.md) - [references/role-security-expert.md](references/role-security-expert.md) - [references/role-privacy-expert.md](references/role-privacy-expert.md) - [references/role-performance-expert.md](references/role-performance-expert.md) - [references/role-data-expert.md](references/role-data-expert.md) - [references/role-devops-expert.md](references/role-devops-expert.md) - [references/role-platform-expert.md](references/role-platform-expert.md) - [references/role-mobile-expert.md](references/role-mobile-expert.md) - [references/role-search-expert.md](references/role-search-expert.md) - [references/role-payments-expert.md](references/role-payments-expert.md) - [references/role-compliance-expert.md](references/role-compliance-expert.md) - [references/role-ml-expert.md](references/role-ml-expert.md) - [references/role-itinerary-expert.md](references/role-itinerary-expert.md) - [references/role-budget-travel-expert.md](references/role-budget-travel-expert.md) - [references/role-travel-risk-expert.md](references/role-travel-risk-expert.md) - [references/role-family-travel-expert.md](references/role-family-travel-expert.md) - [references/role-local-transport-expert.md](references/role-local-transport-expert.md) - [references/role-experience-curator.md](references/role-experience-curator.md) - [references/role-destination-culture-expert.md](references/role-destination-culture-expert.md) - [references/role-information-discovery-expert.md](references/role-information-discovery-expert.md) - [references/role-source-verification-expert.md](references/role-source-verification-expert.md) - [references/role-recency-expert.md](references/role-recency-expert.md) - [references/role-coverage-analyst.md](references/role-coverage-analyst.md) - [references/role-signal-vs-noise-analyst.md](references/role-signal-vs-noise-analyst.md) - [references/role-qa-expert.md](references/role-qa-expert.md) - [references/example-platform-modernization-panel.md](references/example-platform-modernization-panel.md) - [references/example-analytics-dashboard-panel.md](references/example-analytics-dashboard-panel.md) - [references/example-subscription-billing-panel.md](references/example-subscription-billing-panel.md) - [references/example-ai-assistant-panel.md](references/example-ai-assistant-panel.md) - [references/example-task-local-identity-panel.md](references/example-task-local-identity-panel.md) - [references/example-family-japan-panel.md](references/example-family-japan-panel.md) - [references/example-istanbul-culture-panel.md](references/example-istanbul-culture-panel.md) - [references/example-ai-release-watch-panel.md](references/example-ai-release-watch-panel.md) - [references/example-acquisition-rumor-panel.md](references/example-acquisition-rumor-panel.md) - [references/task-local-expert-template.md](references/task-local-expert-template.md) Read the example only when you need a high-quality reference for what a professional panel output should look like. ## Panel Modes Choose one mode before assembling the panel: - `advisory`: provide expert judgment and recommendation only - `decision-support`: provide recommendation plus a concrete next-step plan - `deep-dive`: investigate a complex problem with more evidence gathering before recommendation Use `advisory` by default unless the user asks for execution planning or deeper analysis. ## Workflow Follow this sequence unless the user asks for a narrower deliverable. ### 1. Frame the question Extract and restate: - the exact question to be assessed - the desired decision or output - known constraints, assumptions, and approvals - relevant code, documents, systems, or artifacts - time sensitivity - the panel mode Reduce vague requests into a precise assessment question before assembling the panel. ### 2. Select the panel Choose a small panel with one `chair` and two to six experts. Pick experts that match the real decision surface. Prefer distinct viewpoints over panel size. Use the role cards in [references/roles-index.md](references/roles-index.md) when they fit. If no card fits cleanly, synthesize a task-local expert with a clearly named professional lens and explicit remit. ### 2a. Synthesize a task-local expert when needed Create a task-local expert only when the registry does not cover a real decision lens. A task-local expert must: - represent a genuine expert discipline, not an ad hoc job title - have a narrow and defensible professional lens - be likely to disagree with at least one other expert for substantive reasons - add decision value that cannot be cleanly absorbed by an existing card Do not create fake-specialized seats such as: - feature-name experts - implementation-step experts - generic smart-reviewer variants - duplicate experts that only rephrase another card When you create a task-local expert, read [references/task-local-expert-template.md](references/task-local-expert-template.md) and define: - expert name - professional lens - decision surface - required evidence - core evaluation criteria - critical unknowns - reject conditions - explicit non-goals and boundary with nearby experts Task-local experts are valid only for the current panel unless the user explicitly asks to persist them into the library. ### 3. Gather independent opinions Ask each expert to assess the problem independently. Each opinion should cover: - core judgment - evidence basis and what is inferred versus directly observed - confidence level and the main reason for that confidence level - reasoning and assumptions - preferred option - main risks - critical unknowns that could change the recommendation - decision thresholds that would cause the expert to change position - what the expert would reject and why Do not let experts anchor on each other too early. If experts are running in parallel, gather these opinions independently before cross-examination. If experts are running in a single thread, still keep the outputs structurally independent: - write each expert section separately - do not let later experts silently inherit prior conclusions - preserve disagreement even when the same agent is simulating multiple seats ### 4. Run cross-examination After independent opinions exist, ask experts to challenge each other. Focus on: - hidden assumptions - underestimated costs - ignored failure modes - disagreement about priorities - conditions under which another expert would be right Keep this phase evidence-driven and concise. ### 5. Deliver the chaired recommendation The `chair` synthesizes the panel into a decision-ready output. Return: - the question - the final panel - each expert's core view - the evidence and confidence profile behind each view - agreement points - disagreement points - the recommended path - tradeoffs and risks - boundaries where the recommendation does or does not hold When the user asks to proceed, include a short next-step plan after the recommendation. Do not turn the report into a full execution playbook unless explicitly requested. ## Expert Standards Apply these rules to every expert: - Act as the most senior expert for the assigned perspective. - Stay rigorous, concrete, and scope-bound. - Prefer defensible reasoning over confident tone. - Distinguish observed facts from inference and speculation. - State confidence level and what would increase or decrease it. - Make assumptions explicit. - Name the key unknowns that prevent a stronger recommendation. - State reject conditions, not just preferred outcomes. - Push back on weak framing, false binaries, and unsupported claims. - Optimize for helping the user make a better decision, not for winning an argument. ## Selection Rules - Prefer the smallest panel that can expose meaningful tradeoffs. - Prefer domain experts to generic reviewers. - Add a role expert only when a domain lens is not enough. - Avoid duplicate experts with the same perspective. - Expand the panel only when the decision has genuine cross-functional risk. - If one expert would dominate because the question is narrow, use fewer experts and state that clearly. ## Output Structure Use this structure when returning a panel result: ```markdown # Expert Panel Report ## Question - ## Decision Criteria - - ## Panel - chair: - : ## Expert Opinions - : - evidence: - evidence quality: - confidence: and why - critical unknowns: - reject conditions: ## Agreement - ## Disagreement - ## Recommendation - recommended path: - why:
## Tradeoffs - ## Minority View - - ## Confidence and Unknowns - - ## Immediate Implications - - ## Boundaries - holds when: - avoid when: ``` ## Decision Rules - Prefer explicit tradeoffs over vague best practices. - Prefer recommendations that match the user's real constraints, not an idealized environment. - State uncertainty when the evidence is incomplete. - Keep minority concerns when they materially affect risk. - Separate recommendation quality from implementation difficulty. - If the panel lacks a necessary perspective, say so and adjust the panel before concluding. ## Red Flags Stop and reassess if: - the question is still too vague to judge - the panel contains overlapping experts with no distinct lens - experts are repeating the same argument in different words - the recommendation hides unresolved disagreement - evidence is too thin for a credible conclusion - the user is asking for implementation but the panel has only produced advice