report

Überblick über den report skill

Was der report skill leistet

Der report skill ist ein auf Playwright ausgerichteter Workflow für Testberichte, der rohe Testergebnisse in einen klaren Statusbericht überführt. Er ist für Situationen gedacht, in denen ein Nutzer nach einem „test report“, „results summary“, „test status“, „show results“, „test dashboard“ oder „how did tests go“ fragt. Statt nur ein Terminal-Log zusammenzufassen, leitet der Skill den Agenten an, vorhandene Playwright-Ausgaben zu prüfen, bei Bedarf Tests auszuführen, JSON-Ergebnisse auszuwerten und einen nützlichen Bericht für den aktuellen Auslieferungs- oder Release-Kontext zu erstellen.

Besonders geeignet für Test-Automation-Teams

Dieser report skill passt am besten für Test-Automation Engineers, QA Leads, Entwickler mit Playwright sowie Agenten, die in Repositories arbeiten, in denen Testergebnisse schnell zusammengefasst werden müssen. Besonders sinnvoll ist er, wenn Teams bereits test-results/, playwright-report/, GitHub Actions, Slack webhooks oder TestRail-ähnliches Reporting verwenden. Seine Hauptaufgabe ist nicht das Erzeugen von Tests, sondern die Interpretation nach dem Lauf und die Bereitstellung des Teststatus.

Warum er nützlicher ist als ein allgemeiner Prompt

Ein allgemeiner Prompt wie „summarize my tests“ übersieht häufig, wo Playwright Ergebnisse ablegt, ob Tests erneut ausgeführt werden sollten und wohin der fertige Bericht gehört. Der report skill ergänzt konkrete Workflow-Entscheidungen: vorhandene Artefakte prüfen, Playwright mit JSON/HTML/list Reportern ausführen, wenn Ergebnisse fehlen, pass/fail/skip/flaky-Zahlen extrahieren, fehlgeschlagene Tests samt Meldungen identifizieren und ein Ziel auswählen, etwa Markdown, HTML-Bericht, CI-Artefakt, Slack oder TestRail, sofern die Umgebung das unterstützt.

Wichtige Hinweise zur Einführung

Der Upstream-Skill ist schlank: Im sichtbaren Repository-Pfad gibt es nur SKILL.md, ohne Helper-Skripte, Regeln, Referenzen oder mitgelieferte Assets. Das macht ihn leicht prüf- und anpassbar, bedeutet aber auch, dass Ihr Agent auf die lokale Playwright-Konfiguration und verfügbare Umgebungsvariablen angewiesen ist. Prüfen Sie vor der Installation, ob Ihr Projekt Playwright verwendet oder ob Sie den Workflow bewusst auf einen anderen JavaScript-Test-Runner übertragen möchten.

So verwenden Sie den report skill

Installationskontext für report

Installieren Sie den Skill aus dem Repository-Pfad, den das Verzeichnis verwendet:

npx skills add alirezarezvani/claude-skills --skill report

Prüfen Sie nach der Installation zuerst die Skill-Quelle:

engineering-team/playwright-pro/skills/report/SKILL.md

In der veröffentlichten Skill-Vorschau gibt es keine zusätzlichen Support-Ordner, daher ist SKILL.md die zentrale Arbeitsanleitung. Prüfen Sie in Ihrem eigenen Repository playwright.config.*, package.json, .github/workflows/, test-results/ und playwright-report/, um zu verstehen, wie Testausgaben erzeugt werden und wohin Berichte geleitet werden sollen.

Welche Eingaben der Skill braucht

Für eine zuverlässige Nutzung von report sollten Sie dem Agenten genug Kontext geben, damit er nicht raten muss:

• Ob die Tests bereits ausgeführt wurden
• Welcher Befehl normalerweise für Playwright-Tests verwendet wird
• Wo Ergebnisartefakte liegen, falls der Pfad nicht dem Standard entspricht
• Ob Retries aktiviert sind, weil flaky tests aus dem Retry-Verhalten abgeleitet werden
• Gewünschtes Ausgabeformat: Markdown, PR comment, Slack summary, TestRail push oder lokaler HTML report
• Umgebungsbeschränkungen, etwa „do not rerun tests“ oder „CI only“

Schwacher Prompt:

Make a test report.

Stärkerer Prompt:

Use the report skill for this Playwright project. Do not rerun tests unless no recent results exist. Check test-results/ and playwright-report/, parse JSON output if available, summarize passed/failed/skipped/flaky counts, list failed tests with error messages, and produce a Markdown report for the release channel.

Praktischer Workflow für report

Ein guter Workflow für einen report guide sieht so aus:

1. Vorhandene Artefakte mit ls -la test-results/ playwright-report/ 2>/dev/null prüfen.
2. Wenn kein nutzbares Ergebnis vorhanden ist und erneutes Ausführen erlaubt ist, ausführen:

   npx playwright test --reporter=json,html,list 2>&1 | tee test-output.log
   

3. JSON-Ausgabe auf Summen, Dauer, Fehlschläge, übersprungene Tests und Retries auswerten.
4. Ziele erkennen:
   • TESTRAIL_URL deutet darauf hin, dass eine Veröffentlichung in TestRail möglich sein kann.
   • SLACK_WEBHOOK_URL deutet darauf hin, dass eine Slack-Zusammenfassung gepostet werden kann.
   • .github/workflows/ deutet darauf hin, dass CI-/PR-Reporting relevant sein kann.
   • playwright-report/ deutet darauf hin, dass der HTML-Bericht geöffnet oder bereitgestellt werden kann.
