家

Skill

生産性とワークフロー

read-the-damn-docs

BuilderIO/skills

サードパーティのAPI、ライブラリ、サービスを実装、統合、またはデバッグする前に、Web検索や公式ドキュメントの精読を徹底し、正確性を確保するとともに、当て推量を避けるようにしています。

...すべて拡張します

更新された時間 2026年9月6日

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

「そのドキュメントをちゃんと読め」

信頼できるドキュメントで疑問が解決できる場合は、推測してはいけない。最も一般的で正しい方法は、最新の公式ドキュメントをウェブ検索し、関連するページを開いて、コーディングする前にそれらを読むことです。API、バージョン、プロバイダーの動作、設定、制限、ライフサイクルフック、またはセキュリティ上重要なフローについては、ドキュメントに実際に書かれている内容に基づいて答えを導き出してください。

「ドキュメント優先」のきっかけ

以下のいずれかに該当する場合は、作業を進める前にドキュメントを読んでください：

ユーザーが「最新」「現在」「公式」「サポート対象」「ベストプラクティス」「推奨」「今日」「今」「調べて」といった言葉を要求した場合。
必要なドキュメントがリポジトリにまだ含まれていない、またはユーザーから提供されていない場合。モデルの記憶が最新であることを期待するのではなく、ウェブで公式ドキュメントを検索してください。
タスクが、パッケージ、SDK、フレームワーク、プラグイン、CLI、モデル、クラウドリソース、またはプロバイダー連携の追加、アップグレード、設定、またはインポートを伴う場合。
APIの変更が頻繁であるか、バージョンに依存する：AI SDK、OpenAI/Anthropic/Google API、Next.js、React、Tailwind、Vite、Nitro、Drizzle、Prisma、Stripe、GitHub、 Slack、Notion、ブラウザAPI、デプロイメントプラットフォーム、認証ライブラリなど。
実装には、認証、OAuthスコープ、権限、シークレット、 Webhook、課金、支払い、PII、暗号化、データ保持、移行、再試行、レート制限、クォータ、キャッシュ、デプロイ、またはコンプライアンスが関係します。
エラーには、非推奨、不明なオプション、エクスポートの欠落、無効な設定、サポートされていないフィールド、変更されたデフォルト値、またはバージョンの不一致などが含まれます。
リポジトリには、ローカルドキュメント、ADR、生成されたスキーマ、OpenAPI仕様、ルート／アクションレジストリ、デザインシステムドキュメント、あるいはパッケージレベルのREADMEなどがあり、これらが契約を定義する可能性があります。
その選択を元に戻すには多大なコストがかかる：公開ワイヤ形式、データベーススキーマ、移行戦略、永続的なID、イベント名、顧客に可視化される動作、または外部自動化契約など。
外部APIのドキュメントを作成する際、「通常」「おそらく」「と思う」「記憶では」といった表現を使おうとしたり、モデルの記憶からコードをコピーしようとしたりする自分に気づく。

ドキュメントとして認められるもの

入手可能な最も信頼性の高い情報源を使用してください：

ローカルリポジトリのドキュメント、仕様書、ADR、スキーマ、生成された型、パッケージのREADME、およびプロジェクト固有の挙動に関するテスト。
サードパーティの挙動については、公式の製品ドキュメント、APIリファレンス、移行ガイド、変更履歴、リリースノート、およびSDKのソースコード／型定義。正確なURLが分からない場合は、Web 検索でこれらを探してください。
バージョンに関するパッケージレジストリのメタデータ。依存関係を追加する前に、 npm view version, pnpm view version、またはエコシステム内の同等のコマンドを実行し、そのメジャーバージョンのドキュメントを参照してください。
公式ドキュメントが不完全な場合のソースコードや型定義。これを伝承ではなく、証拠として扱うこと。

公式ドキュメントが存在する場合は、Stack Overflow、古いブログ記事、無作為なスニペット、および記憶を主要な情報源として使用することを避けてください。コミュニティの情報源は、信頼できる仕様が判明した後の症状のデバッグにのみ使用してください。

必須のワークフロー

