CommunityCodierung & Entwicklunggithub.com

Beweisbericht (Evidence Report)

Erstellt eine einzige HTML-Seite, die eine konkrete Frage mithilfe von echten Screenshots und gespeicherten Werten beantwortet. Sie dient als visueller Beleg und ist für Mobilgeräte sowie den A4-PDF-Druck optimiert.

Was ist Beweisbericht (Evidence Report)?

Der Beweisbericht (Evidence Report) ist eine KI-Agent-Fertigkeit (Skill), die dazu dient, eine einzelne, klar formulierte Frage mit einem einzigen HTML-Dokument zu beantworten. Der Bericht basiert auf echten, live aufgenommenen Screenshots der Anwendung und den darin gespeicherten Werten – nicht auf Erinnerungen oder simulierten Zuständen. Dies gewährleistet, dass der Bericht unanfechtbare Beweise liefert. Der Skill unterstützt verschiedene Fragestellungen wie Vorher-Nachher-Vergleiche, Soll-Ist-Abgleiche, Audits, Zustandsvergleiche und Entscheidungsvorlagen. Die Nutzung ist insbesondere dann angezeigt, wenn eine große, sichtbare Funktion implementiert oder überarbeitet wurde. Der Skill priorisiert die visuelle Kommunikation über textlastige Aufzählungen. Empfänger, die keinen Code lesen, verstehen den Bericht schneller und können ihn auf dem Handy öffnen oder als A4-PDF drucken. Der Skill definiert einen klaren Workflow: Von der Definition der Frage und der Achse (Vergleichsachse) über die Erstellung einer Item-Liste mit Bewertungen, das Aufnehmen und Markieren von Screenshots bis hin zur finalen Ausgabe als optimiertes HTML. Der Skill enthält Mechanismen, um häufige Fallstricke wie falsche Logins, nicht sichtbare Elemente oder fehlerhafte Markierungen zu vermeiden.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/kimjisub/agent-skills/tree/HEAD/skills/evidence-report

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Beweisbericht

Auslöser - Wenn du einem anderen ein Ergebnis zeigen musst, es aber mit Worten nicht greifbar ist – und der Beweis ein echter Bildschirm ist. Wenn du eine große, sichtbare Funktion implementiert oder überarbeitet hast, beginne den Abschlussbericht hiermit, auch wenn du nicht dazu aufgefordert wurdest. Dokumente ohne Bildschirm und Flussdiagramme zwischen Dokumenten und Bildschirmen sind nicht Gegenstand dieses Skills.

Zweck

Erstelle ein Dokument, das eine einzige Frage mit echten Screenshots beantwortet. Der Empfänger liest weder Code noch Commit-Logs. Das Einzige, was er kennt, ist der Bildschirm; daher beruht die Glaubwürdigkeit des Dokuments vollständig darauf, dass die Screenshots tatsächlich von der laufenden Anwendung stammen. Zehn Stichpunkte mit denselben Erkenntnissen zu schreiben, ist weniger effektiv, als zwei Fotos nebeneinander zu stellen, die denselben Datensatz in zwei Zuständen zeigen. Wenn du eine große Funktion abgeschlossen hast und ohne diesen Bericht einfach "fertig" sagst, überträgst du die Kosten der manuellen Überprüfung auf den Empfänger.

Das Ergebnis ist eine einzige HTML-Seite. Der Empfänger öffnet sie auf seinem Handy oder erstellt ein PDF über den Browserdruck – daher muss die Vorlage sowohl für schmale Bildschirme als auch für den A4-Druck optimiert sein. Es werden weder PDF noch Markdown separat erstellt.

Dieser Skill hat kein festes Inhaltsverzeichnis. Zuerst legst du den einen Satz fest, den dieses Dokument beantwortet, und daraus ergeben sich die Vergleichsachse(n) und der Abschnittsaufbau.

