Heim

Skill

Produktivität und Workflow

read-the-damn-docs

BuilderIO/skills

Erfordert vor der Implementierung, Integration oder Fehlerbehebung von APIs, Bibliotheken und Diensten von Drittanbietern eine gründliche Recherche im Internet und das Lesen offizieller Dokumente, um die Richtigkeit sicherzustellen und Spekulationen zu vermeiden.

...Alle erweitern

Zeit aktualisiert 6. September 2026

# documentation # debugging # web search # api reference # best practices # third party apis

Lies die verdammten Dokumentationen

Raten Sie nicht, wenn es Fragen gibt, die in den offiziellen Dokumenten beantwortet werden können. Am häufigsten ist es richtig, im Internet nach den aktuellen offiziellen Dokumentationen zu suchen, die entsprechenden Seiten zu öffnen und sie vor dem Programmieren zu lesen. Bei APIs, Versionen, dem Verhalten von Anbietern, Konfigurationen, Limits, Lifecycle-Hooks oder sicherheitsrelevanten Abläufen sollten Sie die Antwort auf das stützen, was in der Dokumentation tatsächlich steht.

Anlässe für „Dokumente zuerst“

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

Der Nutzer fragt nach „neuesten“, „aktuellen“, „offiziellen“, „unterstützten“, „Best Practices“, „empfohlenen“, „heutigen“, „jetzigen“ Informationen oder sagt „schau mal nach“.
Die benötigten Dokumentationen befinden sich noch nicht im Repo oder wurden nicht vom Nutzer bereitgestellt. Suchen Sie im Internet nach den offiziellen Dokumentationen, anstatt darauf zu hoffen, dass das Modell auf dem neuesten Stand ist.
Die Aufgabe fügt ein Paket, SDK, Framework, Plugin, CLI, Modell, Cloud-Ressource oder eine Anbieter-Integration hinzu, aktualisiert, konfiguriert oder importiert diese.
Die API unterliegt schnellen Änderungen oder ist versionsabhängig: KI-SDKs, OpenAI/Anthropic/Google- APIs, Next.js, React, Tailwind, Vite, Nitro, Drizzle, Prisma, Stripe, GitHub, Slack, Notion, Browser-APIs, Bereitstellungsplattformen, Authentifizierungsbibliotheken und Ähnliches.
Die Implementierung hängt von Authentifizierung, OAuth-Bereichen, Berechtigungen, Geheimnissen, Webhooks, Abrechnung, Zahlungen, personenbezogenen Daten, Verschlüsselung, Datenaufbewahrung, Migrationen, Wiederholungsversuchen, Ratenbeschränkungen, Kontingenten, Caching, Bereitstellungen oder Compliance ab.
Ein Fehler bezieht sich auf Veralterung, unbekannte Optionen, fehlende Exporte, ungültige Konfiguration, nicht unterstützte Felder, geänderte Standardwerte oder Versionsinkompatibilität.
Ein Repo enthält lokale Dokumentationen, ADRs, generierte Schemata, OpenAPI-Spezifikationen, Routen-/Aktions- Register, Design-System-Dokumentationen oder READMEs auf Paketebene, die den Vertrag definieren könnten.
Die Entscheidung lässt sich nur mit hohem Aufwand rückgängig machen: öffentliche Datenübertragungsformate, Datenbankschema, Migrationsstrategie, persistente IDs, Ereignisnamen, für den Kunden sichtbares Verhalten oder externe Automatisierungsverträge.
Man ertappt sich dabei, wie man „normalerweise“, „wahrscheinlich“, „ich glaube“, „aus dem Kopf“ oder aus dem Modellspeicher kopierten Code für eine externe API schreiben will.

Was als Dokumentation gilt

Verwenden Sie die maßgeblichste verfügbare Quelle:

