Escalate Issues

Probleme eskalieren

Wann verwenden

Diesen Skill verwenden wenn eine Wartungsaufgabe auf Probleme stoesst die ueber automatisierte Bereinigung hinausgehen:

• Unsicher ob Code sicher geloescht werden kann
• Konfigurationsaenderungen erfordern Domaenenwissen (Sicherheit, Performance, Architektur)
• Waehrend der Bereinigung erkannte brechende Aenderungen
• Komplexes Refactoring erforderlich (nicht nur Bereinigung)
• Sicherheitsrelevante Befunde (hartcodierte Geheimnisse, Schwachstellen)

NICHT verwenden fuer einfache Probleme mit klaren Loesungen. Nur eskalieren wenn automatisierte Bereinigung riskant oder unzureichend ist.

Eingaben

Vorgehensweise

Schritt 1: Schweregrad bewerten

Das Problem mit Standard-Schweregradstufen klassifizieren.

KRITISCH — Blockiert Produktionsfunktionalitaet:

• Defekte Imports in aktiv genutztem Code
• Sicherheitsschwachstellen (offengelegte Geheimnisse, SQL-Injection)
• Datenverlustrisiko durch Bereinigungsoperation
• Produktionsdienstausfaelle

HOCH — Beeintraechtigt Wartbarkeit oder Entwicklerproduktivitaet:

• Erheblicher toter Code (>1000 Zeilen)
• Defekte CI/CD-Pipelines
• Grosse Konfigurationsdrift zwischen Umgebungen
• Unreferenzierte Module die moeglicherweise dynamisch geladen werden

MITTEL — Geringfuegige Hygieneprobleme:

• Ungenutzte Hilfsfunktionen (<100 Zeilen)
• Veraltete Dokumentation die Aktualisierung erfordert
• Veraltete Konfigurationsdateien (nicht mehr verwendet aber vorhanden)
• Lint-Warnungen in unkritischen Pfaden

NIEDRIG — Stilinkonsistenzen:

• Gemischte Einrueckung (funktioniert aber inkonsistent)
• Nachfolgende Leerzeichen
• Inkonsistente Benennung (camelCase vs snake_case)
• Geringfuegige Formatierungsunterschiede

Schweregrad-Entscheidungsbaum:

Bricht es die Produktion? -> KRITISCH
Blockiert es die Entwicklung? -> HOCH
Beeintraechtigt es die Codequalitaet? -> MITTEL
Ist es rein kosmetisch? -> NIEDRIG

Erwartet: Problem mit klarem Schweregrad-Label klassifiziert

Bei Fehler: Wenn unsicher, Standard HOCH waehlen und zur Neueinschaetzung an einen Menschen eskalieren

Schritt 2: Befund dokumentieren

Allen relevanten Kontext fuer den Spezialisten zur Pruefung erfassen.

Fehlerbericht-Vorlage:

# Problem: [Kurzer Titel]

**Schweregrad**: KRITISCH | HOCH | MITTEL | NIEDRIG
**Entdeckt waehrend**: [Skill-Name, z.B. clean-codebase]
**Datum**: JJJJ-MM-TT
**Blockierend**: Ja | Nein

## Beschreibung

Klare Beschreibung des Problems in 2-3 Saetzen.

## Kontext

- **Datei(en)**: [Liste betroffener Dateien mit Zeilennummern]
- **Verwandt**: [Verwandte Issues, Commits oder fruehere Loesungsversuche]
- **Auswirkung**: [Was bricht wenn nicht behoben, oder was wird verschwendet wenn nicht bereinigt]

## Beweismaterial

```sprache
# Code-Ausschnitt oder Log-Auszug der das Problem zeigt
```

## Versuchte Loesungen

- X versucht aber gescheitert wegen Y
- Z in Betracht gezogen aber unsicher wegen W

## Empfehlung

- **Option 1**: [Sicherer konservativer Ansatz]
- **Option 2**: [Aggressivere Loesung mit Risiken]
- **Bevorzugt**: [Welche Option und warum]

