---
name: expert-panel-review
description: Multi-expert panel review that analyzes a plan or code from 3 specialized perspectives (Domain Expert, Architecture Expert, Risk/Compliance Expert). Produces a synthesized panel verdict with confidence level. Use when reviewing plans, assessments, or code changes that need high-confidence validation — especially for GKV/SV domain changes.
---

# Skill: expert-panel-review

Multi-expert panel review of plans or code from 3 specialist perspectives simultaneously.

## Invoked by

📋✅ Plan Reviewer mode (mandatory before verdict)
🔍 Reviewer mode (optional, for complex changes)

## Required Inputs

| Input | Source | Example |
|-------|--------|---------|
| `TICKET_KEY` | Jira issue key | `ESIDEPAISY-13009` |
| `MODULE` | PAISY module name | `eau`, `eubp`, `svmeldungen` |
| `ARTIFACT_TYPE` | What's being reviewed | `plan`, `code`, `assessment` |
| `ARTIFACT_PATH` | Path to the document or diff | `docs/EAU/ESIDEPAISY-13009/ESIDEPAISY-13009-plan.md` |

## Output

Markdown section appended to the review document, or standalone file:
`docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-panel-review.md`

## Expert Panel Composition

### For Plan/Assessment Review

| # | Expert | Emoji | Lens | Focus Areas |
|---|--------|-------|------|-------------|
| 1 | Domain Expert | 🏛️ | GKV/SV regulation & business correctness | Are domain assumptions correct? Is the spec interpretation right? Do date boundaries, Kennzeichen values, and Verfahrensmerkmale match the official GKV documentation? |
| 2 | Architecture Expert | 🔧 | PAISY patterns & technical design | Is the plan technically sound? Correct patterns used (AbstractMeldung, Datenbaustein, ServiceCenter, EMFactory, JAXB)? Missing components? Correct module boundaries? |
| 3 | Risk & Compliance Expert | 🛡️ | Edge cases, backward compatibility, data integrity | What could go wrong? Missing error paths? Backward compatibility issues? Data migration risks? What happens to in-flight transactions? |

### For Code Review

| # | Expert | Emoji | Lens | Focus Areas |
|---|--------|-------|------|-------------|
| 1 | Domain Expert | 🏛️ | Business logic correctness | Does the code implement domain rules correctly? Are Datenbaustein field mappings correct? Do date calculations follow SV rules? |
| 2 | Performance & Data Expert | ⚡ | DB queries, batch patterns, memory | N+1 queries? Missing EM flush/clear in loops? Unbounded collections? Correct transaction boundaries? Index usage? |
| 3 | Integration Expert | 🔗 | API contracts, backward compat, versioning | Will this break existing callers? Is the JAXB contract preserved? Are Flyway migrations safe for rollback? ServiceCenter protocol correct? |

## Steps

### 1. Load the artifact

For plans/assessments:
```bash
cat docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-<ARTIFACT_TYPE>.md
```

For code:
```bash
cd /Users/pplate/git/paisy-<TICKET_KEY>
git diff origin/current --stat
git diff origin/current
```

### 2. Load domain context

Search BigMind and Wiki for domain-specific context:
```python
memory_search_facts("<MODULE> <domain keywords>")
# For GKV topics, also check ADP Docs Wiki
set-wiki(uri="mcp://wikis/adpdocs.de.adp.com")
search-page(query="<relevant domain topic>")
```

### 3. Run Expert Panel (3 parallel perspectives)

For each expert, perform a **complete independent review** of the artifact. Each expert MUST:
- State their assumptions explicitly
- Challenge claims in the document with evidence
- Provide a confidence score (0-100%) for their domain
- List specific concerns with file/section references
- Give a per-expert verdict: ✅ APPROVE / ⚠️ CONCERN / ❌ REJECT

#### Expert 1: 🏛️ Domain Expert Review

**System prompt context:**
```
You are a German social insurance (Sozialversicherung) domain expert specializing in GKV electronic data exchange procedures. You have deep knowledge of:
- GKV Datenaustausch specifications (DSRV, ITSG standards)
- SV-Meldeverfahren procedures (DEÜV, EEL, EAU, EuBP, DaBPV, DSAK, DSBD, DSVV)
- Date boundary rules (Gültigkeitszeiträume, Abrechnungszeiträume)
- Kennzeichen values and their semantics
- Vorlaufsatz/Nachlaufsatz structure
- XML schema versioning (v2025, v2027 namespaces)

Review this artifact for DOMAIN CORRECTNESS ONLY. Do not review code quality or architecture.
Focus: Are the domain assumptions correct? Does this match the official GKV specifications?
```

#### Expert 2: 🔧 Architecture Expert Review (for plans) / ⚡ Performance Expert (for code)

**For plans — system prompt context:**
```
You are a senior Java architect specializing in the PAISY monorepo patterns:
- AbstractMeldung inheritance hierarchy
- Datenbaustein field-based data exchange
- ServiceCenter singleton + pgm protocol
- EMFactory per-module pattern
- JAXB binding with Jakarta namespace
- Flyway dual-database migrations (H2 + Oracle)
- Spring Shell command dispatch
- NATS JetStream message broker integration

Review this plan for ARCHITECTURAL SOUNDNESS ONLY. Do not review domain correctness.
Focus: Are the correct patterns used? Is the component decomposition right? Are there missing pieces?
```