FrageVergleichsachseAufgabe des Dokuments
Was hat sich geändert?Vorheriger Code <-> Aktueller CodeZeige zwei Screenshots nebeneinander, um die Verbesserung zu belegen
Wurde die Spezifikation umgesetzt? Was fehlt noch?Spezifikation, Lastenheft <-> Aktueller BildschirmKennzeichne jeden Punkt mit einer Bewertung und zeige nur die Abweichungen
Entspricht es unseren Prinzipien?Prinzipien, Checkliste <-> Aktuelles ProduktGruppiere die Funde nach Ursache, belege sie mit Screenshots und erkläre, was auf dem Bildschirm sichtbar ist
Was ändert sich, wenn sich die Bedingungen ändern?Zustand A <-> Zustand BÄndere Flags, Daten oder Berechtigungen tatsächlich und mache Screenshots
Wie ist der aktuelle Zustand?Keine AchseZeige den gesamten aktuellen Bildschirm
Was muss entschieden werden?Option A <-> Option BPaare zu jedem Punkt den aktuellen Bildschirm, die Optionen und die benötigten Eingaben

Normalerweise vermischen sich zwei oder mehr Achsen. Wenn du die Spezifikation prüfst, stößt du vielleicht auf "etwas, das nicht spezifiziert war, aber bereits existiert". Das ist ein Punkt mit einer anderen Achse und erfordert einen eigenen Abschnitt. Eine vage Frage führt zu einem vagen Dokument. Wenn du sie nicht in einem Satz formulieren kannst, teile das Dokument in zwei Teile.

Kernprinzipien

  1. Der Screenshot ist kein Reenactment, sondern das echte, laufende Ergebnis. Aus dem Gedächtnis zu schreiben, "wie es gewesen sein müsste", ist fast immer falsch. Der vorherige Bildschirm hatte vielleicht inzwischen gelöschte Elemente, oder das Problem war weniger oder schlimmer als erinnert. Auch "unter dieser Bedingung müsste es so aussehen" ist falsch. Wenn du das Flag tatsächlich aktivierst, siehst du möglicherweise ein anderes Bild als erwartet. Deshalb erzeugst du den anzuzeigenden Zustand und machst dann den Screenshot. So kannst du in das Dokument schreiben: "Dies ist das Ergebnis des tatsächlichen Betriebs, keine Simulation." Dieser eine Satz bestimmt die Glaubwürdigkeit des gesamten Dokuments. → Schritt 3
  2. Setze die Werte neben das Foto. Das Foto sagt nur: "So sieht es aus." Die gespeicherten Werte (data-* Attribute, Screenreader-Text) neben dem Bildschirmwert erklären auch, "warum es so aussieht". → Schritt 3
  3. Zeichne Markierungen innerhalb des Bildschirms. Wenn du Koordinaten per Augenmaß setzt, verschiebt sich fast immer eine ganze Zeile oder Spalte. Bei einem Browser-Bildschirm suchst du das Element per Text oder Selektor, zeichnest Rahmen und Nummern an Ort und Stelle und machst den Screenshot. → Schritt 4
  4. Erklärungen dürfen das Erklärte nicht verdecken. Wenn du ein Highlight-Label direkt auf den Bildschirm legst, verdeckt es fast immer etwas: Titel, Beschriftungen von Eingabefeldern, Werte in benachbarten Spalten. Setze auf das Bild nur Nummern und erkläre sie in der Bildunterschrift. Nummern-Badges sind klein und verursachen wenig Verlust, egal wo sie platziert sind. → Schritt 4
  5. Überprüfe das Erstellte immer mit eigenen Augen. Dass ein Tool "Erfolg" zurückgibt, bedeutet nur, dass die Datei geschrieben wurde. Ob der Rahmen am richtigen Element sitzt, das Badge den Inhalt verdeckt, in der Naht eine Kopfzeile wiederholt wird oder ein Bildlink kaputt ist, siehst du erst, wenn du es öffnest. → Schritt 5 und 6
  6. Trenne, was per Screenshot belegt ist und was nicht. Was du per Code bestätigt hast, aber aufgrund fehlender Daten im Bildschirm nicht zeigen kannst, kennzeichne separat als "(Code-Basis)". Wenn du beides vermischt, wird die Glaubwürdigkeit der Screenshots in Frage gestellt. → Schritt 1 und 3

Richtlinien