Lokale Repo-Dokumentationen, Spezifikationen, ADRs, Schemata, generierte Typen, READMEs auf Paketebene und Tests für projektspezifisches Verhalten.
Offizielle Produktdokumentationen, API-Referenzen, Migrationsanleitungen, Changelogs, Release- Notes sowie SDK-Quellcode und -Typen für das Verhalten von Drittanbietern. Suchen Sie diese über eine Websuche, wenn Sie die genaue URL noch nicht haben.
Metadaten aus der Paketregistrierung für Versionen. Bevor Sie eine Abhängigkeit hinzufügen, führen Sie npm view version, pnpm view versionoder das entsprechende Äquivalent im Ökosystem aus und lesen Sie anschließend die Dokumentation für diese Hauptversion.
Quellcode oder Typdefinitionen, wenn die offizielle Dokumentation unvollständig ist. Betrachten Sie dies als Beleg, nicht als Volksweisheit.

Vermeiden Sie Stack Overflow, alte Blogbeiträge, zufällige Codeausschnitte und Ihr Gedächtnis als primäre Quelle, wenn offizielle Dokumentationen vorhanden sind. Nutzen Sie Community-Quellen nur zur Fehlerbehebung , nachdem der verbindliche Vertrag bekannt ist.

Erforderlicher Arbeitsablauf

Identifizieren Sie die genaue Schnittstelle: Paketname, installierte Version, Zielversion, Anbieter-Endpunkt, CLI-Befehl, Konfigurationsdatei, lokaler Helper, Schema oder Produktfunktion.
Durchsuchen Sie das Internet nach der aktuellen offiziellen Dokumentation, es sei denn, die relevanten Dokumente sind bereits lokal vorhanden oder der Benutzer hat eine URL angegeben. Verwenden Sie gezielte Suchanfragen wie official docs, migration guide, oder API reference.
Öffnen und lesen Sie die Dokumentation, die dieser Oberfläche am nächsten kommt. Bevorzugen Sie zunächst lokale Dokumentation für internen Code, dann offizielle Upstream-Dokumentation. Überprüfen Sie bei neuen Paketen die neueste Version, bevor Sie Import-, Konfigurations- oder Installationsbefehle schreiben.
Extrahieren Sie die wenigen für die Aufgabe benötigten Fakten: Optionsnamen, Importe, Lebenszyklus- Regeln, Standardverhalten, kompatibilitätsbrechende Änderungen, Beschränkungen, Berechtigungen und Beispiele für die aktuelle Hauptversion.
Implementiere oder beantworte die Frage anhand dieser Fakten. Wenn die Dokumentation im Widerspruch zum bestehenden Code steht, überprüfe den lokalen Codepfad und weise auf die Diskrepanz hin.
Überprüfen Sie dies mit der kleinsten sinnvollen Prüfung: Typprüfung, Tests, Build, CLI-Trockenlauf, API-Schema-Validierung oder einer lokalen Reproduktion.
Nennen Sie in der endgültigen Antwort die Dokumentation oder lokalen Dateien, auf die Sie zurückgegriffen haben, wenn diese Informationen die Empfehlung oder Umsetzung beeinflussen.

Beispiele, die zur Erstellung von Dokumentation führen müssen

„Füge Tailwind zu dieser App hinzu.“ Überprüfe die aktuelle Tailwind-Hauptversion und die zugehörige Installationsdokumentation im Internet, bevor du Konfigurationsdateien erstellst oder von einer alten PostCSS-Konfiguration ausgehst.
„Verwende das AI-SDK, um Antworten zu streamen.“ Überprüfe die aktuelle Hauptversion des AI-SDK, Importe, Namen der Anbieterpakete, Streaming-Helfer sowie Server-/Laufzeit- Beispiele anhand der offiziellen Dokumentation.
„Stripe-Webhooks einbinden.“ Lies vor dem Programmieren die aktuellen Stripe-Dokumentationen zur Signaturüberprüfung, zu Ereigniswiederholungen, zu Endpunkt-Geheimnissen und zum Parsen von Framework-Body-Daten.
„Behebe diesen Next.js-Caching-Fehler.“ Lies die Dokumentation zur installierten Next.js-Hauptversion und zum Router-Modus, bevor du Annahmen zur Semantik der Cache-Invalidierung triffst.
„Füge Drizzle-Migrationen hinzu.“ Lies die aktuellen Drizzle-Kit-Dokumentationen und die bestehenden Migrationskonventionen des Repos, bevor du Dateien generierst.
„Erstellen Sie eine GitHub-Action.“ Lesen Sie die offiziellen Dokumentationen zu Syntax und Berechtigungen von Actions, insbesondere zu pull_request, workflow_runOIDC, Tokens und Artefakte.
„Warum schlägt dieser OAuth-Ablauf fehl?“ Lies die Dokumentation des Anbieters zu Bereichen, Umleitungs-URIs, PKCE, Token-Aktualisierung und App-Verifizierung, bevor du den Code änderst.
„Das Plan-/Kommentar-/Aktionssystem dieses Repos nutzen.“ Lesen Sie die lokalen Dokumentationen, die Routen-/Aktionsregister, Schemas und Tests, bevor Sie Endpunkte oder Props definieren.
„Vite/Nitro/React aktualisieren.“ Lies den Migrationsleitfaden für die genaue Ziel- Hauptversion, bevor du die Konfiguration oder Importe bearbeitest.
„Welches Modell sollten wir verwenden?“ Lies die aktuellen Modelldokumente des Anbieters, die Seiten zu Preisen und Limits sowie die SDK-Beispiele, bevor du eine Empfehlung aussprichst.