5. Immer eine Markdown-Zusammenfassung erzeugen, sofern der Nutzer nicht ausdrücklich nur ein einzelnes Ziel verlangt.

Tipps für bessere Ausgabequalität

Sagen Sie dem Agenten, welche Entscheidung der Bericht unterstützen soll. Ein Release Manager braucht Risiken und Blocker; ein Entwickler braucht fehlgeschlagene Specs, Stack Traces und Reproduktionsbefehle; ein QA Lead benötigt möglicherweise Zahlen zu flaky tests und Trends bei der Laufzeit. Wenn der Bericht in einen PR eingefügt werden soll, verlangen Sie eine kompakte Zusammenfassung. Für eine Incident-Review bitten Sie um Gruppierung der Fehler nach Suite, Browser oder Fehlermuster.

FAQ zum report skill

Ist report nur für Playwright?

Der Skill ist auf Playwright-Befehle, -Ordner und -Reporter ausgelegt und daher am zuverlässigsten für Playwright Test Automation. Sie können seine Struktur auf Jest, Cypress oder andere Runner übertragen, müssen dann aber Befehle, Artefaktpfade und die Erkennung von flaky tests anpassen. Wenn Ihr Repository keine Testartefakte und kein Playwright-Setup hat, kann ein normaler Prompt ähnlich effektiv sein.

Führt report Tests automatisch aus?

Er kann den Agenten anleiten, Tests auszuführen, wenn keine aktuellen Ergebnisse gefunden werden, und dabei npx playwright test --reporter=json,html,list verwenden. Sie sollten jedoch klar angeben, ob erneute Läufe erlaubt sind. In großen Test-Suites können erneute Ausführungen langsam, teuer oder nach einem CI-Fehler ungeeignet sein, wenn die ursprüngliche Umgebung entscheidend ist.

Was erzeugt der report skill?

Die Standardausgabe ist ein Markdown-Testbericht mit Zahlen zu bestandenen, fehlgeschlagenen, übersprungenen und flaky tests, Gesamtdauer sowie Details zu fehlgeschlagenen Tests. Je nach Umgebung kann der Workflow Ergebnisse außerdem an TestRail, Slack, GitHub Actions artifacts oder PR comments weiterleiten oder den Playwright HTML report einbeziehen.

Wann sollte ich report nicht installieren?

Überspringen oder verschieben Sie die Installation, wenn Ihr Team kein Playwright verwendet, eine dedizierte Reporting-Plattform mit strikten APIs nutzt oder historische Analysen über einen einzelnen Testlauf hinaus benötigt. Dieser Skill ist ein kompakter Workflow-Prompt, kein vollständiger Reporting-Service, keine Datenbank, kein Dashboard und kein System für flaky-test management.

So verbessern Sie den report skill

report-Eingaben vor der Anfrage verbessern

Der schnellste Weg zu besseren report-Ergebnissen ist, die Ausführungsgrenzen klar zu benennen. Geben Sie Testbefehl, Artefaktpfade, Ziel, Zielgruppe und Rerun-Regel an. Zum Beispiel:

Generate a report for the CI Playwright run. Use existing artifacts only. Look in test-results/ and playwright-report/. Output a PR-ready Markdown summary with top failures, flaky tests, and whether the build should block merge.

So verhindern Sie, dass der Agent Zeit mit erneuten Testläufen verschwendet oder den falschen Detailgrad liefert.

Häufige Fehlermodi abfangen

Typische Probleme sind fehlende JSON-Ausgabe, veraltete Artefakte, sehr große Logs und uneindeutige Retries. Wenn JSON nicht verfügbar ist, bitten Sie den Agenten, auf test-output.log und Metadaten aus dem HTML-Bericht auszuweichen. Wenn Artefakte veraltet sein könnten, verlangen Sie Zeitstempelprüfungen. Wenn Logs zu groß sind, fordern Sie eine Gruppierung nach Titel des fehlgeschlagenen Tests und erster aussagekräftiger Fehlermeldung an, statt vollständige Stack Traces einzufügen.

report an den Team-Workflow anpassen

Da der Skill keine mitgelieferten Skripte enthält, entstehen teambezogene Verbesserungen meist durch lokale Konventionen. Dokumentieren Sie Ihre bevorzugte Berichtsvorlage, Slack-Kanalregeln, TestRail-Projektzuordnung, CI-Artefakt-URL-Muster und Severity-Labels. Verweisen Sie anschließend im Prompt auf diese Konventionen, damit der report skill Ausgaben erzeugt, die zu Ihrem Release-Prozess passen.

Nach dem ersten Bericht iterieren

Betrachten Sie den ersten Bericht als Entwurf. Stellen Sie Anschlussfragen wie:

• „Group failures by root cause.“
• „Separate product defects from test infrastructure failures.“
• „Add rerun recommendations for flaky tests.“
• „Make this suitable for a non-technical release update.“
• „Include exact commands to reproduce the failed specs.“

So bleibt der Bericht auf Entscheidungen ausgerichtet und nicht nur auf Zahlen.