**For code — system prompt context:**
```
You are a performance and data access expert for Java/JPA applications:
- JPA EntityManager lifecycle and persistence context management
- Batch processing patterns (flush/clear every N items)
- Query optimization (N+1 detection, eager vs lazy loading)
- Transaction boundary correctness
- Connection pool management
- Memory-efficient collection processing
- H2 vs Oracle behavioral differences

Review this code for PERFORMANCE AND DATA INTEGRITY ONLY. Do not review domain correctness.
Focus: Will this scale? Are there hidden performance traps? Is data consistency guaranteed?
```

#### Expert 3: 🛡️ Risk Expert Review (for plans) / 🔗 Integration Expert (for code)

**For plans — system prompt context:**
```
You are a risk and compliance analyst specializing in payroll system changes:
- Backward compatibility requirements (Bestandskunden must not break)
- Data migration risks (what happens to existing records?)
- In-flight transaction handling during deployments
- Wartungswechsel (maintenance version rotation) implications
- Rollback scenarios (can this be undone safely?)
- Edge cases: empty datasets, date sentinels (00.00.0000, 9999999), null BBNRs
- Multi-tenant Oracle implications
- Timing risks: what if this runs mid-Abrechnungslauf?

Review this plan for RISKS AND GAPS ONLY. Do not review architecture or domain.
Focus: What could go wrong? What's not addressed? What edge cases are missing?
```

**For code — system prompt context:**
```
You are an integration and contract expert for the PAISY module ecosystem:
- API stability between modules (breaking changes detection)
- JAXB XML contract preservation (namespace, element order, required fields)
- Flyway migration safety (can it be applied to existing production data?)
- ServiceCenter protocol compatibility (F; response handling)
- Backward compatibility with existing callers
- Dual-database correctness (H2 behavior vs Oracle behavior)
- Version-aware code paths (V2/V3 coexistence)

Review this code for INTEGRATION SAFETY ONLY. Do not review performance or domain.
Focus: Will this break anything that already works? Are contracts preserved?
```

### 4. Synthesize Panel Verdict

After all 3 experts complete their reviews, synthesize:

```markdown
## 👥 Expert Panel Verdict

### Panel Composition
| Expert | Verdict | Confidence | Key Concern |
|--------|---------|-----------|-------------|
| 🏛️ Domain Expert | ✅/⚠️/❌ | <N>% | <one-line summary> |
| 🔧/⚡ Architecture/Performance Expert | ✅/⚠️/❌ | <N>% | <one-line summary> |
| 🛡️/🔗 Risk/Integration Expert | ✅/⚠️/❌ | <N>% | <one-line summary> |

### Consensus
**Overall Panel Verdict:** ✅ UNANIMOUS APPROVE / ⚠️ CONDITIONAL APPROVE / ❌ REVISE REQUIRED

**Confidence Level:** <average of 3 experts>%

### Dissenting Opinions
<If any expert disagrees with the others, document the disagreement explicitly>

### Consolidated Findings

#### Must Address (blocking)
1. [Expert emoji] <finding> — <rationale>

#### Should Address (non-blocking)
1. [Expert emoji] <finding> — <suggestion>

#### Noted (informational)
1. [Expert emoji] <observation>
```

### 5. Apply Panel Rules

| Scenario | Action |
|----------|--------|
| All 3 experts ✅ APPROVE | → Panel APPROVE, proceed to final verdict |
| 2 experts ✅, 1 expert ⚠️ CONCERN | → Panel CONDITIONAL APPROVE, document concern |
| Any expert ❌ REJECT | → Panel REVISE REQUIRED, must address before approval |
| 2+ experts ⚠️ CONCERN | → Panel REVISE REQUIRED, cumulative risk too high |
| Average confidence < 70% | → Flag for human review regardless of verdicts |

### 6. Store findings

```python
memory_store_fact(
    category="codebase",
    fact=f"{TICKET_KEY}: Expert panel review — {verdict}. Domain: {d_verdict} ({d_conf}%), Arch: {a_verdict} ({a_conf}%), Risk: {r_verdict} ({r_conf}%)"
)
```

## Expected Output

- 3 independent expert reviews with specific findings
- Synthesized panel verdict with confidence levels
- Clear blocking/non-blocking categorization
- Dissenting opinions explicitly documented (not suppressed)

## Error Handling

| Error | Resolution |
|-------|------------|
| No domain context found | Fetch from ADP Docs Wiki before domain expert runs |
| Expert contradicts another | Document as dissenting opinion — don't average away disagreement |
| Low confidence from an expert | Flag for human review — don't proceed with uncertain approval |
| Plan too vague for experts | REVISE — experts need concrete details to review |

## Key Principle

**Never suppress dissent.** If the Risk Expert sees a problem that Architecture Expert dismisses, BOTH perspectives are documented. Patrick makes the final call on risk acceptance. The panel provides information, not consensus-for-consensus-sake.

## Language

- Expert reviews: **German** (PAISY domain convention)
- Technical terms (class names, patterns): English as-is
- Panel synthesis: German