bollwerk/.github/prompts/genome-distill.prompt.md

description	model	tools
Genome Engine Phase 2: Destilliert raw-improvements.md – klassifiziert, scored und bereinigt Improvements für Cross-Repo-Transfer.	Claude Opus 4.6 (copilot)	read edit

Genome Distillation

Du erhältst eine Datei mit rohen Git-Improvements aus KI-Tooling-Dateien. Deine Aufgabe: klassifizieren, scoren, bereinigen – damit nur übertragbare Verbesserungen übrig bleiben.

Input

Lies die Datei .github/genome/output/raw-improvements.md.

Aufgabe

Für jede Capability und jedes Improvement darin:

1. Klassifizierung

Klasse	Bedeutung	Beispiele
🔴 Critical	Bugfixes, die andere Repos auch treffen würden	Fehlende Escapes, falsche Tool-Syntax, Security-Lücke in Prompt
🟡 Evolution	Generelle Verbesserungen, übertragbar	Bessere Formulierung, neues Pattern, strukturelle Optimierung
⚪ Specialized	Projektspezifisch, NICHT übertragbar	Deployment auf einen konkreten Server (IP/Domain), projektspezifische DB-Seeding-Daten, App-spezifische Package-Namen ohne generelles Pattern

2. Scoring (1–10)

Bewerte den Übertragungswert jedes Critical/Evolution-Improvements:

• 9–10: Universell wertvoll, jedes Repo profitiert
• 7–8: Breit anwendbar, gutes Pattern
• 4–6: Situativ nützlich
• 1–3: Grenzwertig, kaum übertragbar

3. Sanitization

Ersetze in den Diffs:

• Benutzernamen → <user>
• Maschinenpfade (z.B. C:\Users\..., /home/...) → <local-path>
• Tokens, API-Keys, Secrets → <redacted>
• Projektspezifische IDs (Issue-Nummern, Project-Board-IDs) → <project-id>
• Repo-spezifische Namen (z.B. bollwerk, krisenvorrat) → <project>
• Server-IPs/Domains (z.B. 195.246.231.210, bollwerk.online) → <server>
• Package-Namen (z.B. de.bollwerk.app) → <package>

Specialized vs. Evolution – Abgrenzung

Specialized = betrifft NUR dieses eine Projekt und ist nach Sanitization NICHT auf ein anderes Repo übertragbar.

Specialized (entfernen):

• Deployment-Skripte die eine konkrete Server-IP/Domain ansprechen (SCP auf den Island-VPS)
• Projekt-Renames (krisenvorrat → bollwerk) ohne inhaltliche Verbesserung
• Seeding-Daten, Issue-Body-Templates für ein konkretes Feature dieses Projekts
• Docker-Compose-Anpassungen für einen konkreten Server

NICHT Specialized (behalten als Evolution):

• Technologie-Handling: Gradle-Build-Patterns, Room-Migration-Checklisten, Emulator-GPU-Workarounds
• Workflow-Patterns: Ticket-Orchestrierung, Sub-Agent-Isolation, Board-Status-Automatisierung
• Tooling-Bugfixes: PowerShell-Binary-Encoding umgehen, ADB-Timeout-Loops, Force-Kill-Fallbacks
• Architektur-Patterns: API-Call statt Container-Restart, Hot-Reload ohne Emulator-Neustart
• Neue Skills/Prompts deren Kernlogik nach Sanitization universell ist

4. Filterung

• Specialized Improvements: komplett entfernen (nicht in Output aufnehmen)
• Reine Formatting-Änderungen (nur Whitespace/Tabellenausrichtung): entfernen
• Renames ohne inhaltliche Änderung: entfernen

⚠️ Häufige Fehler bei der Distillation (vermeiden!)

Fehler 1: member-added pauschal als Specialized verwerfen

Neue Dateien (member-added) sind oft die wertvollsten Improvements. Ein neuer Skill, Prompt oder Agent ist nach Sanitization häufig hochgradig übertragbar. Prüfe:

• Enthält die Datei ein allgemeines Pattern (z.B. Checkliste, Workflow-Struktur, Fehlerklassen-Katalog)?
• Ist sie nach Pfad-/Namen-Sanitization auf andere Projekte anwendbar?
• → Wenn ja: Evolution (Score 7–9), nicht Specialized.

Nur als Specialized werten, wenn der gesamte Inhalt projektspezifisch ist (z.B. nur eine Entity-Definition für eine bestimmte App).

Fehler 2: Nur den ersten Teil der raw-improvements lesen

Die raw-improvements-Datei kann tausende Zeilen lang sein. Skills, Scripts und neue Capabilities stehen oft am Ende. Lies die GESAMTE Datei bevor du klassifizierst – nicht nur die ersten 1000–2000 Zeilen.

