pi_mcps/zoo_backup/work/skills/expert-panel-review/SKILL.md

name, description

name	description
expert-panel-review	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:

cat docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-<ARTIFACT_TYPE>.md

For code:

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:

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:

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

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