対象を正確に特定する：パッケージ名、インストール済みバージョン、ターゲットバージョン、プロバイダーのエンドポイント、CLIコマンド、設定ファイル、ローカルヘルパー、スキーマ、または製品の機能。
関連するドキュメントがすでにローカルにあるか、ユーザーからURLが提供されていない限り、現在の公式ドキュメントをウェブで検索する。次のようなターゲットを絞った検索を使用する official docs, migration guide、または API reference.
その対象に最も近いドキュメントを開いて読みます。内部コードについては、まずローカルのドキュメントを優先し、次に公式のアップストリームドキュメントを参照します。新しいパッケージについては、インポート、設定、またはインストールコマンドを記述する前に、最新バージョンを確認してください。
タスクに必要な少数の事実（オプション名、インポート、ライフサイクルルール、デフォルトの動作、互換性を破る変更、制限、権限、および現在のメジャーバージョンに関する例）を抽出する。
それらの事実に基づいて実装または回答を行います。ドキュメントが既存のコードと矛盾する場合は、ローカルのコードパスを調査し、その不一致を指摘してください。
最小限の実用的なチェック（型チェック、テスト、ビルド、CLIのドライラン、 APIスキーマの検証、またはローカルでの再現）で検証してください。
最終的な回答では、その根拠が推奨事項や実装に影響を与える場合、参照したドキュメントやローカルファイルの名前を明記する。

ドキュメント作成が必須となる例

「このアプリに Tailwind を追加する」。設定ファイルを作成したり、古い PostCSS の設定を前提としたりする前に、ウェブ上の現在の Tailwind のメジャーバージョンとそのインストールドキュメントを確認してください。
「AI SDK を使用してレスポンスをストリーミングする。」公式ドキュメントから、現在の AI SDK のメジャーバージョン、インポート、プロバイダーのパッケージ名、ストリーミングヘルパー、およびサーバー／ランタイムのサンプルを確認してください。
「StripeのWebhookを接続する。」コーディングを行う前に、Stripeの最新の署名検証、イベントリトライ、エンドポイントシークレット、およびフレームワークのボディ解析に関するドキュメントを読む。
「この Next.js のキャッシュバグを修正する。」キャッシュ無効化の挙動を想定する前に、インストール済みの Next.js のメジャーバージョンおよびルーターモードに関するドキュメントを参照してください。
「Drizzleのマイグレーションを追加する。」ファイルを生成する前に、最新のDrizzleキットに関するドキュメントと、既存のリポジトリにおけるマイグレーションの規約を確認してください。
「GitHub Actionを作成する」。公式のActionsの構文および権限に関するドキュメント、特に pull_request, workflow_run、OIDC、トークン、およびアーティファクトに関するドキュメントを必ず確認してください。
「なぜこの OAuth フローは失敗するのか？」コードを変更する前に、プロバイダーのスコープ、リダイレクト URI、 PKCE、トークンの更新、およびアプリ検証に関するドキュメントを読んでください。
「このリポジトリのプラン／コメント／アクションシステムを使用する。」エンドポイントやプロパティを考案する前に、ローカルドキュメント、ルート／アクションレジストリ、スキーマ、およびテストを熟読してください。
「Vite/Nitro/React をアップグレードする。」設定やインポートを編集する前に、移行ガイドを参照して、正確な対象となるメジャーバージョンを確認してください。
「どのモデルを使うべきか？」提案する前に、現在のプロバイダーのモデルに関するドキュメント、料金・利用制限のページ、およびSDKのサンプルを確認してください。

「リポジトリ内の情報をざっと確認するだけで十分な場合」

些細な編集のたびにウェブを検索してはいけません。答えがリポジトリ内（既存のヘルパーの使用法、近隣のテスト、型付きインターフェース、生成されたクライアント、ADR、またはパッケージのREADMEなど）にすでに存在する場合、ドキュメントの確認はローカルで簡潔に行うことができます。しかし、タスクが外部ツール、パッケージ、プロバイダー、または現在の製品の挙動に依存する場合は、通常、ウェブ検索が適切な最初のステップとなります。些細な言語構文、タイプミスの修正、フォーマット、または外部との契約を伴わない独立したコードについては、通常通り進めてください。

ドキュメントが利用できない場合

ネットワークへのアクセス、認証、またはローカルファイルの欠如によりドキュメントを参照できない場合は、記憶に頼る前にその旨を明言してください。不確実性を絞り込み、可能であればソースコードや型を確認し、結果を「最新かつ確定済み」として提示することを避けてください。

GitHubで見る

---
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.