prototype (mattpocock/skills)

Bewertung

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem Mac-Testrechner, einem frischen temporären Projekt und temporären HOME/TMPDIR/Caches pro Lauf; Skill installiert (Treatment) oder nicht vorhanden (Kontrolle) oder nicht vorhanden mit der Kernanforderung des Skills in einem an den Prompt angehängten Satz (One-Liner-Gruppe); 2 Läufe pro Gruppe und Aufgabe; Netzwerk aus; Schreiben nach /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten genannten Formulierung). Drei Aufgaben: einen Abo-Lebenszyklus mit Zahlungsfehlern modellieren (State-Frage), Optionen für eine statische Preis-Sektion vergleichen (Look-Frage, echte Tarifinhalte müssen bleiben) und den Nutzer Rabatt-Stapelungsregeln ausprobieren lassen, bevor programmiert wird (Logik-Frage, Speichern in prototype/). Die Regelprüfungen umfassen eigenständiges HTML, fünf gezeigte Zustände, Buttons pro Ereignis, geführte Szenarien, Kennzeichnung als Prototyp, keine Testdateien und bei der Preis-Aufgabe mindestens drei Varianten, einen URL-Parameter ?variant= und einen festen schwebenden Umschalter.

Drei-Arm-Vergleich

Gemessen mit Codex CLI über 18 Läufe, bewertet durch regelbasierte Prüfungen ohne LLM-Richter. Gesamt 27.2 / 30, Urteil Empfohlen.

Urteil: Empfohlen (27.2 / 30). Quelle: mattpocock/skills, skills/engineering/prototype, festgeschrieben auf Commit 4ae2317. Installation: npx skills@latest add mattpocock/skills --skill prototype. Lizenz: MIT (LICENSE im Repo).

Was es ist

Der Skill prototype aus mattpocock/skills baut einen Wegwerf-Prototyp, der eine Designfrage beantwortet. Fragen zu Logik oder Zustand erhalten eine einzelne HTML-Datei mit Zustandsanzeige, Freispiel-Buttons und geführten Durchläufen; Fragen zum Aussehen erhalten mehrere radikal unterschiedliche Varianten auf einer Route, umschaltbar per URL-Parameter und einer schwebenden Leiste am unteren Rand. Regeln: klar als Wegwerf markiert, mühelos auszuführen, keine Persistenz, kein Feinschliff, keine Tests. SKILL.md plus LOGIC.md und UI.md, insgesamt etwa 2,600 Wörter; nur Markdown.

Wie wir getestet haben

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem Mac-Testgerät, pro Lauf ein frisches temporäres Projekt sowie temporäre HOME/TMPDIR/Caches, Skill installiert (Treatment) oder nicht vorhanden (Kontrolle) oder nicht vorhanden mit der Kernanforderung des Skills als einem an den Prompt angehängten Satz (Ein-Satz-Gruppe), 2 Läufe pro Gruppe und Aufgabe, Netzwerk aus, Schreibzugriffe auf /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten erwähnten Formulierung).

Drei Aufgaben: einen Abo-Lebenszyklus mit Zahlungsfehlern modellieren (Zustandsfrage), Optionen für einen statischen Preisbereich vergleichen (Aussehensfrage, der echte Tarifinhalt muss bleiben) und den Nutzer Rabattstapelungsregeln ausprobieren lassen, bevor programmiert wird (Logikfrage, Speichern in prototype/). Zu den Regelprüfungen gehören eigenständiges HTML, fünf angezeigte Zustände, ein Button pro Ereignis, geführte Szenarien, die Markierung als Prototyp, keine Testdateien und bei der Preisaufgabe mindestens drei Varianten, ein ?variant=-URL-Parameter und ein fester schwebender Umschalter.

1. Ein Abo-Zustandsmodell prototypen — Ich kann nicht beurteilen, ob unser Abo-Lebenszyklus bei Zahlungsfehlern Sinn ergibt. Zustände: trial, active, past_due, paused, canceled. Ereignisse: Trial endet, Zahlung erfolgreich, Zahlung fehlgeschlagen, Nutzer pausiert, Nutzer setzt fort, Nutzer kündigt, Nutzer reaktiviert. Regeln: zwei fehlgeschlagene…
2. Preisseiten-Varianten prototypen — Auf pricing.html dieser kleinen statischen Website (drei Tarife) bin ich unsicher, wie die Tarife präsentiert werden sollten. Erstelle ein paar verschiedene Designoptionen für diesen Bereich, die ich im Browser vergleichen kann; der echte Preisinhalt muss bleiben. Kein Build-Schritt.
3. Rabattstapelungsregeln prototypen — Fühlt sich das Stapeln von Rabatten richtig an? Bisherige Regeln: Gutschein SAVE10 gibt 10% Rabatt, Gutschein HALF gibt 50% Rabatt, Bestellungen über $50 versandkostenfrei, Treuekunden erhalten zusätzlich 5% Rabatt. Ich kann nicht entscheiden, in welcher Reihenfolge sie gelten oder welche sich stapeln dürfen. Ich möchte Fälle ausprobieren und sehen, was…

