pi_mcps/zoo_backup/work/skills/code-review/SKILL.md

name, description

name	description
code-review	Structured code review against implementation plan.

Skill: code-review

Structured code review against implementation plan, with mandatory SonarQube static analysis.

Invoked by

🔍 Reviewer mode

Required Inputs

Input	Source	Example
TICKET_KEY	Jira issue key	ESIDEPAISY-12081
MODULE	PAISY module name	eau, eubp, svmeldungen

Output

Markdown file: docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-review.md

Steps

1. Read the plan document

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

Extract: planned changes, affected files, expected patterns, acceptance criteria.

2. Read the test plan (if exists)

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

Cross-reference: are all planned test cases implemented?

3. Get the diff

cd /Users/pplate/git/paisy-<TICKET_KEY>
git diff origin/current --name-only
git diff origin/current --stat
git diff origin/current

4. Read changed files

For each changed file, read the full file to understand context — not just the diff hunks.

cd /Users/pplate/git/paisy-<TICKET_KEY>
git diff origin/current --name-only | while read f; do echo "=== $f ==="; done

5. Run SonarQube static analysis (MANDATORY)

For every changed Java file, run the SonarQube SAST analyzer:

# Get list of changed Java source files (exclude tests for MAIN scope)
changed_java = [f for f in changed_files if f.endswith(".java") and "/test/" not in f]
changed_tests = [f for f in changed_files if f.endswith(".java") and "/test/" in f]

# Analyze each source file
for java_file in changed_java:
    file_content = read_file(java_file)
    analyze_code_snippet(
        fileContent=file_content,
        language=["java"],
        scope=["MAIN"]
    )

# Analyze test files separately
for test_file in changed_tests:
    file_content = read_file(test_file)
    analyze_code_snippet(
        fileContent=file_content,
        language=["java"],
        scope=["TEST"]
    )

Additionally, check for PR-level Sonar analysis if a PR exists:

# Check if a Sonar PR analysis exists for this branch
# Project key is always "com.adp.de:paisy"
list_pull_requests()  # Get PR ID for this branch
search_sonar_issues_in_projects(
    projects=["com.adp.de:paisy"],
    pullRequestId="<PR_ID>",
    issueStatuses=["OPEN"]
)

SonarQube findings are categorized:

Severity	Impact on Review
BLOCKER	❌ Blocks approval
HIGH	❌ Blocks approval
MEDIUM	⚠️ Warning, should fix
LOW/INFO	ℹ️ Informational

6. Run the review checklist

For each changed file, verify:

#	Check	What to look for
1	Plan compliance	All plan items implemented? Nothing missing, nothing extra?
2	Pattern correctness	Correct PAISY patterns used? (AbstractMeldung, Datenbaustein, ServiceCenter, EMFactory, JAXB)
3	No src.gen/ changes	Generated sources must never be modified manually
4	Logging	@Slf4j or @Log4j2 with parameterized messages (log.debug("x: {}", v)) — no string concatenation
5	German domain terms	Domain terms preserved: Fehlzeiten, Lohnkonto, Vorlaufsatz, Nachlaufsatz
6	Error handling	PAISY F; responses checked before parsing? Null-safe patterns?
7	Date handling	Correct formatters? Empty date checks (00.00.0000, 0000000, 9999999)?
8	Test coverage	Every new/modified public method has a test? Edge cases covered?
9	Flyway migrations	Correct naming convention? Dual H2/Oracle? Type mapping correct?
10	No hardcoded values	No hardcoded BBNR, sprint IDs, Epic keys, instance names?
11	Field visibility	protected for shared fields, private with Lombok for DTOs?
12	Annotations	Correct use of @Service/@Lazy, @Transactional, @XmlElement?
13	SonarQube clean	No new BLOCKER/HIGH issues? MEDIUM issues documented?

7. Check test quality

cd /Users/pplate/git/paisy-<TICKET_KEY>
# Find new/modified test files
git diff origin/current --name-only | grep -E "Test\.java$"

For each test file:

• Meaningful assertions (not just assertNotNull)?
• Edge cases covered?
• Mocking done correctly (Mockito patterns)?
• Test naming convention: test<What>_<Scenario>_<Expected>()?

8. Run tests

cd /Users/pplate/git/paisy-<TICKET_KEY>
mvn test -pl java/modules/cs-modules/<MODULE> -f java/pom.xml

9. Expert Panel (for complex changes — optional)

For changes that span multiple modules, touch shared infrastructure, or involve GKV domain logic, invoke the expert-panel-review skill:

Trigger conditions (invoke if ANY apply):
- Changed files span 3+ packages
- Changes touch AbstractMeldung or shared base classes
- New/modified Datenbaustein field mappings
- JAXB schema changes (new XSD bindings)
- Flyway migrations that alter existing tables (not just add)
- ServiceCenter protocol changes

When triggered, invoke with ARTIFACT_TYPE=code.

10. Generate review document

Write docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-review.md:

# Code Review: <TICKET_KEY> — <Summary>

**Datum:** <today>
**Modul:** <MODULE>
**Reviewer:** Roo (Reviewer)
**Branch:** <branch name>
**Status:** ✅ Approved / ⚠️ Approved with comments / ❌ Changes requested

---

## Zusammenfassung

<1-2 sentence summary of the review outcome>

## SonarQube-Analyse

| Schweregrad | Anzahl | Status |
|-------------|--------|--------|
| Blocker | <N> | ✅ 0 / ❌ N Befunde |
| High | <N> | ✅ 0 / ❌ N Befunde |
| Medium | <N> | ⚠️ N Befunde |
| Low/Info | <N> | ℹ️ |

<If PR-level Sonar analysis available:>
**Sonar Quality Gate:** ✅ Passed / ❌ Failed

## Geprüfte Dateien

| Datei | Änderung | Bewertung |
|-------|---------|-----------|
| `<path>` | Neu/Geändert | ✅ / ⚠️ / ❌ |

## Checkliste

| # | Prüfpunkt | Ergebnis | Anmerkung |
|---|-----------|----------|-----------|
| 1 | Plan-Konformität | ✅ | Alle geplanten Änderungen umgesetzt |
| 2 | Pattern-Korrektheit | ✅ | AbstractMeldung korrekt erweitert |
| 3 | Keine src.gen/ Änderungen | ✅ | — |
| 4 | Logging | ⚠️ | Zeile 42: String-Konkatenation → parameterized |
| 5 | Deutsche Domänenbegriffe | ✅ | — |
| 6 | Fehlerbehandlung | ✅ | F;-Prüfung vorhanden |
| 7 | Datumsbehandlung | ✅ | — |
| 8 | Testabdeckung | ✅ | 7 Tests, alle bestanden |
| 9 | Flyway-Migrationen | ✅ | H2 + Oracle korrekt |
| 10 | Keine Hardcoded-Werte | ✅ | — |
| 11 | Feld-Sichtbarkeit | ✅ | — |
| 12 | Annotationen | ✅ | — |
| 13 | SonarQube sauber | ✅ | Keine neuen Blocker/High Issues |

## Befunde

### ❌ Blocker (must fix)

1. **<file>:<line>** — <description of critical finding>
   - Begründung: <why this must be fixed>

### ⚠️ Hinweise (non-blocking)

1. **<file>:<line>** — <description of finding>
   - Empfehlung: <suggested fix>

### ℹ️ SonarQube-Befunde

<List any SonarQube findings with rule keys and descriptions>

## Expert Panel (falls durchgeführt)

<Include panel verdict if expert-panel-review was invoked>

## Tests

- **Ausgeführt:** <N> Tests
- **Bestanden:** <N> ✅
- **Fehlgeschlagen:** <N> ❌
- **Build:** ✅ Grün / ❌ Rot

## Empfehlung

<Final recommendation: merge / fix and re-review / reject>

11. Store in BigMind

memory_store_fact(
    category="codebase",
    fact=f"{TICKET_KEY}: Code review completed — {status}. {findings_count} findings ({blockers} blockers). SonarQube: {sonar_issues} issues ({sonar_blockers} blocking)."
)

Expected Output

• Review document at docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-review.md
• SonarQube analysis results integrated
• All tests executed and results documented
• Expert panel verdict (if triggered)
• Clear recommendation: merge / fix / reject

Error Handling

Error	Resolution
No plan document found	Review without plan — note in review that plan was missing
Build fails	Document build failure as blocker, don't proceed with detailed review
No tests found	Flag as blocker — every change needs tests
Worktree not found	Check if /Users/pplate/git/paisy-<TICKET_KEY> exists, or use main repo with branch checkout
SonarQube MCP unavailable	Note in review as "⏭️ SonarQube nicht verfügbar", proceed with manual checklist only
Sonar project key wrong	Always use com.adp.de:paisy for the PAISY monorepo

Severity Levels

Level	Symbol	Meaning	Action
Blocker	❌	Must fix before merge	Changes requested
Warning	⚠️	Should fix, not blocking	Approved with comments
Info	ℹ️	Suggestion for improvement	Approved
OK	✅	No issues	—

Language

• Review document: German
• Code references (class names, methods, patterns): English as-is
• Checklist items: German