Wann einsetzen: Sie treffen auf einen gebührenpflichtigen Artikel, eine Dokumentationsseite oder einen Blogbeitrag und möchten TL;DR plus eine Meinung, ohne es selbst zu lesen.
Ablauf
-
Mit Markdown-Ausgabe abrufen
Rufen Sie https://example.com/blog/post auf und geben Sie mir die ersten ~3000 Zeichen als bereinigtes Markdown.✓ Kopiert
→ Inhalt kommt mit funktionierenden Überschriften und ohne Nav-Chrome an
-
Zusammenfassen und Behauptungen extrahieren
Zusammenfassung in 5 Punkten. Listen Sie alle spezifischen Zahlen oder Behauptungen des Autors auf, mit dem Satz, in dem sie erscheinen.✓ Kopiert
→ Zusammenfassung mit Aufzählungszeichen plus zitierte Zitate, nicht paraphrasiert
-
Kritik
Was ist das stärkste Gegenargument zu der Hauptthese des Autors? Seien Sie spezifisch.✓ Kopiert
→ Echte Kritik, nicht 'andererseits...' Matsch
Ergebnis: Eine nützliche Lektüre des Artikels in 30 Sekunden, mit Zitaten, die Sie überprüfen können.
Fallstricke
- Seite wird mit JS gerendert und das Abrufen gibt eine nahezu leere Hülle zurück — Überprüfen Sie die erste Abrufausgabe – wenn sie verdächtig kurz ist oder 'Loading...' sagt, wechseln Sie zu Firecrawl oder Chrome DevTools MCP
- Lange Seite wird von max_length gekürzt — Verwenden Sie
start_index für die Paginierung: der zweite Aufruf mit start_index: 5000 setzt fort, wo der erste endete
Wann einsetzen: Eine Bibliothek, von der Sie abhängig sind, veröffentlicht Versionshinweise auf einer statischen Seite und Sie haben einen Monat lang nicht überprüft.
Ablauf
-
Die Änderungsseite abrufen
Rufen Sie https://vendor.com/changelog auf und listen Sie jede Freigabe seit 2026-03-01 mit ihrem Datum und einer einzeiligen Zusammenfassung der Änderungen auf.✓ Kopiert
→ Chronologische Liste mit Daten
-
Nach Auswirkungen klassifizieren
Kategorisieren Sie jedes in: Breaking Change, neue Funktion, Fehlerbehebung, intern. Kennzeichnen Sie alles, was als Breaking oder veraltet gekennzeichnet ist.✓ Kopiert
→ Pro-Release-Tag mit hervorgehobenen Breaking-Elementen
-
Hervorheben, was uns betrifft
Wir verwenden diese Bibliothek hauptsächlich für <Funktion X>. Welche dieser Änderungen beeinflussen unsere Nutzung, und welche Maßnahme (falls vorhanden) sollten wir ergreifen?✓ Kopiert
→ Handlungsliste, nicht generisch 'überprüfen Sie die Notizen'
Ergebnis: Wissen Sie in 2 Minuten, ob Sie die Version aktualisieren und testen müssen oder die Freigabe ganz überspringen.
Fallstricke
- Änderungsprotokolle werden paginiert – erste Seite hat nur die letzten 2 Monate — Blättern Sie mit
start_index oder rufen Sie die Archiv-URL explizit auf - GitHub-Release-Seiten werden jetzt über JS gerendert — Verwenden Sie stattdessen die rohe API:
https://api.github.com/repos/owner/repo/releases gibt JSON ohne JS zurück
Wann einsetzen: Sie programmieren gegen eine öffentliche Spezifikation (OAuth, RFC 9457 Problemdetails, eine REST-APIs Referenzdokumentation) und möchten, dass Claude die kanonische Quelle hat.
Ablauf
-
Die Spezifikationsseite(n) abrufen
Rufen Sie https://datatracker.ietf.org/doc/html/rfc9457 als Markdown auf. Geben Sie nur die Abschnitte 1-4 zurück.✓ Kopiert
→ Bereinigtes Markdown der normativen Abschnitte
-
Dagegen implementieren
Verwenden Sie diesen RFC als Quelle der Wahrheit und schreiben Sie mir einen TypeScript-Typ plus Validator für das Problem-Details-Objekt. Zitieren Sie spezifische Abschnittsnummern in Kommentaren.✓ Kopiert
→ Code mit Inline-// per RFC 9457 §3.1-Verweisen
-
Überprüfung der Grenzfälle
Welche Grenzfälle oder optionalen Felder aus der gleichen RFC behandelt meine Implementierung nicht? Entscheiden Sie, ob Sie diese behandeln oder die Wahl dokumentieren.✓ Kopiert
→ Ehrliche Lückenanalyse gegen die Spezifikation
Ergebnis: Eine spezifikationstreue Implementierung mit nachverfolgbaren Zitaten, die Sie in der Code-Überprüfung verteidigen können.
Fallstricke
- IETF-Seiten sind riesig – ein vollständiger RFC kann das Kontext-Budget überschreiten — Rufen Sie nur die benötigten Abschnitte mit Ankerlinks oder start_index auf, nicht das vollständige Dokument