Die Bewertung erfolgt programmatisch (versteckte Tests / Erkennung eingepflanzter Fehler / Constraint-Checks / Rendering+OCR, wo relevant), 0–5 pro Lauf. Kein LLM-Judge hat eine Bewertung entschieden.

Ergebnisse

Der Ein-Satz-Prompt für die dritte Gruppe: "Baue einen Wegwerf-Prototyp, der eine genannte Frage beantwortet: bei Logik- oder Zustandsfragen eine einzelne eigenständige HTML-Datei mit sichtbarer Formulierung der Frage, einer lesbaren Anzeige des aktuellen Zustands, die nach jedem Klick neu gerendert wird, einem Button pro Aktion und geführten Durchlauf-Szenarien (Happy Path, Edge Case, ein unerlaubter Schritt); bei Aussehensfragen drei radikal unterschiedliche Varianten auf einer Seite, umschaltbar per ?variant=-URL-Parameter und einer schwebenden Leiste am unteren Rand. Keine Tests, kein Feinschliff."

Durchschnittswert: 3.71 ohne vs. 4.95 mit dem Skill (Delta +1.23). Token pro Lauf: 133k vs. 136k (1.02x); Zeit 186s vs. 149s. Ein-Satz-Gruppe: 4.72 (Gewinn des Skills gegenüber dem Ein-Satz-Prompt: +0.23; Gewinn des Ein-Satz-Prompts gegenüber ohne Skill: +1.01); Ein-Satz-Token 89k pro Lauf, der Skill kostet also 1.52x so viel wie der Ein-Satz-Prompt.

Was passiert ist

• Durchschnittswert 3.71 für die Kontrolle, 4.72 für die Ein-Satz-Version, 4.95 für den Skill. Der Skill liegt +1.24 Punkte über der Kontrolle und +0.23 Punkte über dem Ein-Satz-Prompt, bei 136k Token pro Lauf gegenüber 133k (1.02x) für die Kontrolle und 89k für den Ein-Satz-Prompt (1.5x).
• Die Aussehensaufgabe zeigt den Effekt: Der Skill erzeugte in beiden Läufen drei Varianten mit einem schwebenden Umschalter am unteren Rand und per URL umschaltbaren Varianten (5.0 und 5.0 nach unseren Checks); die Kontrolle erreichte 4.0 und 1.0: in keinem Lauf eine schwebende Leiste, in einem Lauf drei Layouts mit Umschalter und URL-Parameter, im anderen nicht, und in einem Lauf fehlte ein Tarifpreis auf der Seite.
• Bei den beiden Logikaufgaben baute die Kontrolle bereits interaktives HTML (4.4-4.8 beim Abo-Modell, 4.0 bei der Rabattstapelung); der Skill ergänzt die Durchlauf-Szenarien und die Prototyp-Markierung: Szenarien erscheinen in 4 von 4 Skill-Läufen gegenüber 2 von 4 Kontroll-Läufen.
• Die Ein-Satz-Version war bei der Preisaufgabe ebenso gut; bei den Logikaufgaben verlor sie etwas, weil sie die Datei nicht immer als Prototyp markierte (2 von 4 Läufen).

Dimensionswerte

Grenzen dieses Tests

• Regelbasierte Checks von Merkmalen (Varianten, schwebende Leiste, Szenarien); die Qualität der Designs und ob der Prototyp die Frage beantwortet, wurden nicht von einer Person beurteilt.
• Die Bewertung wurde während der Analyse zweimal korrigiert: Varianten dürfen in separaten CSS/JS-Dateien liegen, und ein Layout-Umschalter zählt als Variante; der erste Durchlauf zählte diese zu niedrig, daher werden frühere Zahlen nicht verwendet.
• Der Rat des Skills, den Prototyp auf einem Wegwerf-Branch zu committen und einen Hinweis in einem Issue zu hinterlassen, lässt sich in einem Scratch-Ordner nicht testen.
• n = 2 pro Gruppe und Aufgabe: Abweichungen unter etwa 1 Punkt sind Rauschen.
• Regelbasierte Bewertung misst, was die Checks sehen können; sie kann weder Geschmack beurteilen noch, ob ein Ergebnis das bestmögliche ist.

Sicherheit

Siehe security.md. Scan: 1 CRITICAL / 1 HIGH / 0 MEDIUM. Urteil: sicher ausführbar (Sandbox ohne Netzwerk). Ein sauberer Scan beweist nicht, dass ein Skill sicher ist.

Fazit

Der Skill bringt Codex deutlich dazu, die Art von Prototyp zu bauen, die er beschreibt (per URL umschaltbare Varianten, schwebende Leiste, geführte Szenarien), wo eine schlichte Anfrage das nicht tut — ohne zusätzliche Token-Kosten. Eine Ein-Satz-Zusammenfassung erreicht das meiste davon, aber der Skill ergänzt die Logik-Durchläufe und die Details zur Prototyp-Markierung.