Fehler 3: Mehrteilige Commits nicht trennen

Ein einzelner Commit kann enthalten:

• 3× Specialized (Rename krisenvorrat→bollwerk in 3 Dateien)
• 1× Evolution (GPU-Hardening-Pattern mit Timeout-Loop)
• 1× Evolution (Hot-Reload-Action als neues Pattern)

Trenne diese pro Hunk, nicht pro Commit.

Fehler 4: Technische Scripts als Specialized abtun

PowerShell/Python-Scripts die ein universelles DevOps-Problem lösen (z.B. Emulator-Boot-Timing, PowerShell-Binary-Encoding-Bug, APK-Deployment ohne Container-Restart) sind Evolutions, auch wenn sie projektspezifische Pfade enthalten. Nach Sanitization sind sie übertragbar.

Fehler 5: Zu konservativ scoren

Eine Conversion-Rate von < 10% ist ein Warnsignal. Bei typischen aktiven Repos mit 20+ Capabilities sollte die Rate bei 15–30% liegen (bezogen auf Capabilities mit mindestens einer Evolution, nicht auf Improvements-Gesamtzahl).

Regeln zur Diff-Analyse

⚠️ Wichtig: Commits haben oft eine dominante + eine versteckte Änderung.

Gehe für jeden Commit wie folgt vor:

1. Commit-Message ignorieren – sie beschreibt nur die dominante Änderung
2. Jeden geänderten Hunk einzeln bewerten – auch wenn der Commit-Titel z.B. "rename" lautet, können einzelne Hunks inhaltliche Verbesserungen enthalten
3. Rename-Churn erkennen: Commit A ändert Pfad X→Y, Commit B ändert Y→X = beide Specialized. Erst wenn der finale Wert stabil ist, ist es eine Evolution
4. Nicht zu früh aggregieren: Ein Commit mit 10 Datei-Diffs kann 2 Specialized + 1 Evolution enthalten – trenne sie

Häufige versteckte Evolutions-Muster:

• Absolute Pfade (C:\..., x:\...) → relative Pfade (.github/...) → Evolution Score 8
• Board/Order-Zuweisung zu Ticket-Erstellung hinzugefügt → Evolution Score 8
• Script-Aufruf statt vager Beschreibung in Prompt → Evolution Score 7
• Vollständige Label-Liste statt unvollständiger → 🔴 Critical
• Neues Skript das universellen Bug umgeht (z.B. PowerShell-Binary-Encoding, GPU-Inkompatibilität) → Evolution Score 8
• Neuer Skill/Prompt mit transferierbarer Checkliste (z.B. DB-Migration-Steps, Audit-Fehlerklassen) → Evolution Score 8–9
• Workflow-Isolation (Sub-Agent pro Iteration, kein geteilter Kontext) → Evolution Score 7
• API-Call statt Container-Restart für Config-Updates → Evolution Score 7
• Timeout-Loop + Fallback statt einfachem wait-for-device → Evolution Score 7

Output-Format

Schreibe das Ergebnis in .github/genome/output/distilled-insights.md mit folgendem Format:

# Distilled Insights

**Quelle:** <repo-name>
**Zeitraum:** <aus raw-improvements übernehmen>
**Distilliert:** <aktuelles Datum>
**Ergebnis:** X Critical, Y Evolution (Z Specialized entfernt)

---

## 🔴 Critical

### Capability: `<capability-key>`

**Score:** N/10
**Zusammenfassung:** <1-Satz was gefixt wurde>

```diff
<bereinigter Diff>
```

---

🟡 Evolution

Capability: <capability-key>

Score: N/10 Zusammenfassung: <1-Satz was verbessert wurde> Pattern: <abstrahiertes Pattern, das andere übernehmen können>

<bereinigter Diff>

## Regeln

- Fasse mehrere Commits an derselben Capability zu EINEM Improvement zusammen, wenn sie dasselbe verbessern
- Bei Score < 4: nicht aufnehmen (zu wenig Übertragungswert)
- Sortiere innerhalb jeder Klasse absteigend nach Score
- Halte Zusammenfassungen auf 1 Satz
- Das "Pattern"-Feld bei Evolution beschreibt die **generalisierte Verbesserung**, nicht den konkreten Change
- Diffs dürfen gekürzt werden – nur die relevanten Hunks behalten
- Schreibe am Ende einen **Analyse-Bericht** in den Chat (nicht in die Datei): `Capabilities: N | Improvements: M | Critical: A | Evolution: B | Specialized entfernt: C | Churn-Commits übersprungen: D`