PullMD Teil 1: Strg+A und der Junk-Kontext
Ich sitze vor einem langen Reddit-Thread, in dem jemand exakt das Problem beschreibt, mit dem ich gerade arbeite. Strg+A, Strg+C, rein in den Chat. Am Handy dasselbe Spiel, nur umständlicher: alles markieren, kopieren, einfügen — denn „Teilen an Claude“ funktioniert bei Reddit nicht, die blocken KIs. Und ich ertappe mich immer wieder bei genau diesen Handgriffen.
Die Antwort ist am Ende brauchbar. Teuer ist der Weg dahin: Ein Drittel des eingefügten Textes ist Navigationsleiste, ein Drittel Cookie-Banner und Sidebar-Werbung, und erst das letzte Drittel ist der eigentliche Inhalt. Token und Zeit verpuffen für Rauschen, bevor das Modell auch nur einen Satz des relevanten Posts gelesen hat. Ich wollte, dass der Chatbot den Thread versteht — nicht die ganze Reddit-UI mitliest.
Das ist keine neue Erkenntnis. Aber es ärgert mich jedes Mal neu. Und irgendwann reichte ein Mal zu viel.
Die kurze Hoffnung: Cloudflare bringt einen Markdown-Dienst
Cloudflare hat einen Markdown-Service eingeführt — eine URL als Eingabe, sauberes Markdown als Ausgabe, ohne UI-Overhead. Ich habe es sofort ausprobiert. Ein paar Wikipedia-Artikel, ein Tech-Blog — das Ergebnis sah beeindruckend aus. Sauberes Markdown, keine Navigation, keine Werbung.
Die Euphorie hielt ein paar Tage. Dann kam die Ernüchterung: Der Dienst funktioniert nur, wenn die Zielseite ihn aktiv unterstützt. Site-Betreiber müssen ihre Seite dafür freigeben. Reddit tut das nicht. Viele der Blogs, die ich täglich lese, auch nicht. Bei diesen Seiten bekomme ich entweder einen Fehler oder genau den selben HTML-Brei, nur einen API-Call weiter entfernt.
Ich wollte schon fast einen Skill dafür bauen — eine Automation, die für die wenigen unterstützten Seiten den Cloudflare-Weg nutzt. Aber ein Werkzeug, das nur für einen Bruchteil der Quellen funktioniert, die ich tatsächlich verwende, ist keine Lösung. Es ist ein Pflaster.
Eigenbau, klein anfangen
Die Entscheidung war schnell getroffen: wenn es nichts Fertiges gibt, das wirklich funktioniert, baue ich es selbst. Aber nicht groß und nicht alles auf einmal. Reddit zuerst — weil es meine häufigste Quelle ist, und weil es einen bekannten Workaround gibt: An jede Reddit-URL einfach .json anhängen, und man bekommt die Rohdaten ohne API-Key, ohne OAuth, ohne App-Registration. Das ist seit Jahren dokumentiert, noch immer aktiv, und genau das Richtige für einen ersten Schritt.
Für Android sollte der Service als PWA installierbar sein, mit der Web Share Target API — damit ich aus der Reddit-App direkt auf „Teilen“ drücken und den Link in meinen Service schicken kann, ohne Umweg über einen Browser-Tab. Vor dem ersten Code-Zeichen wollte ich aber erst das Konzept durchdenken. Also ein Planungs-Chat auf claude.ai, um die Architektur zu sortieren — und dann Claude Code mit dem fertigen Spec loslassen.
Der Konzept-Chat (02. März)
Der Konzept-Chat begann mit einem Tippfehler, den meine Autokorrektur produziert hat. Mein erster Prompt fragte nach einem Tool für „Tresor Posts“. Die Antwort kam ziemlich schnell:
Gute Idee, lass uns das durchdenken! Ich nehme an, „Tresor“ war Autokorrektur und du meinst Reddit Posts – richtig?
Das hat mich kurz amüsiert und gleichzeitig daran erinnert, warum ich diesen Chat führe — weil das Modell im richtigen Kontext trotzdem versteht, was ich meine. Genau diesen Kontext wollte ich qualitativ besser machen.
Die zentrale Architektur-Frage war: ein Zugang oder zwei? Claude hat es klar aufgeteilt. Der Kern ist ein HTTP-Endpoint — für CLI, Claude Code selbst, n8n-Workflows. Darüber liegt eine Mini-Web-UI als PWA — für Android, mit dem Share-Target. Beide Wege führen zum selben Endpoint, bedienen aber unterschiedliche Konsumenten. Das Modell hat vorgeschlagen, auf die offizielle Reddit-API zu verzichten, da man heute nur noch auf Anfrage Zugang bekommt. Stattdessen eine Dual-Strategie: .json-Trick zuerst (URL + .json, mit einem realistischen User-Agent-Header), und wenn Reddit blockt, Fallback auf HTML-Scraping von old.reddit.com. Das alte Reddit ist viel einfacher zu parsen als das neue Design, und kein Headless-Browser nötig.
Beim Kommentar-Format hat Claude eine Entscheidung getroffen, die ich sofort gut fand: Einrückung mit zwei Leerzeichen statt Markdown-Blockquotes (> > >). Der Grund ist praktisch — bei verschachtelten Antworten ab Tiefe 4 werden >-Ketten im Copy-Paste-Output in Chatbots kaum noch lesbar. Mit Einrückung bleibt die Hierarchie erkennbar, ohne die Token-Struktur zu vergraben.
Dann kam der Moment, an dem der Codename gewählt wurde. Claude schlug einen kurzen Codenamen vor, mit dem ich die nächsten Wochen baute — aus markenrechtlichen Gründen Wochen später wieder abgelegt, dazu in Teil 4 mehr.
Am Ende des Chats stand die Frage nach der Subdomain. Mein Heimnetz folgt einem festen Subdomain-Schema, und ich habe Claude einfach gebeten, sich für den neuen Service einen Namen auszusuchen.
Web Share Target API — kurz erklärt
Die Web Share Target API ist ein Manifest-Eintrag, der einer installierten PWA erlaubt, sich im Android-Share-Sheet zu registrieren. Das entscheidende Wort ist installiert — nicht nur als Lesezeichen im Browser, sondern über den Browser-Dialog „App installieren“ oder „Zum Startbildschirm hinzufügen“. Außerdem muss die PWA über HTTPS laufen (was mit Traefik als Reverse-Proxy kein zusätzlicher Aufwand ist).
Der Manifest-Eintrag dafür sieht minimal so aus:
"share_target": {
"action": "/share",
"method": "GET",
"params": {
"url": "link"
}
}Sobald die PWA installiert ist, erscheint sie im Android-Share-Dialog neben WhatsApp, Signal und Co. Ein Klick auf den Eintrag öffnet die App mit dem geteilten Link bereits vorausgefüllt. Für jeden, der einen eigenen URL-zu-X-Service auf Android nutzbar machen will, ohne eine native App zu bauen, ist das der direkteste Weg.
Das Ergebnis: ein Spec, kein Code
Am Ende des Chats stand eine vollständige Spezifikation: Dateistruktur, API-Design mit Parametern und Rückgabeformaten, PWA-Manifest, Docker-Compose mit Traefik-Labels. Ein Ausgabe-Format-Beispiel mit eingerückten Kommentaren. Alle offenen Fragen beantwortet.
Kein einziges Zeichen Code — das war der Plan. Der Chat sollte klären, nicht bauen. Das Bauen würde Claude Code übernehmen, mit dem Spec als Briefing. Am selben Abend, 21:53 Uhr, fing es an.
Teil 1 von 9 der PullMD Serie.