GerbilManager/.claude/skills/ticket-triage/SKILL.md

name, description

name	description
ticket-triage	Fehlerberichte (Tickets) der Züchterin abarbeiten: neue Tickets per Subagent triagieren, Rückfragen an die Tickets hängen, beantwortete Tickets wieder aufgreifen, Fixes gebündelt umsetzen und beim Schließen dokumentieren, was gefixt wurde. Nutze diesen Skill, wenn der Nutzer „Tickets abarbeiten / triagieren", „Fehlerberichte bearbeiten" o. Ä. verlangt.

Ticket-Triage & Abarbeitung

Tickets entstehen über das „Fehler melden"-Feature (POST /feedback) und werden unter Hilfe → Meine Tickets (/hilfe/tickets) verwaltet. Dieser Skill automatisiert das Triagieren, Rückfragen-Stellen, Umsetzen und Schließen.

Status-Lebenszyklus (Feedback.Status)

Status	Bedeutung	Wer ist dran
Open	Neues Ticket, noch nicht triagiert	KI (triagieren)
NeedsInfo	KI hat eine Rückfrage angehängt	Züchterin (antworten)
Answered	Züchterin hat geantwortet	KI (wieder aufgreifen, umsetzen)
Resolved	Erledigt — mit fixNote (Changelog)	—

Zu bearbeiten sind Open (neu) und Answered (KI wieder dran). NeedsInfo wartet auf die Züchterin, Resolved ist fertig — beide überspringen.

Voraussetzungen

• App läuft (Aspire): dotnet run --project GerbilManager.AppHost; API auf http://localhost:5179. Siehe CLAUDE.md (Architektur, Import→DB-Workflow, Domänenwissen: 6-Jahre-Lebensspanne, Geschwisterverpaarung, Genotyp/E-Locus, isResident).
• Feedback überlebt den Import-Ingest (FK-freie Spalten) — Tickets bleiben erhalten, auch wenn die DB neu befüllt wird.

Ablauf

1. Tickets holen & einteilen

curl -s http://localhost:5179/feedback (neueste zuerst). Encoding-Falle: über eine Datei holen (curl -o raw.json) und mit python … .decode('utf-8') lesen, nicht via Windows-stdin-Pipe (sonst Mojibake). Test-/Dummy-Tickets ausschließen. Filtere auf status in (Open, Answered). Bei Answered zusätzlich das Feld answer (Antwort der Züchterin) mitnehmen — darauf basiert die Umsetzung.

2. Triage per Subagent (ein Agent pro Ticket)

Nutze die Workflow-Orchestrierung (pipeline) — einen Triage-Agenten pro Ticket. args ASCII-sicher halten (nur id/context/gerbilId/litterId übergeben; die deutschen Nachrichten holt der Agent selbst aus GET /feedback). Defensive im Script: const tickets = Array.isArray(args) ? args : JSON.parse(args).

Jeder Triage-Agent:

1. liest CLAUDE.md + docs/ticket-triage.md (falls vorhanden),
2. holt seinen Ticket-Text (+ answer bei Answered) aus GET /feedback,
3. untersucht die echten Daten über die API (GET /gerbils/{id}, /litters/{id}, Eltern verfolgen; provenance zeigt Import-Herkunft inkl. verworfener Werte),
4. liefert strukturiert (StructuredOutput-Schema): ticketId, title, category, rootCause, recommendation, fixLayer (import-data|import-logic|backend|frontend| genetics-engine), affectedAreas[], overlapKey (Cluster-Slug), effort (S/M/L), confidence, needsUserInfo.

Sammle alle Ergebnisse in eine Datei docs/ticket-triage.md (Cluster-/ Überschneidungs-Matrix + offene Rückfragen) — token-schonend per Python aus dem Workflow-Ergebnis generieren, nicht 70 KB in den Kontext laden.

3. Rückfragen an die Tickets hängen

Für jedes Ticket mit needsUserInfo: PUT /feedback/{id} mit {"question": "<konkrete Rückfrage, deutsch>"} → Status wird automatisch NeedsInfo. Die Züchterin beantwortet es in der App; beim nächsten Lauf taucht es als Answered auf und wird wieder aufgegriffen.

4. Umsetzen — gebündelt nach Cluster (Überschneidungen vermeiden!)

Die Triage-Matrix zeigt, welche Tickets sich Dateien teilen. Bündele nach datei-disjunkten Workstreams, damit parallele Subagenten nicht kollidieren:

• Genetik-Engine → gerbil-manager-web/src/genetics/**, tools/import/genotype.py.
• Stammbaum-Import (Eltern/Dedup/Gender/isResident) → tools/import/extract.py, merge_and_resolve.py, conflict-decisions.json.
• Frontend-Anzeige (z. B. Nicht-Bestandstiere ausblenden) → GerbilDetailPage.tsx, de.ts. Gemeinsam genutzte Dateien (de.ts, GerbilDetailPage.tsx) gehören genau einem Workstream — sonst sequenziell. Datenkorrekturen, die die Züchterin nennt, als Override in conflict-decisions.json kodieren (data-driven, re-ingest-stabil). Subagenten committen NICHT und re-ingesten NICHT — das koordiniert der Haupt-Loop.

5. Import neu einspielen (bei Daten-/Import-Änderungen)

python tools/import/extract.py → extract_contracts.py → merge_and_resolve.py, dann POST /import/ingest-resolved (wischt + lädt neu). Danach betroffene Tickets gegen die API verifizieren.

6. Ticket schließen — MIT Changelog

Beim Schließen IMMER dokumentieren, was gefixt wurde, in einfacher Sprache für die Züchterin: PUT /feedback/{id} mit {"status": "Resolved", "fixNote": "<verständliche Erklärung, was korrigiert wurde>"}. Beispiel: „Die Mutter von Yuki wurde auf Izumi korrigiert (vorher fälschlich Benjiro). Bitte Stammbaum neu laden." — keine Code-/Fachbegriffe.

Verifikation vor „fertig"

• Code-Fixes: npx tsc --noEmit, npx vitest run, betroffene npx playwright test, dotnet build/dotnet test, Python-test_*.py — grün.
• Daten-Fixes: in resolved_import.json stichprobenartig prüfen, dann re-ingest + API-Check des konkreten Tiers/Wurfs.
• Jedes erledigte Ticket auf Resolved mit fixNote gesetzt.

Hinweise

• Pro Ticket genau ein Triage-Agent; Umsetzung gebündelt nach Cluster.
• Encoding: deutsche Texte als UTF-8 (Datei, nicht stdin-Pipe).
• Nichts committen, bis der Haupt-Loop verifiziert hat; auf main arbeiten.