RichtlinieWann greift sie?Inhalt
Daten und Einstellungen nur lesen, zum Ändern um Erlaubnis fragenSchritt 3Abfragen zum Suchen von Fällen sind frei. Das Ändern der Entwicklungsdatenbank, um einen Fall zu erzeugen, erfolgt nur nach Bestätigung durch den Benutzer; die geänderten Werte werden notiert und zurückgesetzt. Die Produktionsdatenbank ist unter keinen Umständen Gegenstand
Während des Screenshots veränderte Dinge im Dokument und Bericht vermerkenSchritt 3 · Schritt 6Spuren, die während des Aufnahmevorgangs entstehen, wie Login-Session-Erstellung, Externer-Login-Zustimmung, Änderungen an der Entwicklungsdatenbank
In einer Form übergeben, die der Empfänger öffnen kannSchritt 6Lokale Pfade werden auf dem Gerät des Empfängers nicht geöffnet. Sende die report.html Datei oder erstelle einen Link. Wenn du einen Link erstellst, überprüfe, ob er tatsächlich geöffnet wird, bevor du ihn weitergibst
Vor dem Versenden nach außen Bestätigung einholenSchritt 6Frage zuerst, ob die Ausgabe (Slack, E-Mail, Kundenkommunikation) als Entwurf oder direkt gesendet werden soll

Voraussetzungen

VoraussetzungPrüfungFehlt sie?
Die Arbeit ist auf dem Bildschirm sichtbarErscheint die Änderung auf dem Bildschirm, den der Benutzer sieht?Wenn es sich um eine reine Backend- oder Skript-Änderung handelt, ist dies nicht Gegenstand. Berichte mit Text
Das zu screenshotende Produkt läuftAntwortet der lokale Entwicklungs- oder Staging-Server?Das Starten erfolgt gemäß der Dokumentation des Repos. Vorheriger Code siehe axes §Zeitachse
Es ist ein Browser-Tool verfügbarLäuft node scripts/shot.mjs mit Playwright? Jedes andere Tool, das JS auf der Seite ausführen kann, ist auch geeignetPlaywright-Installation und Screenshots mit anderen Tools siehe capture §Browser-Manipulation
Anmeldung ist möglichIst ein Login erforderlich? Gibt es ein Konto?Siehe capture §Anmeldezustand herstellen
Python Pillowpython3 -c "import PIL"Zusammenfügen und Zuschneiden sind nicht möglich

Ablauf

0. Frage und Achse     READ <- variants/axes - Je nach Achse sind die Vorbereitungen unterschiedlich (Code zurücksetzen, Daten ändern, Dokumente lesen, Fälle suchen). Nur die Abschnitte der gewählten Achse
1. Punkte und Bewertung   (Bei der Prüfachse erzeugen axes §Prüfachse 1–2 die Punkte)
2. Struktur          READ <- steps/20-document - Kriterien zum Gruppieren von Punkten in Abschnitte, Bewertungsvokabular, Zusammenfassung, Platz für Abbildungen und Tabellen
3. Screenshot        READ <- steps/30-capture - Hürden bei Anmeldung, synthetischen Events, langen Bildschirmen, Auslesen von Bildschirmwerten
4. Markierung        READ <- steps/30-capture §Markierungen innerhalb des Bildschirms - Bei Koordinaten per Augenmaß verschiebt sich um eine Spalte
5. Bildprüfung       (Kein separates Dokument. Die Checkliste ist in Schritt 5 enthalten)
6. Ausgabe           READ <- steps/60-output - Wenn die Vorlage zerstört wird, brechen schmale Bildschirme und Druck zusammen. Wenn die Entscheidungsblock-Regeln verletzt werden, wird der kopierte Block abgeschnitten

Schritt 0: Frage und Achse

Formuliere einen Satz. Er muss den Empfänger und den Zweck enthalten, z. B.: "Ich erkläre dem Kunden, was diese Woche geändert wurde" oder "Ich lege mit dem Produktmanager fest, was von der Spezifikation noch fehlt". Ist der Zweck ein anderer, unterscheidet sich der Fokus, selbst beim gleichen Bildschirm. Wähle dann die Achse aus der Tabelle im Zweck-Abschnitt und lies den entsprechenden Abschnitt in axes.

Danach stehen fest: ein Satz (die Frage), die Achse und der Empfänger.

