Automatisch vom Browser-Fehler zum Code-Fix

Aktuell experimentiere ich damit, meine Unternehmensprozesse als Claude Code Skills in Form eines Skill Trees abzubilden. Auf oberster Ebene stehen die einzelnen Rollen — Buchhaltung, Sales, DevOps — und darunter die jeweils zugehörigen Aufgaben.

Die Idee: Ich spreche meine KI-Mitarbeiter direkt per “Hey [Rolle], mache …” an — wie echte Kollegen. Claude erkennt die Rolle, lädt den passenden Skill und arbeitet die Aufgabe selbstständig ab.

In diesem Post beschreibe ich eine (sehr spezielle) Aufgabe aus der DevOps-Rolle: das Debugging einer App vom Browser-Fehler bis zum Code-Fix. Der Skill spart mir pro Durchlauf rund zwei Stunden manuelle Arbeit — und da ich ihn etwa dreimal pro Woche brauche, kommt da einiges zusammen.

Zielbild

Regelmäßig gibt es den Fall, dass eine Web-Anwendung Fehler zeigt. Mein Ziel: Ich möchte Claude einfach sagen können:

“Hey DevOps Gus, checke bitte meine App unter http://meineapp.lan/hieristderfehler und fixe das.”

Claude soll dann selbstständig loslaufen — rausfinden wo der Code liegt, den Bug identifizieren, Änderungen vornehmen, redeployen und das Ganze wiederholen, bis es funktioniert. Ein autonomer Debug-Loop vom Browser bis zum erfolgreichen Redeploy.

flowchart LR
    A["🌐 Browser\nFehlermeldung"] -->|URL| B["📋 Helm Chart\nIngress → Service"]
    B -->|.lan Hostname| C["🖥️ VM / SSH\nkubectl logs"]
    C -->|Image-Tag| D["🐳 Docker Image\nOCI-Labels"]
    D -->|source + directory\n+ revision| E["💻 Source Code\nBug identifizieren"]
    E -->|git push| F["⚙️ GitHub Actions\nImage bauen"]
    F -->|neues Image| G["🚀 ArgoCD\nAuto-Redeploy"]

    style A fill:#e74c3c,color:#fff
    style B fill:#3498db,color:#fff
    style C fill:#2ecc71,color:#fff
    style D fill:#9b59b6,color:#fff
    style E fill:#f39c12,color:#fff
    style F fill:#1abc9c,color:#fff
    style G fill:#27ae60,color:#fff

Vorarbeiten: Traceability durch OCI-Labels

Damit die Kette vom laufenden Container zurück zum Code funktioniert, braucht es Linking-Informationen im Docker Image selbst. Dafür nutzen wir OCI-Labels — zwei statische im Dockerfile, eins automatisch durch die CI-Pipeline:

FROM base AS final
LABEL org.opencontainers.image.source="https://github.com/Qrist0ph/Akualytics.AI"
LABEL org.opencontainers.image.directory="aipipelines/D4fAccounting"
# image.revision wird automatisch per docker/metadata-action gesetzt

Label	Zweck
`image.source`	URL zum GitHub Repository
`image.directory`	Relativer Pfad zum Projekt im Repo
`image.revision`	Git Commit SHA (automatisch via `docker/metadata-action`)

Damit hat jedes Image drei Breadcrumbs: Repo → Verzeichnis → Commit.

Diese drei Labels sind der Schlüssel zur gesamten Kette — ohne sie wäre der Rückweg vom Container zum Code nicht möglich.

Der manuelle Prozess — Schritt für Schritt

Schritt 1: Von der URL zum Helm Chart

Ein User meldet: “Die App unter acme.yaico.de/dashboard funktioniert nicht.”

Aber welcher Service steckt dahinter? Welches Helm Chart? Welches Image?

Alle Helm Charts liegen in einem zentralen Repository. Der schnellste Weg zum richtigen Chart: nach dem Hostnamen in den Ingress-Definitionen suchen.

cd ~/repos/kubetest
grep -r "acme.yaico.de" --include="*.yaml" -l

Das liefert z.B. pipelines/acme/values.yaml — dort steht der Ingress-Hostname und der Namespace. Im zugehörigen Ingress-Template sieht man, welcher Service hinter welchem Pfad steckt.

Öffentliche Apps haben immer auch einen internen .lan-Endpoint (z.B. acme.yaico.de → acme.lan), der direkt aus dem lokalen Netzwerk erreichbar ist.

Schritt 2: Per SSH auf die VM und Container-Logs prüfen

Der .lan-Hostname zeigt via Pi-hole DNS auf die VM. Per SSH verbinden und Kubernetes-Logs prüfen:

ssh -i ~/.ssh/argobox_bitwarden.pem chris@<hostname>.lan

kubectl get pods -n <namespace>
kubectl logs <pod-name> -n <namespace> --tail=100

