KI-News · Werkzeuge
/prototype von Matt Pocock:
Wegwerf-Code gegen eine echte Frage.
EN Read in English
/prototype soll eine Design- oder Zustandsfrage nicht diskutieren, sondern durch
kurzen, bewusst wegwerfbaren Code beantworten. Auch dieser Skill stammt aus Matt Pococks
Sammlung, wie schon /handoff.
Statt einer erfundenen Aufgabe habe ich mir echten PlantWiz-Code angesehen, bis eine echte,
ungeklärte Zustandsfrage auftauchte, und genau dort /prototype ausgelöst.
skills/engineering/prototype.
Getestet in einem isolierten Git-Worktree von PlantWiz, einer produktiven Vue-3-Anwendung mit
Node-Backend, damit die laufende Arbeit im eigentlichen Repository unberührt bleibt. Die Frage
war real und noch offen, nicht für diesen Beitrag konstruiert. Ein Durchlauf, von mir selbst
ausgeführt und bewertet.
Was der Skill genau vorschreibt
Die Idee hinter /prototype steht direkt im ersten Satz der Skill-Datei: „A
prototype is throwaway code that answers a question. The question decides the shape.“ Anders als
/handoff hat die Datei kein disable-model-invocation: true im
Frontmatter, der Agent darf sich also theoretisch auch von selbst dazuschalten, wenn eine
Design-Frage im Gespräch auftaucht. In der Praxis bleibt das eine Randnotiz, weil die
Beschreibung im Frontmatter eng gefasst ist: „sanity-check whether a state model or logic feels
right, or explore what a UI should look like“.
Bevor überhaupt Code entsteht, verzweigt der Skill in genau zwei Richtungen. Die Hauptdatei
SKILL.md enthält dafür keine Details selbst, sondern verweist auf zwei separate
Dateien im selben Ordner, LOGIC.md und UI.md, die jeweils den
kompletten Ablauf für ihren Zweig vorschreiben:
- LOGIC-Zweig (
LOGIC.md) für „fühlt sich dieses Statemodell richtig an?“: eine einzelne, selbstständige HTML-Datei mit Buttons, die eine State-Machine oder einen Reducer durch schwer im Kopf durchdenkbare Fälle schickt. Gedacht dafür, dass auch eine fachfremde Person (Designer, PM, Domänenexperte) sie anklicken kann. - UI-Zweig (
UI.md) für „wie soll das aussehen?“: mehrere strukturell unterschiedliche Layout-Varianten auf derselben Route, umschaltbar über einen?variant=-Parameter und eine schwebende Leiste unten, mit Pfeiltasten-Navigation.
Für beide Zweige gelten dieselben sechs Regeln, wörtlich aus der Skill-Datei zusammengefasst:
- Wegwerfbar von Tag eins an, aber klar als solches benannt, und in der Nähe des Codes platziert, den es betrifft.
- Trivial startbar: ein Befehl für UI-Prototypen, ein Doppelklick für die HTML-Logikdemo.
- Keine Persistenz per Default. Zustand lebt im Speicher, außer die Frage betrifft explizit Persistenz.
- Kein Politur. Keine Tests, keine Fehlerbehandlung über das Lauffähige hinaus, keine Abstraktionen.
- Zustand sichtbar machen, nach jeder Aktion oder jedem Varianten-Wechsel.
- Festhalten, wenn fertig: validierte Entscheidung in den echten Code übernehmen, den Prototyp selbst auf einen Wegwerf-Branch außerhalb von main committen, mit Verweis darauf im Ticket. Main behält nur die Entscheidung, nicht den Prototyp.
Warum nicht einfach direkt im echten Code ausprobieren?
Die naheliegende Alternative wäre, die fragliche Logik gleich in der echten Komponente
umzubauen und so lange zu testen, bis es passt. Genau das verhindert der Skill bewusst durch
Regel eins und drei: kein Test-Setup, keine Datenbank, kein bestehender State-Store im Weg. Ein
UI-Prototyp hängt sich zwar an eine echte Route (Sub-Shape A, laut UI.md der
bevorzugte Fall), aber nur, um an echten Daten und echter Dichte gemessen zu werden, nicht um
produktionsreif zu sein. Der entscheidende Unterschied zur direkten Umsetzung: Ein Prototyp
darf falsch sein, ohne dass jemand das später wieder sauber herausoperieren muss, weil er nie
vorhatte, in main zu landen.
Der Testfall: eine echte, ungeklärte Zustandsfrage
In TodoView.vue berechnet nextDue() für wiederkehrende Garten-Todos
das nächste Fälligkeitsdatum aus completedAt + Intervall. isCompleted()
prüft dagegen completedAt ≥ nextDue, obwohl nextDue selbst gerade erst
aus completedAt abgeleitet wurde. Bei einem positiven Intervall ist diese Bedingung
rechnerisch nie wahr. Ein wiederkehrendes Todo landet also nie in der „Erledigt“-Liste: Klickt
man das Häkchen, verschwindet es sofort wieder unter „Offen“, mit neuem, weiter in der Zukunft
liegenden Fälligkeitsdatum, ohne jede sichtbare Bestätigung. Der Feldkommentar im Datenmodell,
completedAt // ISO datetime des letzten Abhakens, zeigt, dass dem ursprünglichen
Autor bewusst war, dass hier Information verloren geht, ohne dass je eine Entscheidung für oder
gegen eine Historie getroffen wurde.
Die Design-Frage in einem Satz: Soll ein Abhaken bei wiederkehrenden Todos irgendeine sichtbare
Bestätigung oder einen Verlauf bekommen, oder ist das unsichtbare Weiterschieben auf den
nächsten Termin tatsächlich das gewünschte Verhalten? Das ist eindeutig eine Zustandsfrage, kein
Layout-Problem, also der LOGIC-Zweig aus LOGIC.md.
Der Prototyp
Nach LOGIC.md gehört an den Anfang der Demo die Frage selbst, in einem Absatz, nicht
im Kommentar. Danach ein reiner Reducer ohne DOM-Zugriff, liftbar in den echten
Code, und darüber eine Seite mit domänensprachlichen Buttons statt Reducer-Jargon. Gebaut hat
Claude Code, unter meiner Anleitung, zwei Modelle nebeneinander, umschaltbar mit einem Klick:
- Modell A ist der 1:1-Nachbau der Logik aus
TodoView.vue, inklusive des Fehlers. - Modell B ist ein Alternativvorschlag mit
lastCompletedAtund einer explizitenhistory[]-Liste statt Selbstbezug.
Dazu, wie vorgeschrieben, freies Klicken (Todo anlegen, abhaken, zurücksetzen) und drei geführte Walkthroughs als Tabs: der Happy Path mit einem einmaligen Todo, ein wiederkehrendes Todo dreimal hintereinander abgehakt, und ein Doppelklick-Fall direkt nach dem Abhaken. Jeder Schritt ist ein echter Button, der die passende Aktion auslöst und zum nächsten Schritt weiterschaltet.
| Ergebnis im Browser | Modell A (wie im Code) | Modell B (mit Verlauf) |
|---|---|---|
| Wiederkehrendes Todo einmal abgehakt | bleibt unter „Offen“, kein Häkchen sichtbar | wechselt sichtbar nach „Erledigt“, mit Häkchen |
| Verlauf | keiner, nur der letzte Zeitpunkt | Zähler „1× erledigt“, wächst mit jedem Durchlauf |
| Rückgängig machen möglich? | de facto ja, aber nur weil „erledigt“ nie eintritt | ja, über denselben Button, solange derselbe Tag |
Der Prototyp ist eine einzelne, selbstständige HTML-Datei, genau wie LOGIC.md es
vorschreibt. Kein Build, kein Server nötig, direkt im Browser klickbar.
Was der Prototyp nebenbei aufgedeckt hat
Der eigentliche Nutzen zeigte sich nicht erst beim Klicken, sondern schon beim Bau von Modell A:
Um die bestehende Logik originalgetreu nachzubilden, musste Claude Code nextDue()
und isCompleted() Zeile für Zeile in den Reducer übertragen. Genau dabei wird die
Selbstbezüglichkeit offensichtlich, die im echten Code zwischen mehreren Computed-Properties und
einer 200 Zeilen langen Komponente verteilt und dadurch weniger auffällig ist. Der Prototyp hat
den Fehler nicht gesucht, sondern als Nebenprodukt beim Nachbauen der Logik automatisch
sichtbar gemacht: Im Browser lässt sich live beobachten, dass „Erledigt“ nach dem Klick leer
bleibt, während „Offen“ sich nur das Datum ändert.
Der Abschluss laut Skill: festhalten statt liegen lassen
Schritt sechs aus SKILL.md verlangt, den Prototyp nach der Entscheidung auf einen
eigenen Wegwerf-Branch zu committen, mit der Frage und dem Verdikt in der Commit-Message, statt
ihn einfach im Arbeitsverzeichnis liegen zu lassen. Das habe ich befolgt: Branch
prototype-skill-test, Commit-Message mit Frage, Auslöser (der Bug aus
TodoView.vue) und Verdikt (Modell B beantwortet die Frage sauberer und deckt den
Fehler auf; Empfehlung für die Umsetzung: completedAt durch
lastCompletedAt plus history[] ersetzen). Der Prototyp selbst bleibt
auf diesem Branch, nicht in main.
UI.md mit
seinen mehreren Layout-Varianten und der schwebenden Umschalt-Leiste blieb ungetestet, weil die
gefundene Frage eindeutig eine Zustandsfrage war. Ob die Variantenumschaltung in einer echten
Vue-Route genauso reibungslos funktioniert wie im LOGIC.md-Zweig beschrieben,
müsste ein zweiter Durchlauf an einer echten UI-Frage zeigen.
Direkter Vergleich zu den naheliegenden Alternativen
| /prototype | Direkt im echten Code testen | Nur beschreiben/planen | |
|---|---|---|---|
| Auslösung | manuell (oder theoretisch automatisch, laut Skill selten) | manuell, ad hoc | manuell, in Worten |
| Kann falsch sein, ohne Aufräumkosten | ja, per Definition wegwerfbar | nein, muss später sauber herausoperiert werden | ja, kostet aber keine Erkenntnis |
| Für Nicht-Entwickler nachvollziehbar | ja, domänensprachliche Buttons statt Code | nein | teilweise, ohne Interaktion |
| Deckt verteilte Logikfehler auf | ja, beim Nachbau als Nebeneffekt | möglich, aber im bestehenden Umfang versteckt | nein |
| Hinterlässt einen Nachweis | ja, auf Wegwerf-Branch mit Verdikt | nur der finale Diff | nur wenn mitgeschrieben |
Wann sich das lohnt
Eine State- oder UI-Frage, die sich nicht im Kopf durchspielen lässt
Ein Zustandsmodell mit mehreren Übergängen, ein Datenmodell mit unklaren Edge Cases, oder mehrere plausible Layouts für dieselbe Seite. Genau der Fall aus diesem Test.
Eine fachfremde Person muss mitentscheiden
Die HTML-Logikdemo braucht kein Setup und spricht Domänensprache statt Code. Wo nur Entwickler beteiligt sind, reicht oft auch ein Gespräch am bestehenden Code.
Die Antwort ist eigentlich schon klar
/prototype weglassen. Für eine eindeutige, unstrittige Änderung ist der
Wegwerf-Umweg reiner Zusatzaufwand.
Skills für Ihr Team auswählen?
Ich richte Claude Code in Entwicklerteams ein, inklusive der Frage, welche Skills wirklich etwas bringen und welche nur Tokens kosten. 30 Minuten Erstgespräch, kostenlos.