Schritt 1: Punkte und Bewertung

Beginne nicht mit dem Screenshot. Schreibe die Punkte auf, die in diesem Dokument behandelt werden, und füge jedem einen Referenzcode und eine Bewertung hinzu. Diese Liste ist das Rückgrat des Dokuments; die zu screenshotenden Bildschirme und die Markierungspunkte werden hier festgelegt.

Referenzcodes trennen Punkte unterschiedlicher Art, da das Interesse des Empfängers verschieden ist.

  • Aufgetragene Arbeit: R-1, R-2 … (Der Empfänger fragt sich: Ist es erledigt?)
  • Nebenbei gefundene und mitkorrigierte Fehler: A-1, A-2 … (Der Empfänger fragt sich: Warum hast du das angefasst?)
  • Abweichungen von der Spezifikation: G-1, G-2 … (Der Empfänger fragt sich: Was machen wir jetzt damit?)
  • Prüf-Funde: Folgen der Gruppennummer 1-1, 1-2 … (Punkte mit derselben Ursache)

Das Bewertungsvokabular ist im gesamten Dokument einheitlich (Beispiele siehe document §Bewertungsvokabular). Zähle die Bewertungen und setze sie auf die erste Seite. Ein Satz wie "35 implementiert, 3 benötigen Entscheidung, 1 Fehler" ersetzt das gesamte Dokument. Beim Zählen werden auch Lücken in der Liste sichtbar.

Es ist leicht, während der Arbeit korrigierte Dinge zu übersehen. Fülle die Liste daher mit git log (für Änderungen) oder durch zeilenweises Durchgehen des Originals (für Spezifikationsvergleiche). Markiere gleichzeitig, ob ein Punkt auf dem Bildschirm sichtbar ist (ob der Fall in den Daten existiert). → Kernprinzip 6

Danach hat jeder Punkt einen Code, eine Bewertung und den zu screenshotenden Bildschirm oder den Vermerk "(Code-Basis)".

Schritt 2: Struktur

Abschnitte werden nicht aus einem Inhaltsverzeichnis ausgewählt, sondern entstehen, wenn du Punkte gruppierst. Es gibt vier Gruppierungskriterien.

  • Nach Bildschirm – Wenn viele Punkte auf einem Bildschirm konzentriert sind. Standard für Verbesserungsberichte.
  • Nach Bewertung – Wenn die Bewertungen auseinandergehen. Standard für Vergleichsberichte; der Empfänger sieht zuerst die "zu entscheidenden" Punkte.
  • Nach Ursache – Bei vielen, über mehrere Bildschirme verstreuten Funden. Standard für Prüfberichte.
  • Nach Punkt – Wenn jeder Punkt eine eigenständige Entscheidung ist. Standard für Entscheidungsvorlagen.

Unabhängig von der Gruppierung steht am Anfang eine ein- bis zweiseitige Zusammenfassung, die das Ganze erklärt, und danach wird es detaillierter. Gehe davon aus, dass der Empfänger von oben nach unten liest und jederzeit aufhört. Die Anzahl der Abschnitte richtet sich nach dem, was gezeigt werden soll. Fülle keine Abschnitte künstlich, erstelle keine leeren Abschnitte. Die konkrete Methode zur Strukturierung und Beispiele findest du in document.

Schritt 3: Screenshot

