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.
| Frage | Vergleichsachse | Aufgabe des Dokuments |
|---|---|---|
| Was hat sich geändert? | Vorheriger Code <-> Aktueller Code | Zeige zwei Screenshots nebeneinander, um die Verbesserung zu belegen |
| Wurde die Spezifikation umgesetzt? Was fehlt noch? | Spezifikation, Lastenheft <-> Aktueller Bildschirm | Kennzeichne jeden Punkt mit einer Bewertung und zeige nur die Abweichungen |
| Entspricht es unseren Prinzipien? | Prinzipien, Checkliste <-> Aktuelles Produkt | Gruppiere 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 Achse | Zeige den gesamten aktuellen Bildschirm |
| Was muss entschieden werden? | Option A <-> Option B | Paare 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
- 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
- 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 - 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
- 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
- Ü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
- 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
| Richtlinie | Wann greift sie? | Inhalt |
|---|---|---|
| Daten und Einstellungen nur lesen, zum Ändern um Erlaubnis fragen | Schritt 3 | Abfragen 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 vermerken | Schritt 3 · Schritt 6 | Spuren, 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 kann | Schritt 6 | Lokale 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 einholen | Schritt 6 | Frage zuerst, ob die Ausgabe (Slack, E-Mail, Kundenkommunikation) als Entwurf oder direkt gesendet werden soll |
Voraussetzungen
| Voraussetzung | Prüfung | Fehlt sie? |
|---|---|---|
| Die Arbeit ist auf dem Bildschirm sichtbar | Erscheint 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äuft | Antwortet 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ügbar | Läuft node scripts/shot.mjs mit Playwright? Jedes andere Tool, das JS auf der Seite ausführen kann, ist auch geeignet | Playwright-Installation und Screenshots mit anderen Tools siehe capture §Browser-Manipulation |
| Anmeldung ist möglich | Ist ein Login erforderlich? Gibt es ein Konto? | Siehe capture §Anmeldezustand herstellen |
| Python Pillow | python3 -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
- Kopiere
assets/web-report.htmlund fülle es alsindex.htmlim Berichtsordner. Gerüst und Kartenlayout siehe 60-output Gerüst. - Wenn der Empfänger etwas entscheiden muss, setze einen Entscheidungsblock direkt unter die zugehörige Begründungskarte. Wenn er auf
Kopierenin der Leiste klickt, werden die getroffenen Entscheidungen als Markdown gebündelt und können in den Chat eingefügt werden (60-output Entscheidungen einholen). - Öffne die drei Vorschaumodi: breiter Bildschirm, 390px Breite, und die Druckseiten aus
scripts/check_print.sh(60-output Bildschirm und Druck). - Binde mit
inline-images.pyalle relativen Bild- und Skript-Pfade in eine einzigereport.htmlein. 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
| Symptom | Ursache und Gegenmaßnahme |
|---|---|
| Der Entwicklungsserver stirbt sofort | next 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 nicht | Radix 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 überlappt | Das 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 Inhaltsverzeichnis | Fixierte Elemente wurden nicht entfernt. Fotografiere nur den relevanten Bereich oder schneide ihn zu |
| Tabellen oder Bilder ragen auf dem Handy aus dem Bildschirm | Die 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 Tabelle | Derselbe Text kommt mehrmals auf dem Bildschirm vor. Ändere nth, verwende exact oder einen präziseren Selektor |
| Der falsche Tab wird screenshotet | Eine andere Session teilt sich den Browser-Daemon. Isoliere die Session |
| Eine vorhandene Funktion wurde als nicht vorhanden beschrieben | Du 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 Bilder | Ein einfacher Server hat gleichzeitige Anfragen verpasst. Verwende inline-images.py, um alles in eine Datei zu bündeln |
| Bilder erscheinen zu klein im Frame | Sie wurden aufgrund einer Höhenbegrenzung skaliert. Lange, vertikale Bilder werden größer, wenn du sie in zwei Spalten nebeneinander anordnest |
| Die Änderung ist zu subtil | Du 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 lesbar | Wechsle 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änger | Wenn du einen neuen Abschnitt hinzufügst, entferne die Beschreibungen aus den bestehenden Abschnitten, die diesen Inhalt bereits abdecken |
Gemeinsame Mechanismen
| Skript | Was es tut | Ausgabe |
|---|---|---|
scripts/shot.mjs | Öffnet Bildschirme gemäß der Aufnahmeliste mit Playwright, zeichnet Markierungen und macht Screenshots. Lange Bildschirme werden in Teilen aufgenommen | PNG-Dateien im Ausgabeverzeichnis, je eine Zeile mit Markierungsergebnis |
scripts/mark.js | Findet 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ügt | Je eine Zeile mit Markierungsergebnis |
scripts/stitch.py | Fügt geteilte Teile zusammen und schneidet nach namensbasierten Koordinaten zu | PNG-Dateien im Ausgabeverzeichnis, je eine Zeile mit Größenangabe |
scripts/inline-images.py | Bettet relative Bildpfade und Skripte in das HTML ein, sodass eine einzelne Datei entsteht | report.html, Anzahl und Größe der eingebetteten Dateien |
assets/decisions.js | Speichert Entscheidungsblöcke; der Kopieren-Button in der unteren Leiste bündelt die getroffenen Entscheidungen als Markdown und kopiert sie | Fixierte Leiste, localStorage |
assets/compare.js | Fü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 deaktiviert | Vergleichsleiste, Differenz-Rate |
assets/report-nav.js | Baut 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 fortgesetzt | Linkes Inhaltsverzeichnis (bei schmalem Bildschirm als Schublade), localStorage |
scripts/serve-tailscale.sh | Exportiert 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.sh | Erzeugt vom Browserdruck inspiriertes A4-PDF in einem temporären Ordner | PDF-Pfad, Seitenzahl, PNG pro Seite |
scripts/grid_overlay.py · scripts/annotate.py | Legt Koordinatenraster auf Nicht-Browser-Bilder und zeichnet Boxen und Legenden | Annotiertes 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.