feat: archive zoo_backup for home sync
This commit is contained in:
Patrick Plate
@@ -0,0 +1,200 @@
|
||||
---
|
||||
name: generate-assessment
|
||||
description: 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
|
||||
|
||||
```python
|
||||
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
|
||||
|
||||
```python
|
||||
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
|
||||
|
||||
```python
|
||||
# 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
|
||||
|
||||
```python
|
||||
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:
|
||||
|
||||
```markdown
|
||||
# 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
|
||||
|
||||
```python
|
||||
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>/`)
|
||||
Reference in New Issue
Block a user