Wenn ein kurzer Blick in die lokale Dokumentation ausreicht

Durchsuche nicht für jede noch so kleine Änderung das Internet. Ein Blick in die Dokumentation kann lokal und kurz ausfallen, wenn die Antwort bereits im Repo zu finden ist: Verwendung bestehender Helper, nahegelegene Tests, typisierte Schnittstellen, generierte Clients, ADRs oder READMEs der Pakete. Wenn die Aufgabe jedoch von einem externen Tool, Paket, Anbieter oder dem aktuellen Produktverhalten abhängt, ist eine Websuche in der Regel der richtige erste Schritt. Bei trivialer Sprachsyntax, der Korrektur von Tippfehlern, der Formatierung oder in sich geschlossenem Code ohne externe Abhängigkeiten kannst du wie gewohnt vorgehen.

Wenn keine Dokumentation verfügbar ist

Wenn Netzwerkzugriff, Authentifizierung oder fehlende lokale Dateien das Lesen der Dokumentation verhindern, weisen Sie deutlich darauf hin, bevor Sie sich auf Ihr Gedächtnis verlassen. Grenzen Sie die Unsicherheit ein, überprüfen Sie den Quellcode oder die Typen, sofern verfügbar, und vermeiden Sie es, das Ergebnis als „bestätigt aktuell“ darzustellen.

Auf GitHub ansehen

---
name: read-the-damn-docs
description: Forces web searches and reading of official docs before implementing, integrating, or debugging third-party APIs, libraries, and services to ensure accuracy and avoid guesswork.
---

# Read The Damn Docs

Do not guess where authoritative docs can answer the question. The most common
right move is to web-search for the current official docs, open the relevant
pages, and read them before coding. For APIs, versions, provider behavior,
config, limits, lifecycle hooks, or security-sensitive flows, ground the answer
in what the docs actually say.

## Docs-First Triggers

Read docs before proceeding when any of these are true:

- The user asks for "latest", "current", "official", "supported", "best
  practice", "recommended", "today", "now", or "look it up".
- The needed docs are not already in the repo or supplied by the user. Search
  the web for the official docs rather than hoping model memory is current.
- The task adds, upgrades, configures, or imports a package, SDK, framework,
  plugin, CLI, model, cloud resource, or provider integration.
- The API is fast-moving or version-sensitive: AI SDKs, OpenAI/Anthropic/Google
  APIs, Next.js, React, Tailwind, Vite, Nitro, Drizzle, Prisma, Stripe, GitHub,
  Slack, Notion, browser APIs, deployment platforms, auth libraries, and similar.
- The implementation depends on auth, OAuth scopes, permissions, secrets,
  webhooks, billing, payments, PII, encryption, data retention, migrations,
  retries, rate limits, quotas, caching, deploys, or compliance.
- An error mentions deprecation, unknown options, missing exports, invalid
  config, unsupported fields, changed defaults, or version mismatch.