Die Logs zeigen die konkrete Fehlermeldung — z.B. eine NullReferenceException, einen fehlenden API-Key oder ein Datenproblem.

Schritt 3: Container-Image → Source Code

Image-Tag aus dem Pod auslesen, dann über die OCI-Labels Repo, Verzeichnis und Commit ermitteln:

kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.containers[0].image}'

crictl inspecti <image> | grep -A5 "Labels"

Aus den Labels ergibt sich ein Direktlink zum exakten Code-Stand.

Schritt 4: Code fixen, pushen, redeployen

Den lokalen Clone des Repos unter C:\repos\ finden — der Repo-Name lässt sich aus der image.source-URL ableiten. Bug identifizieren und fixen.

Nach git push baut die GitHub Action automatisch ein neues Image, und ArgoCD rollt den Pod neu aus.

Danach erneut per SSH auf die VM verbinden und per curl und kubectl logs prüfen, ob der Fehler behoben ist — falls nicht, Loop wiederholen.

Der Skill: Full Stack Debugging

Hintergrund: Claude Code Skills

Claude Code Skills sind Markdown-Dateien, die Claude beibringen, wie es eine bestimmte Aufgabe ausführen soll. Sie werden unter ~/.claude/skills/ abgelegt und bilden zusammen einen Skill Tree — organisiert nach Rollen und Aufgaben. Claude liest den relevanten Skill und führt die beschriebenen Schritte selbstständig aus.

Der oben beschriebene manuelle Prozess lässt sich direkt als Skill formulieren. Statt jeden Schritt selbst zu durchlaufen, gebe ich Claude die Anweisung und es arbeitet den Skill autonom ab — inklusive SSH, kubectl, Code-Analyse, Fix, Push und Redeploy.

Der komplette Skill

📄 ~/.claude/skills/devops/full-stack-debugging.md

# Full Stack Debugging

Autonomer Debug-Loop: Vom Browser-Fehler über Kubernetes bis zum Code-Fix und Redeploy.

## Voraussetzung

Alle Docker Images sollten OCI-Labels enthalten, die den Weg zurück zum Code ermöglichen:
- `org.opencontainers.image.source` — URL zum GitHub Repository
- `org.opencontainers.image.directory` — Relativer Pfad zum Projekt im Repo
- `org.opencontainers.image.revision` — Git Commit SHA (automatisch via `docker/metadata-action`)

## Ablauf

Der User gibt eine URL (öffentlich oder `.lan`) und eine Fehlerbeschreibung.
Dann folge diesen Schritten:

### 1. URL → Helm Chart & Namespace

Suche im zentralen Helm-Chart-Repo nach dem Hostnamen aus der User-URL.
In der gefundenen values.yaml stehen Ingress-Hostname, Service-Zuordnung und Namespace.
Falls die URL öffentlich ist, suche auch den internen .lan-Endpoint.

### 2. SSH auf die VM, Container-Logs prüfen

Verbinde dich per SSH mit dem internen VM-Namen.
Prüfe die Logs der betroffenen Pods im ermittelten Namespace.
Auch kubectl events und ArgoCD CLI können hilfreich sein.

### 3. Container-Image → Source Code

Image-Tag aus dem laufenden Pod auslesen.
OCI-Labels aus dem Image lesen — sie liefern Repo-URL, Verzeichnis und Commit-SHA.

### 4. Code finden und Bug fixen

Source-Code-Repo lokal unter C:\repos\ finden (Repo-Name aus image.source-URL ableiten).
Auf main pullen, Fehlermeldung aus den Logs gezielt im Code suchen, Bug identifizieren und fixen.

### 5. Sicherstellen dass CI/CD existiert

Prüfe, dass eine GitHub Action für den Image-Build existiert.

### 6. Commit, Push, Warten auf Build

Änderungen committen, pushen und warten bis die GitHub Action
das neue Image gebaut und gepusht hat.

### 7. Rollout im Cluster

Erneut per SSH auf die VM verbinden.
ArgoCD erkennt das neue Image normalerweise automatisch.
Falls nicht, manuell syncen.

### 8. Fehler reproduzieren

Auf der VM per curl und kubectl logs prüfen, ob der Fehler behoben ist.
Falls nicht: zurück zu Schritt 2.

Zusammenfassung

Der gesamte Prozess in vier Schritten — von der Fehlermeldung bis zum erfolgreichen Redeploy:

Schritt	Aktion	Tool
1. URL → Helm Chart	Hostname im Helm-Repo suchen, Ingress-Pfad → Service identifizieren	`grep`, Helm Values
2. SSH → Container-Logs	Über `.lan`-Hostname auf die VM, Pod-Logs lesen	SSH, `kubectl logs`
3. Image → Source Code	OCI-Labels aus dem Image lesen: Repo, Verzeichnis, Commit	`crictl inspecti`
4. Code fixen & deployen	Bug finden, fixen, pushen — CI/CD baut und deployt automatisch	`git`, GitHub Actions, ArgoCD