fix ist ein Playwright-Debugging-Skill für fehlschlagende oder flaky Tests. Er führt Agenten durch Reproduktion, Burn-in-Läufe, Trace-Erfassung und eine taxonomiebasierte Diagnose von Timing-, Isolations-, Umgebungs- und Infrastrukturproblemen.
Dieser Skill erreicht 80/100 Punkte und ist damit ein solider Kandidat für Verzeichnisnutzer, die einen Agenten zum Debuggen fehlschlagender oder flaky Playwright-Tests suchen – mit weniger Rätselraten als bei einem generischen Prompt. Er hat klare Trigger und eine brauchbare Troubleshooting-Taxonomie. Die Einschätzung der Einführung wird jedoch dadurch erschwert, dass Installations- und README-Material fehlen und Annahmen über das Playwright-Setup der Nutzer getroffen werden.
- Gut auslösbares Frontmatter mit konkreten Nutzerformulierungen wie "fix test", "flaky test", "debug test" und "intermittent failure".
- Bietet einen praxisnahen Diagnoseablauf: reproduzieren, Burn-in mit wiederholten Läufen, Ausführung mit parallelen Workern, Traces erfassen und den Fehler einordnen.
- Enthält eine separate Taxonomie für flaky Tests mit Entscheidungsbaum und konkreten Playwright-Fixmustern für Timing-, Isolations-, Umgebungs- und Infrastrukturprobleme.
- Im Skill-Verzeichnis werden kein Installationsbefehl, keine README und keine Metadaten bereitgestellt. Nutzer müssen die Installation daher aus dem größeren Repository-Kontext ableiten.
- Der Workflow setzt ein Node/Playwright-Projekt mit npx voraus und bietet nur begrenzte Orientierung für Projekte mit eigenen Runnern, Konfigurationen oder ungewöhnlichen CI-Setups.
Überblick über den fix skill
Was der fix skill leistet
Der fix skill ist ein fokussierter Debugging-Workflow für fehlgeschlagene oder instabile Playwright-Tests. Er hilft einem AI Agent, von „dieser Test ist kaputt“ zu einer wahrscheinlichen Ursache zu gelangen, indem der Fehler reproduziert, Trace-Belege gesammelt und das Problem anhand einer Taxonomie für flaky Tests eingeordnet wird — statt nur aus der Assertion-Fehlermeldung zu raten.
Am besten geeignet für Playwright-Test-Debugging
Installieren Sie diesen Skill, wenn Sie End-to-End-Tests betreuen und regelmäßig Meldungen wie „test failing“, „flaky test“, „passes locally but fails in CI“ oder „intermittent failure“ sehen. Besonders hilfreich ist er für Teams, die Playwright in CI einsetzen, wo Fehler durch Timing, fehlende Testisolation, Unterschiede in der Umgebung oder Infrastrukturbelastung entstehen können.
Warum er nützlicher ist als ein generischer Prompt
Ein allgemeiner Debugging-Prompt springt oft direkt zu Codeänderungen. Der fix skill erzwingt eine bessere Reihenfolge: zuerst reproduzieren, bei verschwundenem Fehler per Burn-in prüfen, Traces erfassen und erst dann Symptome Kategorien zuordnen. Die begleitende Datei flaky-taxonomy.md liefert konkrete Diagnosezweige und Fix-Muster, unter anderem für fehlendes await, gemeinsam genutzten Zustand, CI-spezifische Unterschiede bei Viewport/Fonts/Timezone, Browser-Crashes und Worker-bedingte Instabilität.
Wichtige Einschränkungen vor der Installation
Dies ist kein universeller Bug-Fixer. Der Skill ist auf Playwright-Tests zugeschnitten und setzt voraus, dass der Agent Ihre Testdatei prüfen, Playwright-Befehle ausführen und Ausgaben wie Traces, Screenshots, Logs oder CI-Fehlertexte lesen kann. Es gibt keine Hilfsskripte; der Nutzen entsteht aus Workflow und Taxonomie, nicht aus Automatisierung.
So verwenden Sie den fix skill
fix installieren und zuerst diese Dateien prüfen
Installieren Sie den Skill in einer kompatiblen Skills-Umgebung mit:
npx skills add alirezarezvani/claude-skills --skill fix
Lesen Sie nach der Installation zuerst SKILL.md für den Ausführungs-Workflow und öffnen Sie danach flaky-taxonomy.md für den Entscheidungsbaum und häufige Fixes. Der Repository-Pfad lautet engineering-team/playwright-pro/skills/fix. Die relevanten Quelldateien sind bewusst klein gehalten: Es gibt keine versteckten Skripte, Regeln oder Metadatendateien, die konfiguriert werden müssten.
Welche Eingaben der fix skill benötigt
Für die besten Ergebnisse liefern Sie mindestens eine der folgenden Angaben:
- Testdateipfad, zum Beispiel
e2e/login.spec.ts - Exakter Testname oder
--grep-String - Fehlermeldung, Stacktrace oder Assertion-Fehler
- Ob der Fehler lokal, in CI oder in beiden Umgebungen auftritt
- Ob der Test einzeln besteht, aber in der gesamten Suite fehlschlägt
- Trace-, Screenshot-, Video- oder CI-Artefaktpfad, falls vorhanden
- Relevante Playwright-Konfiguration, insbesondere workers, retries, projects, viewport, timezone und base URL
Schwacher Prompt: „Fix my flaky checkout test.“
Stärkerer Prompt: „Use the fix skill for Debugging e2e/checkout.spec.ts, test should submit paid order. It passes locally alone, fails in CI about 30% of runs, and the failure is Timeout 5000ms exceeded waiting for getByRole('button', { name: 'Pay' }). CI uses 4 workers and retries=2. Suggest the reproduction commands, likely category, and minimal code/config changes.“
Praktischer Workflow mit dem fix skill
Beginnen Sie mit der exakt fehlgeschlagenen Datei:
npx playwright test <file> --reporter=list
Wenn sie besteht, behandeln Sie den Fall als potenziell flaky und führen Sie einen Burn-in aus:
npx playwright test <file> --repeat-each=10 --reporter=list
Wenn das Problem nur bei Nebenläufigkeit auftritt, testen Sie mit Parallelisierung:
npx playwright test --fully-parallel --workers=4 --repeat-each=5
Erfassen Sie anschließend Trace-Belege:
npx playwright test <file> --trace=on --retries=0
Bitten Sie den Agent, den Fehler vor jeder Codeänderung zu klassifizieren. Die erwarteten Kategorien sind Timing/Async, Testisolation, Umgebung oder Infrastruktur. So vermeiden Sie typische schlechte Fixes wie willkürliches waitForTimeout, das Erhöhen globaler Timeouts oder das Verstecken einer echten Race Condition hinter retries.
Prompt-Muster für bessere Ergebnisse
Verwenden Sie einen Prompt, der Belege und Anfrage klar trennt:
„Use the fix skill. Diagnose before changing code. Test: <file> / <test name>. Reproduction result: <passes/fails command>. CI/local behavior: <details>. Trace or screenshot: <path or summary>. Current suspicion: <optional>. Please categorize using flaky-taxonomy.md, explain the evidence, propose the smallest safe fix, and list the command to verify it.“
Diese Struktur hilft dem Skill, einen überprüfbaren Debugging-Plan zu erstellen, statt einen spekulativen Patch vorzuschlagen.
FAQ zum fix skill
Ist fix nur für flaky Tests gedacht?
Nein. Der fix skill behandelt sowohl dauerhaft fehlschlagende Playwright-Tests als auch intermittierende Fehler. Bei deterministischen Fehlern beginnt er trotzdem mit Reproduktion und Trace-Erfassung. Bei intermittierenden Fehlern ergänzt er Burn-in- und Parallel-Worker-Prüfungen, um Muster bei Timing, Isolation oder Infrastruktur sichtbar zu machen.
Wann sollte ich diesen Skill nicht verwenden?
Verwenden Sie ihn nicht als Hauptwerkzeug für Unit-Tests, Backend-Integrationstests, Produktionsfehler ohne Playwright-Abdeckung oder breit angelegtes Debugging der Anwendungsarchitektur. Er kann zwar allgemeine Ideen liefern, aber seine Befehle, Taxonomie und Beispiele sind für Playwright-End-to-End-Tests geschrieben.
Wie unterscheidet er sich vom Playwright trace viewer allein?
Der trace viewer zeigt, was passiert ist; der fix skill hilft zu entscheiden, was der Trace bedeutet. Ein fehlendes Element kann zum Beispiel auf eine Async Race Condition, geleakten Zustand aus einem vorherigen Test, einen CI-Viewport-Unterschied oder eine Netzwerkabhängigkeit hindeuten. Die Taxonomie verwandelt Artefakte in einen Diagnosepfad und einen passenden Fix-Typ.
Ist fix einsteigerfreundlich?
Ja, sofern die Nutzer Playwright-Befehle ausführen und Fehler teilen können. Einsteiger profitieren von der klaren Befehlsfolge und der Kategorietabelle. Der Skill ersetzt jedoch kein grundlegendes Projekt-Setup-Wissen: Playwright muss bereits installiert sein, die Testsuite muss ausführbar sein und Artefakte müssen zugänglich sein.
So verbessern Sie den fix skill
Liefern Sie dem fix skill bessere Fehlerbelege
Die wichtigste Verbesserung ist eine höhere Eingabequalität. Geben Sie exakt an, welche Befehle bereits ausgeführt wurden und mit welchem Ergebnis. „Fails in CI“ ist weniger hilfreich als „fails in CI with 4 workers, passes locally with one worker, fails locally with --fully-parallel --workers=4 --repeat-each=5.“ Dieses eine Detail weist eher auf Isolation oder Parallelisierung hin als auf generisches Timing.
Vermeiden Sie typische Debugging-Fehlwege
Fordern Sie keinen Patch an, bevor eine Diagnose vorliegt. Häufige schlechte Ergebnisse sind feste Sleeps, höhere globale Timeouts, mehr retries oder umgeschriebene Selektoren, ohne die Ursache zu bestätigen. Bitten Sie den Skill, vor Codeänderungen Kategorie, Belege, minimalen Fix und Verifikationsbefehl zu nennen.
Iterieren Sie nach dem ersten Fix
Führen Sie nach einer vorgeschlagenen Änderung den kleinsten sinnvollen Verifikationsbefehl erneut aus. Wenn der Fix auf Timing zielte, nutzen Sie Burn-in. Wenn er Testisolation adressierte, vergleichen Sie Einzeltest- mit Suite-Verhalten. Wenn er die CI-Umgebung betraf, reproduzieren Sie mit CI-näheren Einstellungen wie Docker, workers, timezone, viewport oder gemockten Netzwerkdiensten.
Erweitern Sie den fix-Leitfaden für Ihr Projekt
Teams können lokale Ergebnisse verbessern, indem sie projektspezifische Hinweise direkt beim Skill-Workflow ergänzen: typische CI-Einstellungen, bekannte flaky Services, erforderliche Testdaten-Resets, Standard-Fixtures, Mock-Strategie und bevorzugte Locator-Konventionen. Der fix skill funktioniert am besten, wenn seine Taxonomie mit den tatsächlichen Fehlermustern Ihres Repository kombiniert wird.