AlemTuzlak/skills

Verwenden Sie dies, wenn der Benutzer /prove-it ausführt oder sagt „Beweise es“, „Beweise die Änderungen“, „Zeig mir im Browser“ oder eine Bestätigung einer UI- oder API-Änderung verlangt. Nicht verwenden, nur weil der Agent kurz davor ist, „fertig“ zu sagen, bei typenreiner Arbeit oder bei Dokumentation ohne nachweisbares Verhalten.

Was ist skills?

Diese AI-Agenten-Fähigkeit namens „Prove It“ dient dem Nachweis von UI- und API-Änderungen, indem sie die Änderungen so demonstriert, wie ein Benutzer sie tatsächlich nutzen würde. Sie ist für Agenten wie Claude Code, Cursor oder Codex geeignet und wird nur aktiv, wenn der Benutzer explizit dazu auffordert (z. B. durch den Befehl `/prove-it` oder die Aufforderung „Beweise es“). Die Fähigkeit unterscheidet streng zwischen UI-Nachweisen (die im Browser durch Klicken, Tippen, Absenden und Navigieren erfolgen) und Server-/API-Nachweisen (bei denen sie den Benutzer auffordert, eine geeignete Methode wie Curl, ein vorhandenes Beispiel oder ein Skript auszuwählen). Sie stellt sicher, dass nach dem Nachweis kein Server-Prozess unbeaufsichtigt läuft, und bietet optional die Möglichkeit, einen Screenshot-Bericht zu erstellen. Klare Regeln verhindern, dass ein unbewiesener Abschluss gemeldet wird, und behandeln Fehler wie fehlende Startbefehle oder fehlgeschlagene Nachweise transparent.

Funktioniert mit~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/AlemTuzlak/skills/tree/HEAD/skills/prove-it

Dokumentation

Beweise es

Beweise die Änderung so, wie ein Mensch sie verwendet. Behaupte nicht, dass sie funktioniert, ohne diesen Nachweis.

Diese Fähigkeit lädt nicht automatisch bei „fertig“. Der Benutzer muss danach fragen. Sie lädt keine anderen Fähigkeiten.

Wann verwenden

Aktivieren, wenn der Benutzer:

/prove-it ausführt
„Beweise es“, „Beweise die Änderungen“, „Zeig mir im Browser“ oder eine ähnliche Idee sagt (auch in der ersten Nachricht)

Überspringen, wenn er nicht danach gefragt hat. Überspringen bei typenreiner Arbeit, Kommentaren, Lock-Dateien, Dokumentation ohne Verhalten.

Harte Grenzen

Benutzer hat gefragt. Wenn er nicht um einen Nachweis gebeten hat, wird diese Fähigkeit nicht ausgeführt.
Sage nicht, dass es funktioniert, fertig ist oder repariert ist, es sei denn, diese Fähigkeit hat es tatsächlich bewiesen. Überspringen bedeutet nicht bewiesen.
Ein Screenshot eines einzelnen Bildschirms ist kein Beweis. Klicken, Tippen, Absenden, Navigieren.
Kein neues Paket, keine Abhängigkeit, keine Beispiel-App, kein Browser-Runner, es sei denn, der Benutzer hat diese Option ausgewählt und „Ja“ gesagt.
Stoppe jeden Server, den diese Fähigkeit gestartet hat, bevor die Fähigkeit endet. Lasse dev/preview nicht laufen.

UI vs. Server

UI (Seite, Komponente, Route, Formular, sichtbarer Zustand): Beweise im Browser.
Server / API / Bibliothek ohne Bildschirm: Frage, wie bewiesen werden soll. Wähle nicht stillschweigend.
Beides: Zeige die UI im Browser und frage, wie der Serverteil bewiesen werden soll.

Abläufe

Ablauf 1: Klassifizieren

Liste die Oberflächen auf: UI, Server/API oder beides.
UI → Ablauf 2.
Server/API → Ablauf 3.
Beides → Ablauf 2, dann Ablauf 3 für die API.

Ablauf 2: Browser (UI)

Wenn die App nicht läuft, starte nur einen vorhandenen Befehl (dev, preview, den dokumentierten Start des Repos). Wenn keiner existiert, sage, dass die UI nicht bewiesen werden kann. Biete Überspringen an, oder dass der Benutzer die App startet.
Nutze sie wie ein Benutzer:
- klicken, tippen, absenden, navigieren
- jede Route/Seite, die diesen Zustand teilt
- leere und Fehler-UI, wenn diese Änderung sie hat
- Desktop und ein schmales Viewport, wenn Layout oder CSS geändert wurden
Suche nach Brüchen, nicht nur nach dem Happy Path.
Sage im Chat, was du getan hast und was du gesehen hast. Sage nicht „sieht gut aus“ ohne Schritte.
Stoppe den Prozess aus Schritt 1, wenn diese Fähigkeit ihn gestartet hat.
Ablauf 4.

