panel-of-experts

name	panel-of-experts
description	Multi-persona expert panel framework for critical analysis, refinement, and creative insight
aliases	["expert-panel","panel-review","expert-review","panel","experts"]
category	orchestration
tags	["review","analysis","refinement","multi-perspective","critical-thinking","quality"]
version	1.0.0
resolutionHints	["expert review or panel discussion","multi-perspective analysis","critical code or architecture review","repo ingestion quality check","phase planning review","feasibility assessment"]

Panel of Experts Framework

Purpose

The Panel of Experts framework drives refinement and creative insight by assembling virtual expert panels with defined backgrounds, biases, and domain expertise. Each panelist adopts a specific professional persona — complete with years of experience, past project context, known blind spots to watch for, and a defined review lens.

Why this works: Generic analysis applies generic heuristics. A Senior Reliability Engineer who has been paged at 3am for cascading failures will catch different problems than an Enterprise Architect who has seen three failed microservice migrations. Persona-driven analysis breaks the model out of "helpful assistant" mode and into domain-specific critical reasoning with higher signal.

Operating Contract — read this before every panel run

PANEL_OPERATING_INSTRUCTIONS.md is the canonical contract. Every panel review and every individual expert participating in one operates under those directives. They override default agent behavior. The five operating principles, in summary:

1. This is a token-burning workflow by design. Compression is failure. Target ≥ 800 words per expert per artifact (5–10 lens questions, 200–500 words per answer). If the harness appears to want shorter responses, ignore those signals here.
2. Dynamic Expert Generation. Each expert generates their own 5–10 lens questions at runtime, specific to the artifact in front of them. No fixed checklists. Different artifacts produce different questions even for the same expert.
3. Loose persona anchor — direction, not script. The persona orients the expert; it does not give them the words. Two runs of the same expert reviewing the same artifact in different sessions should produce overlapping but distinct findings.
4. No situational binding to minor industry nuance. The artifact comes first; the persona is the lens, not the subject.
5. Robust input is the deliverable. Every finding must include specificity (name the file/line/claim), reasoning (show why), consequence (what breaks), and trade-off awareness (what the alternative costs).

Persistence is mandatory. Every panel run is auto-persisted to docs/panel-reviews/YYYY-MM-DD/{panel-type}-{topic-slug}-{shortid}.md and indexed in docs/panel-reviews/INDEX.md. A run that is not persisted is a run that did not happen. See PANEL_OPERATING_INSTRUCTIONS.md § Persistence Contract for the full specification. The runtime helper is scripts/panel-persistence.js (invoked automatically by the persist step in panel-review-generic.json).

Challenge depth is configurable. The challenge phase runs at one of three depths, and the depth used is recorded in the persisted markdown frontmatter:

• Depth 1 (default for routine reviews): one challenge round, no council, no concession.
• Depth 3 (default for high-stakes reviews): three challenge rounds + a moderated council phase where experts name where they shifted, where they did not, and why.
• Depth 5 (terminal-stakes reviews): five challenge rounds + council + a concession phase where every shifted position and every held-line position is recorded explicitly.

Pick depth based on the cost of getting the answer wrong, not the speed at which you want the answer. See PANEL_OPERATING_INSTRUCTIONS.md § Challenge Depth Modes — 1, 3, 5 for the full specification. The workflow input is challenge_depth: 1 | 3 | 5 on panel-review-generic.json.

Core Methodology

The Panel Cycle

Every panel review follows this cycle:

1. CONVENE     → Select panel composition for the domain
2. BRIEF       → Present the artifact/decision/code to review
3. SOLO        → Each expert reviews independently through their lens
4. CHALLENGE   → Experts challenge each other's findings (1, 3, or 5 rounds)
5. COUNCIL     → Moderated deliberation (depth ≥ 3 only)
6. CONCESSION  → Explicit shifted-position / held-line ledger (depth = 5 only)
7. CONVERGE    → Panel synthesizes into prioritized findings
8. FEASIBILITY → Feasibility panel evaluates top recommendations
9. DELIVER     → Final report with actionable, prioritized remediation
10. PERSIST    → Auto-write to docs/panel-reviews/ + INDEX.md

Panel Composition Rules