## Spezialisten-Routing

**Vorgeschlagener Agent**: [Agentname]
**Begruendung**: [Warum dieser Spezialist geeignet ist]

## Referenzen

- [Link zu verwandter Dokumentation]
- [Link zu aehnlichen frueheren Problemen]

Erwartet: Problem mit vollstaendigem Kontext in ESCALATION_REPORTS/issue_JJJJMMTT_HHMM.md dokumentiert

Bei Fehler: (Entfaellt — immer dokumentieren, auch wenn unvollstaendig)

Schritt 3: Routing bestimmen

Problemtyp dem geeigneten Spezialisten-Agenten oder menschlichen Pruefer zuordnen.

Routing-Tabelle:

Automatische Routing-Logik:

def route_issue(severity, issue_type):
    if severity == "CRITICAL":
        # Kritische Probleme immer an Menschen eskalieren
        return "human"

    if "security" in issue_type or "secret" in issue_type:
        return "security-analyst"

    if "gxp" in issue_type or "compliance" in issue_type:
        return "gxp-validator"

    if "architecture" in issue_type or "design" in issue_type:
        return "senior-software-developer"

    if "config" in issue_type or "deployment" in issue_type:
        return "devops-engineer"

    # Standard: code-reviewer fuer allgemeine Code-Probleme
    return "code-reviewer"

Erwartet: Problem mit Begruendung an geeigneten Spezialisten geroutet

Bei Fehler: Wenn kein klarer Spezialist, an Menschen fuer manuelles Routing eskalieren

Schritt 4: Umsetzbaren Fehlerbericht erstellen

Einen formatierten Bericht erstellen der fuer die Zielgruppe geeignet ist (Agent oder Mensch).

Fuer Spezialisten-Agenten (strukturiertes Format fuer MCP-Tools): Emit one document: the routing header delimited by --- fences, then the report body beneath it. The receiving tool parses the header keys, so those and the agent ids stay in English.

type: escalation
severity: high
from_agent: janitor
to_agent: security-analyst
blocking: false

# Security Concern: Hardcoded API Key in Config

**File**: config/production.yml:45
**Pattern**: API_KEY="sk_live_abc123..."

**Request**: Please review if this is a valid secret or a placeholder.
If valid, recommend secure credential management strategy.

**Context**: Discovered during config cleanup sweep.

Fuer menschliche Pruefer (ausfuehrliches Markdown):

# Eskalierungsbericht: Unsichere Loeschung toten Codes

**Von**: Janitor-Agent
**Datum**: 2026-02-16
**Schweregrad**: HOCH

## Problem

Datei `src/legacy_payments.js` (450 Zeilen) erscheint ungenutzt, enthaelt
aber komplexe Zahlungsverarbeitungslogik. Statische Analyse zeigt null
Referenzen, aber der Name deutet auf geschaeftskritische Funktionalitaet.

## Grund der Eskalierung

- Unsicher ob Zahlungscode zur Laufzeit dynamisch geladen wird
- Potenzielles Datenverlustrisiko bei falscher Loeschung
- Erfordert Domaenenwissen um geschaeftliche Auswirkung zu bewerten

## Beweismaterial

- Keine direkten Imports gefunden
- Letzte Aenderung vor 8 Monaten
- Git-Historie zeigt Zugehoerigkeit zum Zahlungs-Refactoring

## Empfehlung

Menschliche Pruefung vor Loeschung anfordern. Wenn als tot bestaetigt:
1. Nach archive/legacy/ archivieren
2. In ARCHIVE_LOG.md dokumentieren
3. Ticket erstellen um Zahlungsablaeufe zu verifizieren

## Naechste Schritte

Warte auf menschliche Bestaetigung vor Fortsetzung der Bereinigung.

Erwartet: Bericht fuer die Zielgruppe angemessen formatiert

