Fähigkeiten systematic-debugging

🔍

systematic-debugging

Name: systematic-debugging
Author: ZhanlinCui

Niedriges Risiko ⚙️ Externe Befehle

Systematisch debuggen, um Grundursachen vor der Behebung zu finden

Auch verfügbar von: Cygnusfear,Cycleaddict,Doyajin174,DMJGilbert,Asmayaseen,DYAI2025,davila7,CodingCossack,obra,ChrisWiles

Zufällige Fixes verschwenden Zeit und erzeugen neue Bugs. Diese Fähigkeit bietet ein vierphasiges Debugging-Framework, das Grundursachen vor der Implementierung von Lösungen findet und somit verschwendete Mühe bei symptomorientierten Fixes verhindert.

Unterstützt: Claude Codex Code(CC)

🥉 72 Bronze

Die Skill-ZIP herunterladen

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

Einschalten und loslegen

Teste es

Verwendung von "systematic-debugging". Test schlägt mit git init Fehler im falschen Verzeichnis fehl

Erwartetes Ergebnis:

Phase 1 - Grundursachenuntersuchung:
1. Fehler zeigt git init läuft in /source/code nicht /tmp
2. Rückwärts verfolgt: git init <- WorktreeManager <- Session.create <- Test
3. Gefunden: projectDir war leerer String, aufgelöst zu process.cwd()
4. Grundursache: Test hat auf context.tempDir zugegriffen, bevor beforeEach es initialisiert hat
Grundursache identifiziert: Problem mit Variablen-Initialisierungsreihenfolge

Verwendung von "systematic-debugging". Flaky Test, der manchmal Tool-Ergebnisse verpasst

Erwartetes Ergebnis:

Diagnose: Test verwendet willkürliche setTimeout-Wartezeiten statt Konditionsprüfung
Lösung: Timeouts durch konditionsbasiertes Warten ersetzen
VORHER: await new Promise(r => setTimeout(r, 300))
NACHHER: await waitForEventCount(threadManager, id, 'TOOL_RESULT', 2)
Ergebnis: 60% Bestehensrate auf 100% verbessert

Sicherheitsaudit

Niedriges Risiko

v1 • 2/24/2026

Static analyzer flagged 126 patterns but 125 are false positives from markdown documentation (backticks are code formatting, not shell execution). One legitimate shell script (find-polluter.sh) uses npm test for test debugging - acceptable for a debugging skill. No cryptographic code exists despite scanner claims. Skill teaches debugging methodology safely.

Gescannte Dateien

1,262

Analysierte Zeilen

befunde

Gesamtzahl Audits

Probleme mit niedrigem Risiko (1)

find-polluter.sh:42

Shell Script for Test Debugging

find-polluter.sh executes npm test commands to identify which test creates unwanted files or state. This is legitimate test infrastructure for a debugging skill.

Risikofaktoren

⚙️ Externe Befehle (1)

find-polluter.sh:42

Auditiert von: claude

Qualitätsbewertung

Architektur

100

Wartbarkeit

Inhalt

Community

Sicherheit

Spezifikationskonformität

Was du bauen kannst

Test-Fehler-Untersuchung

Wenn Tests intermittierend oder unerwartet fehlschlagen, verwenden Sie diese Fähigkeit, um den Fehler systematisch bis zur Grundursache zurückzuverfolgen, anstatt schnelle Fixes anzuwenden.

Produktions-Bug-Behebung

Wenn Bugs in der Produktion auftreten, folgen Sie dem vierphasigen Prozess, um die Grundursache zu verstehen, bevor Sie Fixes bereitstellen, die neue Probleme erzeugen könnten.

Mehrkomponenten-Debugging

Beim Debuggen komplexer Systeme mit mehreren Ebenen, verwenden Sie Defense-in-Depth-Diagnostik, um genau zu identifizieren, welche Komponente fehlschlägt.

Probiere diese Prompts

Grundlegende Bug-Untersuchung

Ich sehe diesen Fehler: [Fehler einfügen]. Ich möchte ihn schnell beheben, aber ich weiß, dass ich zuerst untersuchen sollte. Helfen Sie mir, Phase 1 des systematischen Debuggings zu befolgen, um die Grundursache zu verstehen, bevor ich irgendwelche Fixes vorschlage.