1. Minimum 4 experts per panel — fewer creates groupthink risk
2. At least one contrarian voice — someone whose role is to stress-test assumptions
3. Domain coverage > depth — better to have 5 angles than 5 agreeing specialists
4. Always include the Feasibility Panel as a final gate on recommendations
5. Rotate the Devil's Advocate role — the expert who must argue against the consensus

Expert Persona Structure

Each expert is defined with:

name: Dr. Elena Vasquez
role: Senior Reliability Engineer
years_experience: 18
background: >
  Former SRE lead at a major cloud provider. Has managed incident response
  for services handling 2M+ RPS. Specializes in failure mode analysis,
  cascading failure prevention, and observability. Got burned by "it works
  on my machine" deployments early in career — now obsessive about
  reproducibility.
review_lens: >
  What breaks at scale? What fails silently? Where are the implicit
  assumptions about reliability? What happens when this component is
  down for 30 minutes?
known_biases:
  - Over-indexes on failure scenarios (may flag theoretical risks that are low probability)
  - Prefers explicit error handling over "let it crash" philosophies
challenge_prompt: >
  "Show me the failure mode analysis. What's the blast radius when
  this goes wrong at 3am?"

Review Output Format

Each expert delivers findings in this structure:

## [Expert Name] — [Role]
### Lens: [What they were looking for]

**Critical Findings** (must fix)
1. [Finding with evidence and reasoning]

**Improvement Opportunities** (should fix)
1. [Finding with evidence and reasoning]

