pi_mcps/zoo_backup/work/skills/generate-assessment/SKILL.md

name, description

name	description
generate-assessment	Structured assessment document from Jira ticket and code analysis.

IMPORTANT: Never list Roo as author or co-author. The Author field must always be "Patrick Plate" only.

Skill: generate-assessment

Structured assessment document from Jira ticket and code analysis.

Invoked by

📋 Planner 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>-assessment.md

Pre-Flight Checklist (mandatory before assessment generation)

Before writing the assessment, the Planner MUST verify each item below. Results are incorporated into the assessment document (particularly sections 4, 5, and 6). Items marked N/A must be explicitly noted as not applicable with a brief reason.

Legal Framework

• Identify ALL applicable laws (BGB, AO, KCanG, EStG, DSGVO, HGB, GoBD, industry-specific)
• Cite specific paragraphs (§XX Abs. Y) — not just law names
• Define retention periods per data type (map to §147 AO / §24 KCanG / Art. 17 DSGVO)

GDPR Impact

• Identify legal basis for processing (Art. 6(1)(a)-(f) DSGVO)
• Determine if consent is needed (push notifications, marketing, analytics)
• Define data minimization approach (only collect what's needed)
• Document retention/deletion timeline

Security & Architecture

• Auth/permission model defined (which StaffPermission, which role sees what)
• Audit trail planned (which operations logged, immutability requirements)
• Append-only vs. mutable data decision documented
• Mobile-readiness considered (will API work for future native app?)

Quality Traceability

• Every requirement maps to an implementation step
• Every implementation step maps to a test case
• Traceability matrix included in testplan

Business & UX

• Tier mapping defined (Starter/Pro/Enterprise limits)
• Competitive gap validated (what others don't do)
• UX decisions explicit (not "TBD" — pick a concrete approach)
• Export formats defined (PDF for whom, CSV for whom, JSON for whom)

Prior Learnings

• Check BigMind for prior review findings (carry forward unresolved items)
• Apply patterns from previous sprints (coding patterns, entity patterns, service patterns)
• Search for related existing features that integrate (notifications, audit, calendar)

---

Steps

1. Gather context from BigMind

memory_search_facts("<MODULE> <relevant keywords>")
memory_search_chunks("<MODULE> <relevant keywords>")
memory_search_semantic("<natural language description of the problem>")

2. Read Jira ticket

retrieve_ticket_details(TICKET_KEY)
# Extract: summary, description, acceptance criteria (customfield_10510)
# Note the Feature Link (customfield_10001) for traceability

3. Search ADP Wiki for domain context

# Check BigMind index first
memory_search_facts("<domain topic> adpdocs")

# If page ID known, fetch directly
set-wiki(uri="mcp://wikis/adpdocs.de.adp.com")
get-page(title="<relevant page>")

# If not known, search
search-page(query="<domain keywords>")

4. Search Confluence for prior decisions

search_confluence_by_cql("text ~ '<TICKET_KEY>' OR text ~ '<topic keywords>'")

5. Analyze affected source code

• Identify the module entry point: java/modules/cs-modules/<MODULE>/
• Read key classes mentioned in the ticket
• Trace the data flow through the affected components
• Note patterns used: AbstractMeldung, Datenbaustein, ServiceCenter, EMFactory, JAXB, etc.

6. Generate assessment document

Write docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-assessment.md with this structure:

# Assessment: <TICKET_KEY> — <Summary>

**Datum:** <today>
**Modul:** <MODULE>
**Autor:** Patrick Plate
**Status:** Entwurf v1

---

## 1. Problemanalyse

<What is the problem? Why does it need to be solved? Reference Jira ticket.>

## 2. Betroffene Komponenten

| Komponente | Pfad | Rolle |
|-----------|------|-------|
| <Class> | <path> | <what it does> |

## 3. Ist-Zustand

<How does the current code work? Data flow, key methods, patterns used.>

## 4. Risikobewertung

| Risiko | Wahrscheinlichkeit | Auswirkung | Mitigation |
|--------|-------------------|------------|------------|
| <risk> | Hoch/Mittel/Niedrig | <impact> | <mitigation> |

## 5. Lösungsoptionen

### Option A: <name>
- **Beschreibung:** ...
- **Vorteile:** ...
- **Nachteile:** ...
- **Aufwand:** ...

### Option B: <name>
- **Beschreibung:** ...
- **Vorteile:** ...
- **Nachteile:** ...
- **Aufwand:** ...

## 6. Empfehlung

<Which option and why. Reference PAISY patterns, domain constraints, prior art.>

## 7. Offene Fragen

- [ ] <question 1>
- [ ] <question 2>

7. Present to user

• Show the assessment summary
• Explicitly ask: "Assessment v1 erstellt. GO / Feedback?"
• On feedback: revise and increment version (v2, v3, ...)

8. Store findings in BigMind

memory_store_fact(
    category="codebase",
    fact=f"{TICKET_KEY}: Assessment completed. <key finding summary>"
)
memory_append_chunk(
    session_id=SESSION_ID,
    content=f"Assessment for {TICKET_KEY}: <detailed findings>",
    flag_reason="assessment findings"
)

Language

• Document content: German (PAISY domain convention)
• Technical terms (class names, patterns, tools): keep as-is in English
• Section headers: German

Conventions

• Date format: dd.MM.yyyy (German)
• Version tracking: v1, v2, v3 in the Status field
• File location: always under docs/<MODULE>/<TICKET_KEY>/
• Reference existing plan docs if they exist (check ls docs/<MODULE>/<TICKET_KEY>/)