PullMD Teil 4: Der Skill, und was er wirklich bringt

Der Dienst lief, und ich konnte ihn mit curl aufrufen. Nur war das nicht der Punkt. Der Punkt war, dass Claude Code ihn aufruft, ohne dass ich jedes Mal danebenstehe und es ihm sage.

Dafür gibt es Skills. Und weil ich mir bei so etwas nie sicher bin, ob es wirklich etwas ändert oder ob ich mir das nur einbilde, haben wir es gemessen.

Was ein Skill eigentlich macht

Ein Skill ist keine Funktion. Er stellt kein Werkzeug bereit und er kann nichts, was der Agent nicht ohnehin schon könnte.

Er beschreibt Verhalten. Also ungefähr: Wenn jemand dich bittet, eine Seite zu lesen, dann nimm PullMD und nicht WebFetch, das eingebaute Abruf-Werkzeug von Claude Code. Bei GitHub-Adressen nicht, da nimm gh, das Kommandozeilenwerkzeug von GitHub. Und wenn PullMD nicht antwortet, fall auf WebFetch zurück, statt abzubrechen.

Das ist der Unterschied zwischen „das Werkzeug existiert“ und „das Werkzeug wird an der richtigen Stelle benutzt“. Ein Werkzeug-Schema kann das gar nicht ausdrücken, weil es nur beschreibt, was ein Aufruf tut, und nicht, wann er dran ist.

Der Skill hieß damals noch web-reader. Den Namen, unter dem das Projekt heute läuft, gab es noch nicht.

Drei Aufgaben, zweimal gefahren

Die Frage war also: Merkt man den Unterschied überhaupt? Claude hat drei Aufgaben aufgeschrieben und jede zweimal laufen lassen, einmal mit Skill und einmal ohne. Die Antworten liegen bis heute nebeneinander im Projekt, samt einer kurzen Notiz, welcher Weg jeweils genommen wurde.

Die drei Aufgaben:

Einen Wikipedia-Artikel lesen und in drei Sätzen zusammenfassen
Die Startseite von Hacker News abrufen und die fünf obersten Titel nennen
Eine Adresse abrufen, die es gar nicht gibt

Die dritte war der eigentliche Test. Die ersten beiden sollten zeigen, ob im Normalfall etwas passiert.

Das Ergebnis war unbequemer, als mir lieb war

Bei der Zusammenfassung gab es praktisch keinen Unterschied. Beide Fassungen sind richtig, beide ungefähr gleich lang, beide nennen John Gruber und das Jahr 2004. Wer die zwei Absätze nebeneinanderlegt, sieht zwei brauchbare Antworten.

Bei Hacker News wurde es interessanter. Ohne Skill kamen fünf Titel, mit Skill dieselben fünf Titel, dazu Punktzahlen und Kommentarzahlen:

1. **Motorola GrapheneOS devices will be bootloader unlockable/relockable**
   (773 Punkte, 249 Kommentare)
2. **RFC 9849. TLS Encrypted Client Hello** (93 Punkte, 42 Kommentare)

Nicht weil der Skill schlauer wäre, sondern weil über PullMD die ganze Seite als Markdown ankommt und das Modell sich nehmen kann, was es braucht. Bei WebFetch hat vorher schon ein Modell entschieden, was wichtig ist.

Und bei der Adresse, die es nicht gibt, wurde der Unterschied dann deutlich. Ohne Skill:

Fehlermeldung: unable to verify the first certificate

Das ist schlicht irreführend. Die Domain existiert nicht, mit Zertifikaten hat das nichts zu tun.

Mit Skill stand da, dass die Endung .invalid nach RFC 2606 absichtlich nie auflösbar ist, dazu die Kette der Versuche: erst PullMD, dann WebFetch, beide gescheitert, und warum.

Was wir daraus gelernt haben

Der Gewinn ist nicht groß. Er ist strukturell. Die Token-Ersparnis ist eine andere Rechnung, nämlich PullMD gegen rohes HTML; hier ging es nur um den Skill gegen WebFetch. PullMD gibt wortgetreu zurück, was auf der Seite steht, WebFetch nur das, was davon übrig bleibt.

Bei einer Zusammenfassung fällt das nicht auf, denn zusammengefasst wird ja sowieso. Bei Zahlen fällt es auf. Und bei Fehlern fällt es richtig auf, weil die Zwischenstufe eine plausible Erklärung erfindet, wo eine unplausible richtig gewesen wäre.

Ich hätte das Ergebnis gerne eindeutiger gehabt. „Mit Skill dreimal so gut“ wäre eine schöne Zahl gewesen. So war es aber nicht, und ich finde es im Nachhinein ganz gut, dass ich es aufgeschrieben habe, statt es zu erzählen.

Ende April hat mir das übrigens jemand auf Reddit noch einmal von der anderen Seite erklärt, ohne den Skill überhaupt zu kennen. Das steht in Teil 9.

Teil 4 von 15 der PullMD Serie.

← PullMD Teil 3: Die API, und wie aus Reddit jede URL wurde | PullMD Teil 5: Die falsche Engine gemessen →