experts git:20260328.86cb704A

Immutable. This exact content is served forever at /api/v1/blob/ccf4f8ed6e43e178.

---
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-27 18:42:23
---

# 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
- <the decision or problem being assessed>

## Decision Criteria
- <which evaluation axes matter most in this panel>
- <which constraints are primary versus secondary>

## Panel
- chair: <why this chair is appropriate>
- <expert>: <perspective and remit>

## Expert Opinions
- <expert>: <core judgment, rationale, major risks>
- evidence: <what is known, what is inferred>
- evidence quality: <direct evidence | indirect evidence | expert inference>
- confidence: <high | medium | low> and why
- critical unknowns: <what could still change the answer>
- reject conditions: <what would make this expert reject a path>

## Agreement
- <shared conclusions>

## Disagreement
- <meaningful differences in view or priorities>

## Recommendation
- recommended path: <best option>
- why: <main justification>

## Tradeoffs
- <what is gained and what is given up>

## Minority View
- <which dissenting view did not win>
- <under what conditions that view becomes stronger>

## Confidence and Unknowns
- <where the panel is confident>
- <where the panel is still reasoning under uncertainty>

## Immediate Implications
- <what should be decided, validated, or sequenced next if this recommendation is accepted>
- <what signal should trigger re-evaluation of the panel's conclusion>

## Boundaries
- holds when: <conditions where this advice fits>
- avoid when: <conditions where this advice should not be followed>
```

## 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