Ablauf 3: Fragen (Server / API)

Stoppe. Zeige 2–3 Optionen. Setze eine vernünftige erste Wahl an die erste Stelle. Nimm immer überspringen mit auf.
- vorhandenes Beispiel / Playground / Demo
- Beispiel-App, die die neue API verwendet (nur wenn sie Ort + neues Paket/Abhängigkeit bestätigen)
- Curl oder ein kleines Skript gegen einen laufenden Server
- überspringen
Warte. Baue oder führe nichts aus, bis sie gewählt haben.
Wenn überspringen: sage nicht bewiesen. Sage nicht, dass es funktioniert. Stoppe (kein Ablauf 4).
Wenn vorhandener Playground: führe ihn aus, dann beweise im Browser, wenn er eine UI hat, oder zeige die Befehlsausgabe, wenn es ein Skript ist.
Wenn Beispiel-App: frage nach dem Ort. Bevorzuge ein vorhandenes Beispiel. Füge kein Paket oder keine Abhängigkeit hinzu, es sei denn, sie haben Ja gesagt. Dann führe sie aus und beweise.
Wenn Curl/Skript: führe es aus. Zitiere den Exit-Code und den Teil der Ausgabe, der die Behauptung beweist.
Ablauf 4.

Ablauf 4: Optionaler Bericht

Frage nach einem echten Beweis: Soll ein Screenshot-Bericht geschrieben werden? Standard nein.
Wenn nein: stoppe. Der Chat enthält bereits den Beweis.
Wenn ja: schreibe .agent/scratch/prove-it.md (überschreiben). Füge .agent/scratch/ zur .gitignore hinzu, falls es fehlt (wie bei anderen Scratch-Dateien). Füge hinzu, was geklickt wurde, und die Aufnahmen. Öffne die Datei. Committe sie nicht.
Übersprungener Beweis → kein Bericht.

Ablauf 5: Stoppen

Nach Beweis oder Überspringen stoppen. Beginne keine nicht zusammenhängende Arbeit von dieser Fähigkeit.

Entscheidungsbaum

Benutzer hat nicht um einen Beweis gebeten → diese Fähigkeit gilt nicht.
UI → Ablauf 2 → 4 → 5.
Server/API → Ablauf 3 → 4 → 5 (Überspringen endet bei 3).
Beides → 2 dann 3, dann 4 → 5.
Kein Startbefehl und App läuft nicht → sage, dass UI nicht bewiesen werden kann. Überspringen oder Benutzer startet sie.
Benutzer sagt überspringen → nicht bewiesen. Keine Erfolgsbehauptung.

Rote Flaggen

Signal	Was es bedeutet	Stattdessen tun
„Fertig“ sagen, weil Tests bestanden sind	Diese Fähigkeit wurde nicht gefragt, oder Beweis wurde übersprungen	Nur als bewiesen bezeichnen nach Ablauf 2 oder 3.
Ein Screenshot, keine Klicks	Kein Benutzerpfad	Ablauf 2 Schritt 2.
Bauen von `examples/foo` bevor sie wählen	Ungefragte App	Ablauf 3. Warten.
Playwright / einen neuen Server hinzufügen	Neue Abhängigkeit	Nur vorhandenen Startbefehl verwenden.
`pnpm dev` laufen lassen	Watcher läuft weiter	Harte Grenze 5.
„Überspringen, aber es funktioniert“	Überspringen in Behauptung umgewandelt	Sage nicht bewiesen.
Berichtsdatei in `docs/`	Produktdokumentation	`.agent/scratch/prove-it.md`.
Bericht öffnen, wenn Nein gesagt wurde	Ungefragte Datei	Ablauf 4 Standard Nein.
Nur die Seite einer neuen öffentlichen API beweisen	Serverteil stillschweigend übersprungen	Ablauf 3 für die API.

Fehlerbehandlung

Keine Browser-Tools: sage, dass die UI hier nicht bewiesen werden kann. Biete Überspringen an, oder dass sie klicken, während du auf eine URL wartest. Tue keinen Screenshot vor.
Startbefehl schlägt fehl: zitiere den Fehler. Sage nicht, dass die UI funktioniert. Biete Überspringen oder eine Reparatur an, dann beweise erneut.
Beweis schlägt fehl (Klick macht das Falsche, Curl ist nicht 200): sage nicht bewiesen. Nenne, was fehlgeschlagen ist. Bezeichne es nicht als fertig.
Sie wählen Beispiel-App und lehnen ein neues Paket ab: verwende Curl, ein vorhandenes Beispiel oder überspringe. Füge das Paket trotzdem nicht hinzu.
Schreiben von Scratch-Dateien schlägt fehl: behalte den Beweis im Chat. Sage, dass die Berichtsdatei nicht geschrieben wurde.

Siehe nichts weiter. Der Chat ist der standardmäßige Beweis. Die Markdown-Datei ist optional.