Bei Fehler: (Entfaellt — Bericht im generischen Markdown generieren wenn unsicher)

Schritt 5: Eskalierungsstatus verfolgen

Ein Protokoll aller Eskalierungen fuehren um doppelte Berichte zu vermeiden.

# Eskalierungsprotokoll

| ID | Datum | Schweregrad | Problem | Spezialist | Status |
|----|-------|-------------|---------|-----------|--------|
| ESC-001 | 2026-02-16 | KRITISCH | Defekter Prod-Import | Mensch | Geloest |
| ESC-002 | 2026-02-16 | HOCH | Toter Zahlungscode | Mensch | Ausstehend |
| ESC-003 | 2026-02-16 | MITTEL | Konfigurationsdrift | devops-engineer | In Arbeit |

Erwartet: ESCALATION_LOG.md mit neuem Eintrag aktualisiert

Bei Fehler: Wenn das Protokoll nicht existiert, erstellen

Schritt 6: Benachrichtigen und blockieren (falls erforderlich)

Wenn das Problem weitere Wartung blockiert, benachrichtigen und Bereinigung pausieren.

Blockierungslogik:

• KRITISCHE Probleme blockieren immer
• HOHE Probleme blockieren wenn im kritischen Pfad
• MITTLERE/NIEDRIGE Probleme blockieren nicht

Benachrichtigung:

WARTUNG BLOCKIERT

Problem ESC-002 (HOHER Schweregrad) erfordert menschliche Pruefung
vor Fortsetzung.

**Betroffene Operation**: clean-codebase (Schritt 5: Toten Code entfernen)
**Grund**: Unsicher ob src/legacy_payments.js wirklich tot ist

**Erforderliche Aktion**: ESCALATION_REPORTS/ESC-002_2026-02-16.md pruefen

Nach Loesung Wartung ab Schritt 5 erneut ausfuehren.

Erwartet: Wartung pausiert; klare Benachrichtigung generiert

Bei Fehler: Wenn der Benachrichtigungsmechanismus nicht verfuegbar ist, im Bericht dokumentieren

Validierung

Nach der Eskalierung:

• Schweregrad des Problems korrekt bewertet
• Vollstaendiger Kontext dokumentiert (Dateien, Beweise, Versuche)
• Geeigneter Spezialist identifiziert
• Eskalierungsbericht in ESCALATION_REPORTS/ erstellt
• ESCALATION_LOG.md aktualisiert
• Blockierungsstatus kommuniziert falls zutreffend
• Keine sensiblen Informationen im Bericht offengelegt

Haeufige Stolperfallen

1. Uebereskalierung: Einfache Probleme eskalieren verschwendet Spezialisten-Zeit. Nur eskalieren wenn wirklich unsicher oder riskant.

2. Untereskalierung: Code loeschen "um zu sehen ob die Tests bestehen" ohne Eskalierung kann Produktionsausfaelle verursachen.

3. Unzureichender Kontext: Ohne Beweise eskalieren zwingt Spezialisten zur erneuten Untersuchung. Dateipfade, Zeilennummern, Fehlermeldungen beifuegen.

4. Vage Beschreibungen: "Irgendwas stimmt nicht mit der Config" ist nicht umsetzbar. Spezifisch sein: "Konfigurationsdrift: Dev nutzt API v1, Prod nutzt v2".

5. Status nicht verfolgen: Bereits gepruefte Probleme erneut eskalieren. Zuerst ESCALATION_LOG.md pruefen.

6. Geheimnisse offenlegen: Tatsaechliche API-Schluessel oder Passwoerter in Eskalierungsberichte aufnehmen. Sensible Werte schwaerzen.

Verwandte Skills

• clean-codebase — Loest haeufig Eskalierungen aus wenn Unsicherheit besteht
• tidy-project-structure — Kann komplexe organisatorische Probleme aufdecken
• repair-broken-references — Eskalieren wenn unklar ob Referenz behoben oder entfernt werden soll