BuilderIO/read-the-damn-docs

Lies die verdammte Dokumentation

Rate nicht, wenn autoritative Dokumentationen die Frage beantworten können. Der häufigste korrekte Schritt ist, im Internet nach den aktuellen offiziellen Dokumentationen zu suchen, die relevanten Seiten zu öffnen und sie zu lesen, bevor du programmierst. Verankere bei APIs, Versionen, Providerverhalten, Konfiguration, Limits, Lifecycle-Hooks oder sicherheitsrelevanten Abläufen die Antwort in dem, was die Dokumentation tatsächlich sagt.

Auslöser für Dokumentation zuerst

Lies die Dokumentation, bevor du fortfährst, wenn einer dieser Punkte zutrifft:

• Der Benutzer fragt nach „neuest“, „aktuell“, „offiziell“, „unterstützt“, „Best Practice“, „empfohlen“, „heute“, „jetzt“ oder „schlage nach“.
• Die benötigte Dokumentation befindet sich nicht bereits im Repository oder wurde nicht vom Benutzer bereitgestellt. Suche im Internet nach der offiziellen Dokumentation, anstatt darauf zu hoffen, dass das Modellwissen aktuell ist.
• Die Aufgabe fügt ein Paket, SDK, Framework, Plugin, CLI, Modell, Cloud-Ressource oder eine Provider-Integration hinzu, aktualisiert, konfiguriert oder importiert es.
• Die API entwickelt sich schnell oder ist versionssensitiv: AI-SDKs, OpenAI/Anthropic/Google APIs, Next.js, React, Tailwind, Vite, Nitro, Drizzle, Prisma, Stripe, GitHub, Slack, Notion, Browser-APIs, Deployment-Plattformen, Authentifizierungsbibliotheken und ähnliches.
• Die Implementierung hängt von Authentifizierung, OAuth-Scopes, Berechtigungen, Secrets, Webhooks, Abrechnung, Zahlungen, PII, Verschlüsselung, Datenaufbewahrung, Migrationen, Wiederholungen, Ratenlimits, Kontingenten, Caching, Deployments oder Compliance ab.
• Ein Fehler erwähnt Veraltung, unbekannte Optionen, fehlende Exporte, ungültige Konfiguration, nicht unterstützte Felder, geänderte Standardwerte oder Versionskonflikte.
• Ein Repository enthält lokale Dokumentationen, ADRs, generierte Schemata, OpenAPI-Spezifikationen, Routen-/Aktionsregister, Design-System-Dokumentationen oder paketweise READMEs, die den Vertrag definieren könnten.
• Die Entscheidung ist teuer rückgängig zu machen: öffentliche Wire-Formate, Datenbankschema, Migrationsstrategie, persistente IDs, Ereignisnamen, kundensichtbares Verhalten oder externe Automatisierungsverträge.
• Du ertappst dich dabei, dass du kurz davor bist, „normalerweise“, „wahrscheinlich“, „ich denke“, „aus dem Gedächtnis“ oder Code zu schreiben, der aus dem Modellgedächtnis für eine externe API kopiert wurde.

Was als Dokumentation zählt

Verwende die jeweils autoritativste verfügbare Quelle:

• Lokale Repository-Dokumentationen, Spezifikationen, ADRs, Schemata, generierte Typen, Paket-READMEs und Tests für projektspezifisches Verhalten.
• Offizielle Produktdokumentationen, API-Referenzen, Migrationsleitfäden, Änderungsprotokolle, Versionshinweise und SDK-Quellcode/Typen für Drittanbieter-Verhalten. Finde diese durch eine Websuche, wenn du die genaue URL noch nicht hast.
• Paketregistermetadaten für Versionen. Führe vor dem Hinzufügen einer Abhängigkeit npm view <pkg> version, pnpm view <pkg> version oder das entsprechende Ökosystemäquivalent aus und lies dann die Dokumentation für die Hauptversion.
• Quellcode oder Typdefinitionen, wenn die offizielle Dokumentation unvollständig ist. Behandle dies als Beweis, nicht als Hörensagen.

Vermeide Stack Overflow, alte Blogbeiträge, zufällige Code-Snippets und Gedächtnis als primäre Quelle, wenn offizielle Dokumentationen existieren. Verwende Community-Quellen nur zur Fehlersuche bei Symptomen, nachdem der autoritative Vertrag bekannt ist.

Erforderlicher Arbeitsablauf