Die Vorbereitung variiert je nach Achse (axes). Hier stehen nur die allgemeinen Regeln.

  • Gleicher Viewport, gleiche Scrollposition, gleicher Ausschnitt für Paare, die übereinandergelegt werden sollen. Nur so passen zwei Bilder pixelgenau und können mit einem Schieberegler oder als Differenz betrachtet werden (60-output §Übereinanderlegen).
  • Vergleichsbildschirme verwenden dieselben Daten. Bei unterschiedlichen Daten ist kein Vergleich möglich. Wenn du zeigen willst, dass derselbe Fakt auf verschiedenen Bildschirmen anders dargestellt wird, mache Screenshots von allen Bildschirmen mit demselben Datensatz.
  • Prüfe vor dem Screenshot per Abfrage, ob die für die Funktion benötigten Daten tatsächlich existieren. Wenn du später feststellst, dass der Bildschirm leer war, musst du den gesamten Stack neu aufbauen.
  • Prüfe den Anmeldezustand und mache dann den Screenshot. Es kommt tatsächlich vor, dass jemand ein Element, das nur nach Anmeldung sichtbar ist, im abgemeldeten Zustand fotografiert und "nicht vorhanden" schreibt. Bevor du "nicht vorhanden" entscheidest, trenne: Ist es wirklich nicht da, oder ist es nur in dieser Session nicht sichtbar?
  • Führe die Manipulationen in derselben Reihenfolge aus. Erstelle eine Aufnahmeliste in einer Datei; wenn du die Screenshots wiederholen musst, führe nur diese Datei aus.
  • Wähle einen großzügigen Viewport. Wenn der untere Bereich abgeschnitten ist, musst du erneut screenshoten.
  • Lies gleichzeitig die gespeicherten Werte und die Bildschirmwerte aus. → Kernprinzip 2
  • Notiere gleichzeitig, wie du zu diesem Bildschirm gekommen bist. Um den Pfad und die Schrittzahl später nachvollziehen zu können, müsstest du sonst erneut navigieren. Das Notieren während des Screenshots ist kostenlos (document §Position und Tiefe des Bildschirms).

Bei häufig auftretenden Hürden in der Manipulation siehe capture.

Schritt 4: Markierung

Für Browser-Bildschirme zeichnest du beim Screenshot mit scripts/shot.mjs Rahmen und Nummern auf dem Bildschirm (→ capture §Markierungen innerhalb des Bildschirms). Lange Bildschirme werden in Teilen aufgenommen und mit scripts/stitch.py zusammengefügt; nicht zum Thema gehörende Teile (wie Sidebars) werden mit demselben Skript beschnitten. Für Nicht-Browser-Bildschirme liest du mit grid_overlay.py die Koordinaten aus und zeichnest mit annotate.py.

  • Der Rahmen soll nur das hervorzuhebende Element umschließen. Ein zu weit gefasster Rahmen macht unklar, worauf du aufmerksam machen willst.
  • Farben sind einheitlich nach Bewertung. Bereits beim überfliegenden Betrachten soll die Farbe den Charakter verraten. Rot für den Zustand vor der Verbesserung und Problemstellen, Grün für den Zustand nach der Verbesserung. Bei Vergleichsberichten: Rot für Fehlendes, Grün für Vorhandenes, Orange für Entscheidungsbedarf.
  • Die Markierungen für zwei zu vergleichende Bildschirme werden jeweils separat gesucht. Unterschiedliche Textlängen führen zu minimalen Layout-Verschiebungen.
  • Sammle alle Aufnahmen und Markierungen in einer Datei. Änderungen an der Markierung erfordern dann eine erneute Ausführung der gesamten Datei; auch wenn du später die Screenshots wiederholen musst, führst du nur diese Datei aus.

Schritt 5: Bildprüfung

Öffne alle Bilder mit einem Anzeigeprogramm. Prüfe:

  • Enthält die Ausgabezeile der Markierung kein NOT FOUND?
  • Umschließt der Rahmen das hervorzuhebende Element genau? Hat er nicht versehentlich eine andere Stelle mit demselben Text erwischt (z. B. denselben Spaltennamen in einer anderen Tabelle)?
  • Verdeckt das Nummern-Badge keinen Text oder Balken?
  • Wiederholt sich in der Naht keine Kopfzeile oder kein Inhaltsverzeichnis?
  • Ist der obere Rand des zugeschnittenen Bildes nicht halb abgeschnitten? Ist das Seitenverhältnis der beiden nebeneinander zu legenden Bilder nicht extrem unterschiedlich?
  • Ist das, was du als "nicht vorhanden" beschrieben hast, wirklich nicht auf dem Bildschirm? Wenn es aufgrund des Anmeldezustands oder einer Bedingung nicht sichtbar ist, musst du die Bewertung umkehren.
  • Stimmt die Bildunterschrift mit dem überein, was das Bild zeigt? Hast du in einem schmalen Bild eine versteckte Spalte versehentlich als "dreimal wiederholt" beschrieben?