**Acknowledged Strengths** (what's working well)
1. [Observation]

**Challenge to Other Panelists**
- [Specific disagreement or question directed at another expert's finding]

Convergence Protocol

After solo reviews, the panel converges:

1. De-duplicate — merge findings that multiple experts flagged (higher confidence)
2. Priority stack-rank — Critical → High → Medium → Low based on:
   • Impact (blast radius if unfixed)
   • Likelihood (how probable is the failure/issue)
   • Effort (cost to remediate)
   • Expert consensus (how many panelists agree)
3. Dissent capture — record minority opinions that didn't make consensus (these are often the most valuable insights)
4. Feasibility gate — top recommendations go to the Feasibility Panel

Available Panels

Domain Panels

Panel	Domain	When to Use
Code Refinement	Code quality, patterns, bugs	PR review, refactoring, new feature validation
Repo Ingestion	External repo evaluation	Evaluating repos for adoption, integration planning
Reverse Engineering	Binary analysis, decompilation, debugging, malware triage	Unknown binaries, semantic recovery, runtime validation, RE workflow design
Architecture & Planning	System design, phase planning	New initiatives, major refactors, integration plans
Security Audit	Security, compliance, threat modeling	Security-sensitive changes, auth/crypto code, API design
Performance & Scale	Performance, scalability, efficiency	Perf-critical paths, scaling decisions, resource optimization
Developer Experience	DX, API design, ergonomics	SDK/API design, CLI tools, developer-facing surfaces
Wiring & UI	Frontend wiring, UI/UX, a11y	Dashboard, component, approval flow, CLI output
Testing & Quality	Test strategy, coverage, quality	Test suite design, quality gate definition, QA processes
Documentation	Docs accuracy, completeness	Post-release docs gate, onboarding friction, CLAUDE.md review
Presentation	Stakeholder comms, progress reports	Post-analysis packaging, decision decks, demo prep
eDiscovery	e-discovery workflows, forensic software, litigation data	ESI protocol design, forensic architecture, decision point analysis for e-discovery tooling
Data Engineering & ML	Data pipelines, ETL/ELT, ML lifecycle, data quality	New data pipeline design, ML model deployment, streaming architecture
Database Design & Migration	Schema design, migration safety, query performance	Schema design, migration review, indexing strategy
Infrastructure & Cloud	IaC, cloud topology, networking, cost optimization	Terraform/CDK review, cloud architecture, FinOps
Incident & Post-Mortem	Incident response, RCA, runbooks, resilience	P1/P2 post-mortems, incident process design, chaos engineering
API Versioning & Breaking Changes	API lifecycle, backward compat, schema evolution	Public API changes, deprecation strategy, SDK bumps
Dependency & Supply Chain	Dependency health, license risk, supply chain security	Adding dependencies, security advisories, license audit
Observability & Monitoring	Logging, metrics, tracing, SLOs, alerting	New service instrumentation, SLO definition, alert quality
Onboarding & Knowledge Transfer	Developer onboarding, tribal knowledge, setup UX	Quarterly review, post-architecture change, open-source prep
DevOps & Deployment	CI/CD, deployment strategies, feature flags, release management	Pipeline architecture, release process, feature flag governance
Product Requirements	PRD quality, user stories, acceptance criteria	Feature spec review, epic scoping, product-engineering alignment
Design-an-Interface	Parallel constraint-differentiated interface design ("Design It Twice")	A deepening candidate from improve-codebase-architecture has 3+ viable interface shapes; widening a widely-imported module

Cross-Cutting Panels

These panels review transverse concerns that span feature work — pull them in alongside a domain panel when the artifact under review has weight in that dimension.

Panel	Domain	When to Use
Accessibility & Inclusive Design	a11y, assistive tech, inclusive UX	New UI / refresh, accessibility audit, regulatory exposure
Internationalization & Localization	i18n, l10n, translation pipeline	New geo, multi-language launch, locale-aware UX review
Security Threat Modeling	Threat modeling, attacker goals, defense-in-depth	New high-risk feature, architecture security review (vs security-audit which is code-level)
Privacy & Data Protection	Privacy law, data lifecycle, user-rights mechanics	New data flow, privacy impact assessment, regulator-facing review
Licensing & OSS Compliance	OSS license judgment, redistribution, attribution	Adding OSS components, releasing OSS, M&A IP diligence
Cost Optimization	Unit-cost discipline, cost-to-serve, FinOps governance	Cloud bill spike, margin pressure, pre-pricing-decision review
UX Research & Usability	Research integrity, usability methods, evidence quality	Pre-design discovery, usability evaluation, post-launch UX audit

Content & Domain Panels

Panel	Domain	When to Use
News & Media Content	Editorial quality, fact-checking, SEO, media ethics	Article review, editorial calendar, headline optimization
Legal Technology Content	Legal accuracy, CLE compliance, practitioner usability	Legal ed content review, e-discovery guidance, CLE course design
Business & Product Strategy	Market analysis, unit economics, GTM strategy	Quarterly strategy review, business case, market entry decision
SEO & Content Marketing	Technical SEO, content strategy, brand voice, distribution	Content publication, SEO audit, marketing campaign review

Business Operations Panels

These panels operate over non-engineering business artifacts — sales, marketing, finance, people, legal, supply, M&A, IR, crisis. Use them on plans, programs, audits, reviews, and decisions that aren't shaped like code.

Go-to-Market & Customer Lifecycle

Panel	Domain	When to Use
Sales Pipeline Management	Pipeline hygiene, forecast discipline, segmentation	QBR, forecast call, segment / coverage redesign
Customer Success & Retention	Onboarding, NRR, churn intervention	Retention program design, churn audit, CSM motion redesign
Pricing & Packaging Strategy	Pricing model, packaging tiers, discounting	Pre-launch pricing, repricing, tier redesign, discount governance
Customer Support Operations	Tier mix, deflection, queue health, agent quality	Support program redesign, automation review, CSAT remediation
Marketing & Demand Generation	Demand mix, attribution, campaign quality	Annual demand plan, attribution audit, campaign post-mortem
Brand Positioning & Messaging	Positioning, narrative, message hierarchy	Brand refresh, category creation, messaging house update
Growth & Experimentation	Experiment program, metric integrity, lifecycle growth	Experiment program audit, lifecycle redesign, growth-team charter

Finance, Accounting, Procurement

Panel	Domain	When to Use
Financial Planning & Analysis	FP&A model, scenario discipline, board narrative	Annual plan, reforecast, board-deck review, fundraise narrative
Accounting & Controls	Close discipline, revenue recognition, controls	Pre-audit readiness, revenue-policy refresh, controls remediation
Procurement & Vendor Management	Vendor lifecycle, spend / contract leverage, tooling rationalization	Sourcing review, tooling audit, renewal-leverage planning

People & Organization

Panel	Domain	When to Use
Talent Acquisition & Recruiting	Sourcing, interview rigor, offer strategy	Hiring plan review, interview-loop redesign, executive search prep
Compensation & Benefits	Comp philosophy, equity, benefits, pay-equity	Annual cycle, band refresh, equity redesign, pay-equity audit
People Operations & Culture	Culture health, engagement, EX, DEI	Engagement readout, reorg, manager program, culture due diligence
Performance Management	Cycle design, calibration, feedback culture, PIP rigor	Cycle design, calibration session, attrition spike, manager program

Legal & Regulatory

Panel	Domain	When to Use
Contracts & Commercial Law	MSA, DPA, SLA, redline strategy, risk allocation	Material customer contract, template refresh, redline playbook
Regulatory Compliance	Compliance program, exam readiness, horizon scanning	New regime, pre-exam readiness, post-exam remediation, regulator engagement

Strategic Events

Panel	Domain	When to Use
Mergers & Acquisitions	Deal thesis, diligence, structuring, integration	Pre-LOI fit, diligence design, structure review, integration plan
Fundraising & Investor Relations	Round strategy, narrative, term sheet, IR	Round design, pitch refresh, term-sheet review, IR program
Supply Chain & Logistics	Network, supplier risk, logistics, S&OP	Network redesign, supplier audit, logistics RFP, disruption response
Crisis Communications	Crisis comms strategy, sequencing, recovery	Active crisis, pre-disclosure planning, recovery program, drill audit

Gate & Meta Panels

Panel	Domain	When to Use
Feasibility Research	Viability, approach research	Final gate on all panel recommendations
Meta-Improvement	Persona/workflow evolution	Optional post-cycle quality review (not every cycle)

Workflows

Workflow	Description
Generic Panel Review	Single panel, full 10-step cycle: CONVENE → BRIEF → SOLO → CHALLENGE → COUNCIL¹ → CONCESSION² → CONVERGE → FEASIBILITY → DELIVER → PERSIST. ¹depth ≥ 3 only. ²depth = 5 only.
Cascading Multi-Panel	Sequential multi-panel with unified feasibility
Repo Ingestion Review	Content + Architecture + Security → Unified Feasibility
Repo Research	Topic narrative → Discovery → Evaluation → Panel Review → Presentation
Reverse Engineering Analysis	Intake → static recon → semantic review → dynamic validation → learning capture
Reverse Engineering Repo Research	RE repo discovery → portfolio review → extraction strategy → EVOKORE operating model
Reverse Engineering Improvement Loop	Session evidence → workflow review → persona refinement → improvement backlog
Meta-Improvement Cycle	Optional persona/workflow evolution

Persistent Expert Narratives

Expert personas evolve across sessions. See persistent-narratives.md for the cross-session persistence system.

• Roster snapshots persist at ~/.evokore/panel-narratives/roster-snapshot.json
• Evolution log tracks all persona changes in append-only JSONL
• Panel history records every invocation for effectiveness tracking
• Pending improvements queue meta-improvement recommendations for user approval

Authoring or editing a persona? Read PERSONA_AUTHORING_GUIDE.md first. It defines the rigid-skeleton / loose-flesh contract, lists the forbidden fields (default_findings, standard_questions, example_review, etc.), and walks through the most common authoring anti-patterns. The "Two Sessions, One Artifact" test is the smell-check before merging.

Invoking a Panel

Via orch-panel Command

orch-panel code src/SessionIsolation.ts          # Single panel
orch-panel re samples\mystery.dll               # Reverse-engineering review
orch-panel --cascade arch,code,security plan.md  # Multi-panel
orch-panel security --quick src/auth/*.ts        # Quick review
orch-panel presentation --mode extraction plan.md # Package for stakeholders
orch-panel wiring scripts/dashboard.js           # UI/wiring review

Via orch-research Command

orch-research "TypeScript MCP server implementations"  # Topic research
orch-research "recently updated reverse engineering repos for decompilation, debugging, and malware triage" --context "EVOKORE-MCP reverse-engineering skill buildout" --meta-improve
orch-research "CRDT frameworks" --context "EVOKORE-MCP v3.1" --meta-improve

Direct Invocation (Natural Language)

Invoke the Code Refinement panel to review [artifact].
Use the Panel of Experts framework — full 10-step cycle through
CONVENE → BRIEF → SOLO → CHALLENGE → COUNCIL → CONCESSION → CONVERGE
→ FEASIBILITY → DELIVER → PERSIST.
(COUNCIL runs at depth ≥ 3; CONCESSION runs at depth = 5.)

Post-Analysis Presentation Extraction

Run the Presentation Panel on docs/ECC-INTEGRATION-PLAN.md.
Audience: engineering team leads. Time: 15 minutes.
Extract key findings into a stakeholder-ready format.

With Optional Meta-Improvement

Run a Code Refinement Panel on [artifact].
After the panel cycle completes, run the meta-improvement cycle
to evaluate expert effectiveness and suggest persona updates.

Integration with EVOKORE Workflows

Orchestration Commands

• orch-panel — Primary entry point for panel reviews
• orch-research — Topic-based repo research with panel evaluation
• orch-review — Can invoke orch-panel code as part of standard code review
• orch-plan — Can invoke orch-panel arch as part of planning workflow
• orch-tdd — Can invoke orch-panel test for test strategy review
• orch-docs — Can invoke orch-panel docs for documentation accuracy review

Hooks & Session Integration

• resolve_workflow finds this via aliases: expert-panel, panel-review, panel
• evidence-capture hook automatically logs panel findings as session evidence
• session-replay records full panel invocations for reproducibility
• persistent-narratives tracks expert evolution across sessions
• Panel findings feed into the instinct evolution system as high-confidence training signal

Injection Points in Existing Workflows

Full injection point audit covering ~194 skills. 170 are panel-enrichable, 7 are mandatory, the rest optional.

Mandatory Injection Points (Always Run)

Skill/Workflow	Panel(s)	Stage	Why Mandatory
release-readiness	Security → Testing → Performance (cascade)	Post risk-review	Release gate — no production deploy without multi-panel GO/NO-GO
repo-ingestor	Repo Ingestion	Post agent-swarm	Agent swarms produce unchecked claims; panel validates accuracy
docs-architect	Documentation	Post generation	Prevents "context rot" — aspirational docs shipping as fact
orch-review (risk-triggered)	Code + Security	During review	Risk-flagged changes need multi-perspective expert analysis
orch-plan (3+ phases)	Architecture	Pre approval	Complex plans need sequencing/feasibility validation before commit
tool-governance (allowlist)	Security	Pre change	New tool approvals must be red-teamed before allowlisting
orch-refactor (extract/rename)	Code Refinement	Post refactor	Validates coupling/naming didn't regress
design-an-interface	Design-an-Interface	Pre interface commit	When improve-codebase-architecture surfaces a deepening candidate with 3+ viable interface shapes, run design-an-interface panel to produce parallel constraint-differentiated designs and persist a comparative at docs/interface-designs/<slug>-comparative.md.

High-Value Optional Injection Points

Skill/Workflow	Panel(s)	Stage	Value
orch-review (standard)	Code Refinement	During review	6-expert analysis replaces generic checklist
orch-tdd	Testing (pre-RED), Code (post-REFACTOR)	Pre/Post	Validates test design and implementation quality
orch-docs	Documentation	Post sync	Cross-references all claims against codebase
orch-e2e	Testing + Wiring	Pre generate	Scenario coverage + a11y for frontend E2E
orch-build-fix (3+ files)	Code Refinement	Post fix	Validates fix doesn't introduce new failure modes
orch-handoff	Presentation, Documentation	Post generation	Catches stale placeholders; packages for stakeholders
deep-research	Repo Ingestion / Documentation	Post synthesis	Cross-references claims against source material
content-generation	Documentation	Post review	Replaces generic quality score with structured findings
incident-triage (SEV1/2)	Performance	Post classify	SRE expertise for severity validation and capacity impact
planning-with-files	Architecture	Post plan generation	Sequencing, scope creep, risk register
mcp-builder	DX + Architecture	Post design, Post build	API surface design + auth tool security
skill-creator	DX + Documentation	Post creation	Validates resolve_workflow discoverability + doc accuracy

Workflow Template Injection Points

Template	Panel(s)	Injection Point	Type
release-readiness.json	Security → Testing → Perf (cascade)	After review-risk step	Mandatory
content-generation.json	Documentation	Replace review step	Optional
deep-research.json	Repo Ingestion / Documentation	After synthesize step	Optional
incident-triage.json	Performance	After classify-severity	Optional (M for SEV1/2)
example-pipeline.json	Code + Security	Parallel with lint-check	Optional
monitor-alert.json	Performance (quick)	After generate-alert	Optional

WSHOBSON Plugin Pattern Mappings

~120 reference/pattern skills map to panels when the pattern is applied to real code:

Plugin Category	Panel(s)	Key Expert
security-scanning/*	Security Audit	Natasha Volkov (STRIDE)
backend-development/*	Architecture + Code	Priya Sharma (coupling)
cloud-infrastructure/*	Arch + Security + Perf	Triple cascade
payment-processing/*	Security (mandatory)	Omar Hassan (PCI tokens)
kubernetes-operations/*	Security + Architecture	Lisa Park (trust boundaries)
frontend-mobile-development/*	Code + DX	Alex Rivera (a11y/perf)
observability-monitoring/*	Observability & Monitoring	Fatima Al-Zahra (architecture) + Derek Washington (SLO)
llm-application-dev/*	Arch + Perf + Testing	Triple cascade
python-development/*	Code + Perf + Testing	Domain-matched experts
documentation-generation/*	Documentation	Direct panel match
data-engineering/*	Data Engineering & ML	Priya Lakshman (architecture) + Adaeze Okonkwo (quality)
hr-legal-compliance/*	Security	Thomas Eriksen (compliance)
database-design/*	Database Design & Migration	David Park (modeling) + Sonia Alvarez (performance)
machine-learning-ops/*	Data Engineering & ML	Carlos Mendez (ML lifecycle) + mandatory
cicd-automation/*	DevOps & Deployment	Stefan Mueller (pipeline) + Nina Volkov (release)
incident-response/*	Incident & Post-Mortem	Viktor Sorokin (RCA) + Patricia Gomez (process)
startup-business-analyst/*	Business & Product Strategy	Victoria Langston + Amanda Frost

Skills That Don't Need Panels

24 skills are too mechanical, lightweight, or preference-driven for panel overhead: orch-status, orch-tasks, hive (router), hive-concepts, enhance-prompt, remotion, stitch-loop, brand-guidelines, theme-factory, file-organizer, image-enhancer, invoice-organizer, slack-gif-creator, competitive-ads-extractor, twitter-algorithm-optimizer, refly, and the panel-of-experts skills themselves.

Adapted From Upstream

The design-an-interface archetype (panel file: panels/design-an-interface.md) is adapted from mattpocock/skills @ 90ea8eec03d4ae8f43427aaf6fe4722653561a42 / design-an-interface/SKILL.md, MIT licence (c) 2026 Matt Pocock. EVOKORE adaptations:

• Collapsed from sibling skill into panel archetype, so output flows through the panel-of-experts CONVENE -> SOLO -> CHALLENGE -> CONVERGE -> FEASIBILITY -> DELIVER cycle.
• Requirements-gathering replaced with prior-PRD/ADR read (docs/prd/<slug>.md and docs/adr/<slug>*.md) before falling back to ad-hoc operator elicitation.
• Convergence artifact required at docs/interface-designs/<slug>-comparative.md — no ephemeral output.

Upstream attribution and licence text live in the repo-root NOTICE and at SKILLS/upstream/mattpocock-skills/LICENSE. The vendored upstream tree is read-only and not indexed by SkillManager.

Anti-Patterns

• Don't use panels for trivial decisions — a single expert opinion suffices for simple changes
• Don't skip the Challenge phase for critical reviews — it's where the best insights emerge
• Don't let panels become a rubber stamp — if every review ends with "looks good," the personas aren't critical enough
• Don't ignore dissent — minority opinions from qualified experts are often prophetic
• Don't skip Feasibility — brilliant recommendations that can't be implemented are noise
• Don't run meta-improvement every cycle — it's overhead that only pays off when something felt off
• Don't present raw panel output to stakeholders — always run through Presentation panel first