- A repo has local docs, ADRs, generated schemas, OpenAPI specs, route/action
  registries, design-system docs, or package-level READMEs that could define the
  contract.
- The choice is expensive to reverse: public wire formats, database schema,
  migration strategy, persistent IDs, event names, customer-visible behavior, or
  external automation contracts.
- You catch yourself about to write "usually", "probably", "I think", "from
  memory", or code copied from model memory for an external API.

## What Counts As Docs

Use the most authoritative source available:

- Local repo docs, specs, ADRs, schemas, generated types, package READMEs, and
  tests for project-specific behavior.
- Official product docs, API references, migration guides, changelogs, release
  notes, and SDK source/types for third-party behavior. Find these with web
  search when you do not already have the exact URL.
- Package registry metadata for versions. Before adding a dependency, run
  `npm view <pkg> version`, `pnpm view <pkg> version`, or the ecosystem
  equivalent, then read the docs for that major version.
- Source code or type definitions when official docs are incomplete. Treat this
  as evidence, not folklore.

Avoid Stack Overflow, old blog posts, random snippets, and memory as the primary
source when official docs exist. Use community sources only to debug symptoms
after the authoritative contract is known.

## Required Workflow

1. Identify the exact surface: package name, installed version, target version,
   provider endpoint, CLI command, config file, local helper, schema, or product
   feature.
2. Search the web for the current official docs unless the relevant docs are
   already local or the user supplied a URL. Use targeted searches such as
   `<product> <feature> official docs`, `<package> migration guide`, or
   `<provider> API reference`.
3. Open and read the docs closest to that surface. Prefer local docs first for
   internal code, then official upstream docs. For new packages, verify the
   latest version before writing imports, config, or install commands.
4. Extract the few facts needed for the task: option names, imports, lifecycle
   rules, default behavior, breaking changes, limits, permissions, and examples
   for the current major version.
5. Implement or answer using those facts. If the docs conflict with existing
   code, inspect the local code path and call out the discrepancy.
6. Verify with the smallest useful check: typecheck, tests, build, CLI dry run,
   API schema validation, or a local reproduction.
7. In the final answer, name the docs or local files consulted when that
   evidence affects the recommendation or implementation.

## Examples That Must Trigger Docs

- "Add Tailwind to this app." Check the current Tailwind major and its install
  docs from the web before creating config files or assuming old PostCSS setup.
- "Use the AI SDK to stream responses." Verify the current AI SDK major,
  imports, provider package names, streaming helpers, and server/runtime
  examples from official docs.
- "Wire up Stripe webhooks." Read Stripe's current signature verification,
  event retry, endpoint secret, and framework body-parsing docs before coding.
- "Fix this Next.js caching bug." Read the docs for the installed Next.js major
  and router mode before assuming cache invalidation semantics.
- "Add Drizzle migrations." Read the current Drizzle kit docs and existing repo
  migration conventions before generating files.
- "Create a GitHub Action." Read official Actions syntax and permissions docs,
  especially for `pull_request`, `workflow_run`, OIDC, tokens, and artifacts.
- "Why does this OAuth flow fail?" Read the provider's scopes, redirect URI,
  PKCE, token refresh, and app verification docs before changing code.
- "Use this repo's plan/comment/action system." Read local docs, route/action
  registries, schemas, and tests before inventing endpoints or props.
- "Upgrade Vite/Nitro/React." Read the migration guide for the exact target
  major before editing config or imports.
- "What model should we use?" Read current provider model docs, pricing/limits
  pages, and SDK examples before recommending.

## When A Quick Local Read Is Enough

Do not browse the web for every tiny edit. A docs pass can be local and brief
when the answer is already in the repo: existing helper usage, nearby tests,
typed interfaces, generated clients, ADRs, or package READMEs. But if the task
depends on an external tool, package, provider, or current product behavior, web
search is usually the right first step. For trivial language syntax, typo fixes,
formatting, or self-contained code with no external contract, proceed normally.

## If Docs Are Unavailable

If network access, auth, or missing local files prevents reading the docs, say
that plainly before relying on memory. Narrow the uncertainty, inspect source or
types if available, and avoid presenting the result as confirmed-current.