Korrigiere gefundene Fehler und prüfe erneut. Ein einziger Durchlauf ist selten ausreichend.

Schritt 6: HTML und Auslieferung

  1. Kopiere assets/web-report.html und fülle es als index.html im Berichtsordner. Gerüst und Kartenlayout siehe 60-output Gerüst.
  2. Wenn der Empfänger etwas entscheiden muss, setze einen Entscheidungsblock direkt unter die zugehörige Begründungskarte. Wenn er auf Kopieren in der Leiste klickt, werden die getroffenen Entscheidungen als Markdown gebündelt und können in den Chat eingefügt werden (60-output Entscheidungen einholen).
  3. Öffne die drei Vorschaumodi: breiter Bildschirm, 390px Breite, und die Druckseiten aus scripts/check_print.sh (60-output Bildschirm und Druck).
  4. Binde mit inline-images.py alle relativen Bild- und Skript-Pfade in eine einzige report.html ein. Sende die Datei direkt oder exportiere sie als Link; öffne sie dann genau so, wie der Empfänger sie öffnen wird, und überprüfe sie (60-output Übergeben).

Ändere das <style> der Vorlage nicht pro Bericht. Wenn du Breiten in px setzt oder Tabellen außerhalb von .tw platzierst, zerbricht der schmale Bildschirm. → Kernprinzip 5

Danach existiert die report.html, sie funktioniert in allen drei Vorschaumodi, sie wird in der vom Empfänger verwendeten Art geöffnet, und das Versenden wartet auf die Bestätigung durch den Benutzer.

Häufige Stolperfallen