1. Identifiziere die genaue Oberfläche: Paketname, installierte Version, Zielversion, Provider-Endpunkt, CLI-Befehl, Konfigurationsdatei, lokaler Helfer, Schema oder Produktfunktion.
2. Suche im Internet nach der aktuellen offiziellen Dokumentation, es sei denn, die relevante Dokumentation ist bereits lokal vorhanden oder der Benutzer hat eine URL angegeben. Verwende gezielte Suchbegriffe wie <Produkt> <Funktion> offizielle Dokumentation, <Paket> Migrationsleitfaden oder <Provider> API-Referenz.
3. Öffne und lies die Dokumentation, die dieser Oberfläche am nächsten kommt. Bevorzuge zuerst lokale Dokumentation für internen Code, dann offizielle Upstream-Dokumentation. Überprüfe bei neuen Paketen die neueste Version, bevor du Importe, Konfiguration oder Installationsbefehle schreibst.
4. Extrahiere die wenigen Fakten, die für die Aufgabe benötigt werden: Optionsnamen, Importe, Lifecycle-Regeln, Standardverhalten, Breaking Changes, Limits, Berechtigungen und Beispiele für die aktuelle Hauptversion.
5. Implementiere oder antworte mit diesen Fakten. Wenn die Dokumentation mit vorhandenem Code in Konflikt steht, überprüfe den lokalen Codepfad und weise auf die Abweichung hin.
6. Überprüfe mit der kleinsten sinnvollen Prüfung: Typprüfung, Tests, Build, CLI-Trockenlauf, API-Schema-Validierung oder eine lokale Reproduktion.
7. Nenne in der endgültigen Antwort die Dokumentation oder die lokalen Dateien, die konsultiert wurden, wenn diese Belege die Empfehlung oder Implementierung beeinflussen.

Beispiele, die Dokumentation auslösen müssen

• „Füge Tailwind zu dieser App hinzu.“ Überprüfe die aktuelle Tailwind-Hauptversion und ihre Installationsdokumentation aus dem Internet, bevor du Konfigurationsdateien erstellst oder eine alte PostCSS-Einrichtung annimmst.
• „Verwende das AI SDK, um Antworten zu streamen.“ Überprüfe die aktuelle AI SDK-Hauptversion, Importe, Provider-Paketnamen, Streaming-Helper und Server-/Laufzeitbeispiele aus der offiziellen Dokumentation.
• „Richte Stripe-Webhooks ein.“ Lies die aktuellen Stripe-Dokumentationen zur Signaturüberprüfung, Ereigniswiederholung, Endpunktgeheimnis und Framework-Body-Parsing, bevor du programmierst.
• „Behebe diesen Next.js-Caching-Fehler.“ Lies die Dokumentation für die installierte Next.js-Hauptversion und den Router-Modus, bevor du Cache-Invalidierungssemantik annimmst.
• „Füge Drizzle-Migrationen hinzu.“ Lies die aktuellen Drizzle-Kit-Dokumentationen und die vorhandenen Repository-Migrationskonventionen, bevor du Dateien generierst.
• „Erstelle eine GitHub Action.“ Lies die offiziellen Actions-Syntax- und Berechtigungsdokumentationen, insbesondere für pull_request, workflow_run, OIDC, Tokens und Artefakte.
• „Warum schlägt dieser OAuth-Flow fehl?“ Lies die Provider-Dokumentationen zu Scopes, Redirect-URI, PKCE, Token-Refresh und App-Verifizierung, bevor du Code änderst.
• „Verwende das Plan/Kommentar/Aktionssystem dieses Repositorys.“ Lies lokale Dokumentationen, Routen-/Aktionsregister, Schemata und Tests, bevor du Endpunkte oder Props erfindest.
• „Aktualisiere Vite/Nitro/React.“ Lies den Migrationsleitfaden für die exakte Ziel-Hauptversion, bevor du Konfiguration oder Importe bearbeitest.
• „Welches Modell sollen wir verwenden?“ Lies aktuelle Provider-Modell-Dokumentationen, Preis-/Limit-Seiten und SDK-Beispiele, bevor du eine Empfehlung abgibst.

Wenn ein kurzer lokaler Lesevorgang ausreicht

Durchsuche nicht das Internet für jede winzige Änderung. Ein Dokumentationsdurchlauf kann lokal und kurz sein, wenn die Antwort bereits im Repository enthalten ist: vorhandene Helferverwendung, nahegelegene Tests, typisierte Schnittstellen, generierte Clients, ADRs oder Paket-READMEs. Wenn die Aufgabe jedoch von einem externen Tool, Paket, Provider oder aktuellem Produktverhalten abhängt, ist die Websuche normalerweise der richtige erste Schritt. Bei trivialer Sprachsyntax, Tippfehlerkorrekturen, Formatierung oder in sich geschlossenem Code ohne externen Vertrag fahre normal fort.

Wenn keine Dokumentation verfügbar ist

Wenn Netzwerkzugriff, Authentifizierung oder fehlende lokale Dateien das Lesen der Dokumentation verhindern, sage dies deutlich, bevor du dich auf das Gedächtnis verlässt. Grenze die Unsicherheit ein, überprüfe Quellcode oder Typen, falls verfügbar, und vermeide es, das Ergebnis als bestätigt aktuell darzustellen.