name	systematic-debugging
description	Senior-Dev-Debugging-Pipeline. Ursachenforschung → Hypothesen → Fixes → Dokumentation. Kein wildes Rumgestochere.

Systematic Debugging

Wozu

Strukturierte Bug-Hunting-Pipeline statt Trial-and-Error:

Reproduktion festnageln (welche genauen Schritte? welche Browser? welche Daten?).
Symptome vs. Ursache trennen — was sieht der User, was passiert technisch?
Hypothesen formulieren (mind. 3, nach Wahrscheinlichkeit geordnet).
Hypothese verifizieren / falsifizieren (kleinster mögliche Test, ein change at a time).
Root Cause benennen (nicht „das, was den Symptom-Fix bewirkt hat", sondern die echte Wurzel).
Fix umsetzen + Regression-Test schreiben.
Doku schreiben: was war der Bug, warum ist er entstanden, wie wurde er gefixt, wie verhindern wir die Klasse zukünftig?

Setup

Pure Markdown-Skill — Rezept als Prompt.

Use-Case in LocalPilot AI

Hoch relevant. Bisher 2 Bug-Hotfixes (Code-Sessions 23 + 25). Beide hätten von strukturierter Debug-Pipeline profitiert. Konkrete Anwendung:

Vor jedem Maintenance-Commit: die 7 Schritte explizit im Commit-Body durchgehen — nicht nur „Fix XYZ".
Klasse-statt-Instanz: nach dem Fix immer fragen „kann das an anderen Stellen auch passieren?" und Codex-Backlog-Item schreiben (so entstand z. B. #10 für die Anführungszeichen-Bugs).
In docs/RUN_LOG.md: Maintenance-Einträge bekommen ab jetzt eine Root Cause:-Zeile, nicht nur eine Fix:-Zeile.

Integration mit unserem Session-Protokoll

Maintenance-Sessions bekommen ein erweitertes Format:

## Code-Session N – Hotfix: <kurze Beschreibung>

**Symptom**: was hat der User gesehen?
**Reproduktion**: schritte, daten, browser.
**Hypothesen** (geprüft):
  1. ✗ <hypothese> — verworfen, weil …
  2. ✓ <hypothese> — bestätigt, weil …
**Root Cause**: …
**Fix**: …
**Regression-Test**: …
**Klasse-Check**: kann das an anderen Stellen passieren? → Codex-Backlog-Item.

Ersetzt das normale Compact-Format für Bug-Sessions — Feature- Sessions bleiben beim Standard-Compact-Format.

Mehr aus diesem Repository

gleiches Repository

algorithmic-art

BEKO2210/LocalPilot-AI

Generative p5.js-Artworks aus natürlicher Beschreibung. Reproduzierbar via Seed.

2026-04-270

brand-guidelines

BEKO2210/LocalPilot-AI

Multi-Brand-Registry. Mehrere Marken in einem Repo, schnell wechseln, getrennt halten.

2026-04-270

document-suite

BEKO2210/LocalPilot-AI

Offizielle Anthropic-Skill-Suite für Word/Excel/PowerPoint/PDF. Echte Dokumente mit Formatierung, Formeln, Bildern — nicht nur Plaintext.

2026-04-270

mcp-builder

BEKO2210/LocalPilot-AI

Generiert MCP-Server-Boilerplate (TypeScript / Python). Kürzt das Setup für eigene Integrationen um ~80 %.

2026-04-270

rube-mcp

BEKO2210/LocalPilot-AI

Brücke zu 500+ Apps (Slack, GitHub, Notion, Linear, Jira, Google Drive, Calendar, Gmail, …) über einen einzigen MCP-Server. Spart pro App die einzelne OAuth-Einrichtung.

2026-04-270

slack-gif-creator

BEKO2210/LocalPilot-AI

Erstellt benutzerdefinierte animierte GIFs, optimiert für Slack (Größe, FPS, Loop).

2026-04-270

Systematic Debugging

Wozu

Strukturierte Bug-Hunting-Pipeline statt Trial-and-Error:

Reproduktion festnageln (welche genauen Schritte? welche Browser? welche Daten?).

Symptome vs. Ursache trennen — was sieht der User, was passiert technisch?

Hypothesen formulieren (mind. 3, nach Wahrscheinlichkeit geordnet).

Hypothese verifizieren / falsifizieren (kleinster mögliche Test, ein change at a time).

Root Cause benennen (nicht „das, was den Symptom-Fix bewirkt hat", sondern die echte Wurzel).

Fix umsetzen + Regression-Test schreiben.

Doku schreiben: was war der Bug, warum ist er entstanden, wie wurde er gefixt, wie verhindern wir die Klasse zukünftig?

Setup

Pure Markdown-Skill — Rezept als Prompt.

Use-Case in LocalPilot AI

Hoch relevant. Bisher 2 Bug-Hotfixes (Code-Sessions 23 + 25). Beide hätten von strukturierter Debug-Pipeline profitiert. Konkrete Anwendung:

Vor jedem Maintenance-Commit: die 7 Schritte explizit im Commit-Body durchgehen — nicht nur „Fix XYZ".

Klasse-statt-Instanz: nach dem Fix immer fragen „kann das an anderen Stellen auch passieren?" und Codex-Backlog-Item schreiben (so entstand z. B. #10 für die Anführungszeichen-Bugs).

In docs/RUN_LOG.md: Maintenance-Einträge bekommen ab jetzt eine Root Cause:-Zeile, nicht nur eine Fix:-Zeile.

Integration mit unserem Session-Protokoll

Maintenance-Sessions bekommen ein erweitertes Format:

## Code-Session N – Hotfix: <kurze Beschreibung> **Symptom**: was hat der User gesehen? **Reproduktion**: schritte, daten, browser. **Hypothesen** (geprüft): 1. ✗ <hypothese> — verworfen, weil … 2. ✓ <hypothese> — bestätigt, weil … **Root Cause**: … **Fix**: … **Regression-Test**: … **Klasse-Check**: kann das an anderen Stellen passieren? → Codex-Backlog-Item.

Ersetzt das normale Compact-Format für Bug-Sessions — Feature- Sessions bleiben beim Standard-Compact-Format.