Experts

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

• references/role-chair.md
• references/role-architect.md
• references/role-frontend-expert.md
• references/role-backend-expert.md
• references/role-product-expert.md
• references/role-security-expert.md
• references/role-privacy-expert.md
• references/role-performance-expert.md
• references/role-data-expert.md
• references/role-devops-expert.md
• references/role-platform-expert.md
• references/role-mobile-expert.md
• references/role-search-expert.md
• references/role-payments-expert.md
• references/role-compliance-expert.md
• references/role-ml-expert.md
• references/role-itinerary-expert.md
• references/role-budget-travel-expert.md
• references/role-travel-risk-expert.md
• references/role-family-travel-expert.md
• references/role-local-transport-expert.md
• references/role-experience-curator.md
• references/role-destination-culture-expert.md
• references/role-information-discovery-expert.md
• references/role-source-verification-expert.md
• references/role-recency-expert.md
• references/role-coverage-analyst.md
• references/role-signal-vs-noise-analyst.md
• references/role-qa-expert.md
• references/example-platform-modernization-panel.md
• references/example-analytics-dashboard-panel.md
• references/example-subscription-billing-panel.md
• references/example-ai-assistant-panel.md
• references/example-task-local-identity-panel.md
• references/example-family-japan-panel.md
• references/example-istanbul-culture-panel.md
• references/example-ai-release-watch-panel.md
• references/example-acquisition-rumor-panel.md
• references/task-local-expert-template.md

Panel Modes

• 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

advisory

Workflow

1. Frame the question

• 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

2. Select the panel

chair

2a. Synthesize a task-local expert when needed

• 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

• feature-name experts
• implementation-step experts
• generic smart-reviewer variants
• duplicate experts that only rephrase another card

• expert name
• professional lens
• decision surface
• required evidence
• core evaluation criteria
• critical unknowns
• reject conditions
• explicit non-goals and boundary with nearby experts

3. Gather independent opinions

• 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

• 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

• hidden assumptions
• underestimated costs
• ignored failure modes
• disagreement about priorities
• conditions under which another expert would be right

5. Deliver the chaired recommendation

chair

• 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

Expert Standards

• 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

# 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

• 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