SymptomUrsache und Gegenmaßnahme
Der Entwicklungsserver stirbt sofortnext dev liest stdin. Mit < /dev/null wird sofort EOF erreicht und der Server beendet sich normal. Halte stdin mit `tail -f /dev/null
Popover oder Dropdown öffnen sich nichtRadix etc. reagieren nicht auf synthetische Events. Verwende statt dispatchEvent die echte click-Methode des Automatisierungstools
Der Ganzseiten-Screenshot wiederholt denselben Bildschirm oder der fixierte Header überlapptDas Tool kann bei Ganzseiten-Screenshots das Fenster oder innere Boxen nicht weit genug scrollen. Verwende full von shot.mjs, teile den Screenshot in Teile und füge sie zusammen
Im zusammengesetzten Foto wiederholt sich das InhaltsverzeichnisFixierte Elemente wurden nicht entfernt. Fotografiere nur den relevanten Bereich oder schneide ihn zu
Tabellen oder Bilder ragen auf dem Handy aus dem BildschirmDie Tabelle wurde nicht mit .tw umschlossen, oder es wurden inline-style-Angaben mit px-Breiten verwendet. Verwende nur Klassen der Vorlage
Die Markierung zeigt auf die falsche TabelleDerselbe Text kommt mehrmals auf dem Bildschirm vor. Ändere nth, verwende exact oder einen präziseren Selektor
Der falsche Tab wird screenshotetEine andere Session teilt sich den Browser-Daemon. Isoliere die Session
Eine vorhandene Funktion wurde als nicht vorhanden beschriebenDu hast sie im abgemeldeten Zustand oder bei unpassenden Bedingungen screenshotet. Überprüfe vor der Bewertung Anmeldung und Bedingungen
Beim Öffnen über einen Link fehlen einige BilderEin einfacher Server hat gleichzeitige Anfragen verpasst. Verwende inline-images.py, um alles in eine Datei zu bündeln
Bilder erscheinen zu klein im FrameSie wurden aufgrund einer Höhenbegrenzung skaliert. Lange, vertikale Bilder werden größer, wenn du sie in zwei Spalten nebeneinander anordnest
Die Änderung ist zu subtilDu hast die falsche Vergleichsbasis gewählt. Statt eine geänderte Spaltenüberschrift in einer Liste zu zeigen, ist es besser, den tatsächlichen Bearbeitungsbildschirm für diesen Wert zu zeigen
Die Tabelle ist zu dicht und schwer lesbarWechsle zu einer Listenansicht: Label links, Inhalt rechts. Bei Gruppen setze das Gruppenlabel nur einmal ganz links in die Zeile
Das Dokument wird beim Bearbeiten nur längerWenn du einen neuen Abschnitt hinzufügst, entferne die Beschreibungen aus den bestehenden Abschnitten, die diesen Inhalt bereits abdecken

Gemeinsame Mechanismen

SkriptWas es tutAusgabe
scripts/shot.mjsÖffnet Bildschirme gemäß der Aufnahmeliste mit Playwright, zeichnet Markierungen und macht Screenshots. Lange Bildschirme werden in Teilen aufgenommenPNG-Dateien im Ausgabeverzeichnis, je eine Zeile mit Markierungsergebnis
scripts/mark.jsFindet Elemente auf der Seite per Text oder Selektor und zeichnet Rahmen und Nummern. Wird von shot.mjs verwendet; bei anderen Browser-Tools per eval eingefügtJe eine Zeile mit Markierungsergebnis
scripts/stitch.pyFügt geteilte Teile zusammen und schneidet nach namensbasierten Koordinaten zuPNG-Dateien im Ausgabeverzeichnis, je eine Zeile mit Größenangabe
scripts/inline-images.pyBettet relative Bildpfade und Skripte in das HTML ein, sodass eine einzelne Datei entstehtreport.html, Anzahl und Größe der eingebetteten Dateien
assets/decisions.jsSpeichert Entscheidungsblöcke; der Kopieren-Button in der unteren Leiste bündelt die getroffenen Entscheidungen als Markdown und kopiert sieFixierte Leiste, localStorage
assets/compare.jsFügt über .pair[data-compare] nebeneinander, Schieberegler und Differenz-Leiste hinzu. Der Modus ist ein globaler Zustand, Standard ist Schieberegler. Wenn die Pixelgrößen der beiden Bilder unterschiedlich sind, wird die Überlagerung deaktiviertVergleichsleiste, Differenz-Rate
assets/report-nav.jsBaut aus h2/h3 ein linkes Inhaltsverzeichnis auf und zeigt Umfang (Abschnitte · Fotos · Entscheidungen · Lesezeit), gelesene Abschnitte, verbleibende Entscheidungen und aktuelle Position an. Beim erneuten Öffnen wird die Leseposition fortgesetztLinkes Inhaltsverzeichnis (bei schmalem Bildschirm als Schublade), localStorage
scripts/serve-tailscale.shExportiert den Ordner unter einer HTTPS-Adresse im Tailnet und prüft die Antwort (optional, nur mit Tailscale)URL, PID, Befehl zum Herunterfahren
scripts/check_print.shErzeugt vom Browserdruck inspiriertes A4-PDF in einem temporären OrdnerPDF-Pfad, Seitenzahl, PNG pro Seite
scripts/grid_overlay.py · scripts/annotate.pyLegt Koordinatenraster auf Nicht-Browser-Bilder und zeichnet Boxen und LegendenAnnotiertes Bild

Verwendung und Hinweise stehen in den Kopfkommentaren der jeweiligen Skripte.

Ergebnis

Ein Berichtsordner (<Datum>-<Thema>/): index.html zum Bearbeiten, images/ (Originale in images/raw/), Aufnahmeliste und Koordinatendateien, report.html für die Weitergabe (eine Datei mit eingebetteten Bildern). Bei der Übergabe nenne den Link, die während des Screenshots geänderten Dinge und die nicht auf dem Bildschirm sichtbaren Punkte.

Position im Skill-Ökosystem

  • Browser-Tools – Dieser Skill beschreibt, wie du mit einem ausgewählten Tool was und wie screenshotest und in das Dokument einfügst. Wenn die Umgebung eigene Regeln für die Tool-Auswahl und Session-Isolierung hat, befolge diese.
  • Dokument-Skills – Bildschirmlose Berichte, Vorschläge und Folien sind nicht Gegenstand dieses Skills, sondern gehören zu allgemeinen Dokument-Skills.
  • Textverfeinerung – Wenn die Umgebung eigene Kriterien für die Verfeinerung von Berichtssätzen und Bildschirmkomposition hat, verwende diese. Bei der Prüfachse können diese Kriterien auch als Quelle für Prinzipien dienen.

Verwandte Skills