🔍

systematic-debugging

Name: systematic-debugging
Author: Cygnusfear

آمن ⚡ يحتوي على سكربتات📁 الوصول إلى نظام الملفات

Systematisches Debugging für jeden Bug anwenden

متاح أيضًا من: Doyajin174,Asmayaseen,sickn33,CodingCossack,DMJGilbert,obra,Cycleaddict,ZhanlinCui,DYAI2025,ChrisWiles,davila7

Zufällige Fixes verschwenden Zeit und erzeugen neue Bugs. Diese Skill bietet eine Vier-Phasen-Methode, um die Grundursache zu finden, bevor ein Fix versucht wird. Sie verhindert Symptom-Level-Patching und sorgt für dauerhafte Lösungen.

يدعم: Claude Codex Code(CC)

📊 69 كافٍ

تنزيل ZIP المهارة

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

فعّل وابدأ الاستخدام

اختبرها

استخدام "systematic-debugging". Test fails with 'Expected status completed but received pending'

النتيجة المتوقعة:

Phase 1 - Grundursache: Nachverfolgen, wann Status gesetzt wird versus wann wir ihn prüfen
Phase 2 - Muster: Funktionierende Tests finden, die Status-Updates verifizieren
Phase 3 - Hypothese: Möglicherweise wird asynchrone Operation vor Assertion nicht erwartet
Phase 4 - Implementierung: waitFor-Bedingung hinzufügen, um tatsächliche Zustandsänderung zu erkennen

استخدام "systematic-debugging". File created in wrong directory during tests

النتيجة المتوقعة:

Phase 1 - Grundursache: find-polluter.sh verwenden, um zu identifizieren, welcher Test die Datei erstellt
Phase 2 - Muster: Mit Tests vergleichen, die sauber laufen
Phase 3 - Hypothese: Leere Pfadvariable löst zu cwd auf
Phase 4 - Implementierung: Validierungsschicht hinzufügen, die Operation außerhalb von tmpdir verweigert

استخدام "systematic-debugging". Environment secrets not reaching build layer

النتيجة المتوقعة:

Phase 1 - Beweis: Umgebungsvariablen auf jeder Ebene protokollieren (Workflow, Build, Signieren)
Phase 2 - Muster: Finden, wo Weitergabe zusammenbricht
Phase 3 - Hypothese: Layer-Transition entfernt Umgebung
Phase 4 - Implementierung: Defense-in-Depth-Prüfung auf jeder Ebenengrenze hinzufügen

التدقيق الأمني

آمن

v5 • 1/17/2026

This is a legitimate debugging methodology skill containing only documentation and code examples. All 138 static findings are FALSE POSITIVES. The flagged patterns are markdown documentation showing example debugging commands, shell variable expansion, environment checks, and standard filesystem operations - all used for legitimate debugging documentation purposes. No malicious code or intent present.

الملفات التي تم فحصها

1,489

الأسطر التي تم تحليلها

النتائج

إجمالي عمليات التدقيق

عوامل الخطر

⚡ يحتوي على سكربتات (1)

find-polluter.sh:1-64

📁 الوصول إلى نظام الملفات (1)

condition-based-waiting-example.ts:1-159

تم تدقيقه بواسطة: claude عرض سجل التدقيق →

درجة الجودة

الهندسة المعمارية

100

قابلية الصيانة

المحتوى

المجتمع

100

الأمان

الامتثال للمواصفات

ماذا يمكنك بناءه

Testfehler richtig beheben

Aufhören, Sleep-Statements hinzuzufügen. Nachverfolgen, warum Tests an der Quelle fehlgehen, für permanente Fixes.

Symptom-Level-Patching vermeiden

Dokumentierten Prozess befolgen anstatt Fixes zu raten, wenn unerwartetes Verhalten auftritt.

Komplexe Aufrufstapel nachverfolgen

Finden, wo ungültige Daten in Mehrkomponentensystemen mit bewährten Nachverfolgungstechniken entstehen.

جرّب هذه الموجهات

Grundlegendes Bug-Untersuchen

Load skills/debugging/systematic-debugging und hilf mir, diesen Testfehler zu untersuchen. Der Test erwartet X, aber erhielt Y.

Mehrschichtiges System-Debugging

Verwende die Grundursachen-Nachverfolgungstechnik, um diesen Bug rückwärts durch die Aufrufkette zu verfolgen. Der Fehler erscheint in Zeile N.

Flaky-Test-Muster

Wende das bedingungsbasierte Warte-Muster an, um beliebige Timeouts in dieser Testdatei zu ersetzen.

Symptom-Fixen verhindern

Überprüfe meine Arbeit gegen den systematischen Debugging-Prozess. habe ich tatsächlich die Grundursache gefunden?

أفضل الممارسات

Phase 1 (Grundursache) immer abschließen, bevor ein Fix vorgeschlagen wird, auch unter Zeitdruck
Rückwärts durch die Aufrufkette verfolgen, wo schlechte Daten entstanden sind, nicht wo sie sich manifestieren
Validierung auf jeder Ebene hinzufügen, durch die Daten fließen, um Bugs strukturell unmöglich zu machen

تجنب

Sleep-Statements hinzufügen, anstatt auf tatsächliche Bedingungen zu warten
Dort fixieren, wo der Fehler erscheint, anstatt zur Quelle zurückzuverfolgen
Mehrere Fixes auf einmal vorschlagen, um 'mehr Abdeckung zu erhalten'

الأسئلة المتكررة

Can I skip to the fix if the issue seems obvious?

Nein. Die Skill verlangt den Abschluss von Phase 1 vor jedem Fix. Einfache Bugs haben auch Grundursachen. Systematisch ist schneller als Herumfummeln.

What if I do not understand the codebase well enough to trace root cause?

Sage 'Ich verstehe X nicht' anstatt zu raten. Um Hilfe bitten oder mehr recherchieren. Die Skill schätzt Ehrlichkeit über Vortäuschung.

How do I handle production emergencies with this skill?

Die Skill erkennt Druck an, erfordert aber zuerst Untersuchung. Schnelle Fixes verbergen Probleme, die wieder auftreten. Systematisches Debugging handhabt Notfälle schneller als Symptom-Whack-a-Mole.

When should I use condition-based waiting?

Beliebige Sleep- oder Timeout-Aufrufe durch Pollen auf die tatsächliche Bedingung ersetzen. Dies eliminiert fehlerhafte Tests, die auf schnellen Maschinen bestehen, aber in CI fehlschlagen.

What if three fixes have already failed?

Anhalten und die Architektur hinterfragen. Drei fehlgeschlagene Fixes zeigen oft ein strukturelles Problem, kein zu patchendes Symptom. Mit Ihrem menschlichen Partner besprechen.

How is this different from test-driven development?

TDD schreibt Tests vor Code. Diese Skill untersucht Bugs, wenn sie auftreten. Beide erfordern das Verstehen der Grundursache, dienen aber verschiedenen Entwicklungsphasen.