Flaky Test Debugging

Dieser Test schlägt intermittierend fehl: [Test einfügen]. Manchmal besteht er, manchmal schlägt er fehl. Führen Sie mich durch systematisches Debugging, um herauszufinden, was die Flakiness verursacht, einschließlich dem Hinzufügen von diagnostischer Instrumentierung.

Mehrschichtsystem-Ausfall

Mein System hat [Ebenen beschreiben: z.B. CI-Workflow, Build-Skript, Signing-Prozess]. Etwas bricht, aber ich weiß nicht, welche Ebene. Zeigen Sie mir, wie ich an jeder Grenze evidenzsammelnde Instrumentierung hinzufüge, um die fehlschlagende Komponente zu isolieren.

Fehlgeschlagene-Fix-Wiederherstellung

Ich habe bereits [N] Fixes versucht und keiner hat funktioniert. Jeder Fix hat ein neues Problem aufgedeckt. Helfen Sie mir zu stoppen und zu hinterfragen, ob es ein architektonisches Problem gibt, bevor ich einen weiteren Fix versuche. Führen Sie mich durch die erneute Analyse ab Phase 1.

Bewährte Verfahren

Phase 1 Untersuchung immer abschließen, bevor irgendein Fix vorgeschlagen wird - die Grundursache zu verstehen ist schneller als mit zufälligen Fixes zu thrashen
Bugs rückwärts durch den Call Stack verfolgen, um den ursprünglichen Auslöser zu finden, nicht nur dort wo der Fehler erscheint
Nach 3 fehlgeschlagenen Fix-Versuchen stoppen und die Architektur hinterfragen, anstatt weitere Symptom-Fixes zu versuchen

Vermeiden

Fixes vorschlagen, bevor die Grundursachenuntersuchung abgeschlossen ist - dies behandelt Symptome, nicht Ursachen
Mehrere Änderungen auf einmal vornehmen - man kann nicht isolieren, was funktioniert hat, und kann neue Bugs einführen
Den fehlschlagenden Test überspringen - ungetestete Fixes halten nicht und Regressionen bleiben unbemerkt

Häufig gestellte Fragen

Ist systematisches Debugging nicht langsamer als einfach schnelle Fixes zu versuchen?

Nein. Studien aus tatsächlichen Sessions zeigen, dass systematisches Debugging 15-30 Minuten dauert gegenüber 2-3 Stunden Thrashing mit zufälligen Fixes. Die First-Time-Fix-Rate beträgt 95% gegenüber 40%.

Was ist, wenn ich in einem Notfall bin und sofort einen Fix brauche?

Notfälle machen Raten verlockend, aber systematisch ist immer noch schneller. Eile garantiert Nacharbeit. Der Prozess ist designed, um Zeitdruck-Rationalisierung zu widerstehen.

Wie weiß ich, wann ich die echte Grundursache gefunden habe?

Sie können die komplette Kette vom Symptom zurück zur Quelle verfolgen. Wenn Sie an der Quelle fixen und Validierung auf jeder Ebene hinzufügen, wird der Bug unmöglich.

Was ist, wenn meine erste Hypothese falsch ist?

Das ist erwartbar. Bilden Sie eine einzelne Hypothese, testen Sie sie minimal, und wenn sie fehlschlägt, kehren Sie mit neuen Informationen zu Phase 1 zurück. Fügen Sie niemals weitere Fixes auf fehlgeschlagene Fixes hinzu.

Wann sollte ich die Architektur hinterfragen versus weiter debuggen?

Nach 3 fehlgeschlagenen Fix-Versuchen, bei denen jeder neue Probleme an verschiedenen Stellen aufdeckt, stoppen Sie. Dies deutet auf architektonische Probleme hin, nicht nur Bugs. Besprechen Sie Refactoring vor weiteren Fixes.

Funktioniert dies auch für Nicht-Code-Bugs wie Konfigurationsprobleme?

Ja. Der vierphasige Prozess gilt für jedes technische Problem: reproduzieren, Evidenz sammeln, Datenfluss verfolgen, Unterschiede zu funktionierenden Konfigurationen identifizieren.