agent-ready

エージェント対応

公開されているエージェント対応スコア、またはエージェントがナビゲーションに失敗したログを、リリース済みで検証済みの HTTP とドキュメントの変更に結び付けます。

• 対象： Mintlify Agent Score／AFDocs、Is Agentic、Is It Agent Ready、または url-discovery-bench の調査結果と、エージェントによるサーバー側の 404 の証拠を取り込み、リポジトリを調査し、該当するプロトコルを実装してテストを追加し、稼働中のレスポンスを検証します。
• 対象外： ドキュメントの文章の書き換え（ghostwriter）、パッケージ／CLI／SDK の使いやすさ（dx-audit）、製品内のエージェントを信頼できるかどうか（ax-audit）、検索順位、クローラーポリシー、Next.js の llms.txt／Markdown ルート（seo。このスキルが担当するのは、それらのルートが満たすべき AFDocs と Is Agentic の要件です）、リポジトリの指示ファイル（agents-md）。vercel-labs/is-agentic をベンダーとして取り込まないでください。そのスキルはレポートを取得するものです。このスキルは製品に変更を実装します。

目次

• ワークフロー
• 参照ファイル
• 優先度
• 出力
• 注意点

ワークフロー

Agent-ready progress:
- [ ] Step 1: Ingest the report, the agent 404 log, or run scanners against the public URL
- [ ] Step 2: Inspect the existing codebase before any edit
- [ ] Step 3: Inventory every knowledge surface the origin serves and map each finding to a real one; skip surfaces the product does not offer
- [ ] Step 4: Load the matching reference and implement the map first, then failures, then warnings. For Next.js App Router `llms.txt` and markdown routes, load `seo` (that skill's `nextjs-implementation.md` and `answer-engines.md`) instead of a second recipe.
- [ ] Step 5: Add or update tests for every behavior you change
- [ ] Step 6: Verify every public endpoint and machine-readable file you touched (`scripts/check-surfaces.sh`, then the curl recipes for anything it does not cover)
- [ ] Step 7: Report changes, quoted verification, and remaining product decisions

貼り付けられたスコアカードを仕様として扱います。スコアカードがなく、ユーザーが公開 URL を指定している場合は、レポートを取得します。

pnpm dlx afdocs check <docs-url> --format scorecard --sampling deterministic
pnpm dlx is-agentic <domain> --json

Is It Agent Ready：POST https://isitagentready.com/api/scan に {"url":"<origin>","format":"agent"} を送信します。ユーザーが貼り付けたレポートと新しいスキャン結果の両方がある場合は、貼り付けられたレポートを優先します。

サーバーログも依頼内容の一部です。エージェントはサーバー側で取得し、JavaScript を実行しないため、クライアント側の分析には表示されません。.md URL、llms.txt、認識済みの AI ユーザーエージェントへのリクエスト数を数え、それらのエージェントからの 404 が続く場合（取得、404、隣接パスを推測、再試行）は、失敗したチェックとして扱います。ログクエリとナビゲーションベンチマークについては、references/verification.md を参照してください。

ステップ 3 の対象は /docs だけでなく、オリジン全体です。変更履歴、リリースノート、ヘルプセンター、コミュニティ、ステータスページも、エージェントが回答を作成する際の情報源です。通常、ドキュメントが対応済みでも、これらのページは HTML のみです。Markdown のミラーとインデックスへのエントリーを追加するかどうかは、サーフェスごとに判断します。マーケティングページは対象外です。

ビジュアルデザインと既存の製品動作を維持してください。変更するのは発見方法、表現形式、ヘッダー、文書化された要件であり、機能セットではありません。

本番環境に接続できないローカルテストスイートは、安全に実行し、修正して再実行できます。許可なくデプロイしたり、DNS を変更したり、レジストリ名を購入したり、作業ツリーの外に書き込んだりしないでください。

対象範囲内の失敗したチェックすべてにコードまたはコンテンツの変更が行われる（または理由を明記して明示的にスキップされる）こと、新しい動作をテストでカバーすること、ステップ 6 で実際にアクセスした環境からステータス、Content-Type、関連するヘッダーまたは本文を引用することが完了条件です。

参照ファイル

ファイル	参照するタイミング
references/docs-afdocs.md	Mintlify Agent Score、AFDocs、llms.txt、.md URL、Markdown ミラー内のインデックスリンク、Accept ネゴシエーション、ページサイズ、認証ゲート、ドキュメント以外のナレッジサーフェス
references/api-surfaces.md	Is Agentic のレポートがある場合：必須チェック（JavaScript なしでのコンテンツ取得、エージェントに配慮した 404）、JSON エラー、OpenAPI、バージョン管理、レート制限、関数呼び出し、CLI、MCP
references/site-discovery.md	Is It Agent Ready：robots、サイトマップ、Link ヘッダー、DNS-AID、Well-Known カタログ、ボットルール
references/verification.md	ステップ 6：check-surfaces.sh、curl のレシピ、サーバーログの計測、url-discovery-bench、証拠として認められるもの

優先順位

エージェントはMarkdownを問題なく読めますが、ナビゲーションでつまずきます。Mintlifyの2026年のベンチマーク（2,400件のタスク、20のドキュメントサイト、ClaudeおよびCodex）では、どの形式でも精度は94〜99％を維持しました。一方、タスクごとのリクエスト失敗数は、HTMLでは2.23件、プレーンなMarkdownでは1.42件、各Markdownページからllms.txtにリンクすると0.11件でした。作業は次の順に進めてください。

1. マップ：ドキュメントホストにllms.txtを配置し、すべてのMarkdown版ページの冒頭にリンクを追加して、両方を告知するLinkヘッダーを設定します。エージェントは、.mdとllms.txtの存在を把握している場合に限り、それらをリクエストします。
2. 実際に製品で発生している問題（エージェントが読めないドキュメントHTML、実際のAPIでのHTMLエラーページ、代替手段のないアクセス制限付きの公開ドキュメント）。
3. それらと同じサーフェス上の警告（llms.txtの網羅性、見つけにくいディレクティブ、誤ったContent-Type）。
4. リポジトリ内にすでに該当するサーフェスがある場合の推奨チェック（OpenAPI、MCP、OAuth）。
5. 新たな追加項目（コマースプロトコル、A2A、DNS-AID）は、製品がすでに提供している場合、またはユーザーから追加を依頼された場合に限ります。

MCP サーバーがないサイトにMCPカードがないことは、問題ではありません。評価点を稼ぐためにAPI、CLI、決済プロトコルをでっち上げないでください。

出力

作業をチェック項目ごとにまとめてください。それぞれについて、レポートからの根拠、変更したファイル、追加した正確なマークアップまたはスキーマ、検証時の引用、該当しない場合はその理由を記載してください。依頼内容が404ログまたはベンチマークの場合は、変更前後のタスクごとのリクエスト失敗数を引用してください。

最後に、製品上の判断、DNSへのアクセス、または認証情報が必要な残りの項目をまとめてください。

注意点

• is-agentic.com/scan/<domain>には、数か月前のものかもしれない最新の保存済みスナップショットが表示されます。依頼内容として扱う前にスナップショットの日付を確認し、Rescanを押す（またはCLIを実行する）ようにしてください。検証のために、再度スキャンしてください。
• .md版にはナビゲーションがありません。変換時にクロームごと取り除かれているためです。どのページでも漏れないように、.md版のルートからllms.txtへのリンクを出力してください。ページごとに編集すると差異が生じます。
• Markdown版は単一のアプリ内のルートです。同じオリジン上に変更履歴やブログを提供する別のマーケティングアプリがある場合、誰も判断していないままHTMLのみになっています。Markdown版ルートのあるアプリだけでなく、すべてのアプリを確認してください。
• 1つのllms.txtを3通り（プロキシのrel="llms-txt"、フレームワークヘッダーのrel="https://llmstxt.org/rel/llms-txt"、レイアウトの<link>にあるrel="describedby"）で告知すると、そのレスポンスでどのレイヤーが優先されるかによって、スキャナーが読み取るものが変わります。スキャナーが確認するrelのセットを選び、1か所から出力してください。
• Markdown版が存在するのに、llms.txtにHTMLを記載すると、エージェントをMarkdownから遠ざけることになり、最初から.mdにリンクするより低く評価されます。
• <head>、ナビゲーション、またはHTML本文の50％より後にあるディレクティブはカウントされません。ドキュメント本文の先頭付近に、サーバーサイドでレンダリングして配置してください。
• エージェントからのアクセスがないダッシュボードは、何の証拠にもなりません。エージェントはJavaScriptを実行しません。また、Search ConsoleやSERPツールが数えるのは検索ユーザーであり、エージェントではありません。.md、llms.txt、AIユーザーエージェントのリクエストに関するサーバーログだけが、閲覧状況を測る手段です。ログの送信先がなければ、正直な値はクライアント側の代替指標ではなく「データなし」です。
• クローラー向けに調整されたボット対策（チャレンジページ、WAFのボットルール、text/markdownルートへの厳しいレート制限）は、最適化の対象であるエージェントをブロックします。エージェントはチャレンジを通過できません。機械可読なルートを除外するか、ルールの適用対象外のパスから提供してください。
• 網羅性の不合格と厳選インデックスは別です。サイトが同等の網羅性を意図している場合は、サイトマップから再生成してください。インデックスが意図的なものであれば、その旨を明記し、マーケティングURLを追加して水増ししないでください。

保守作業のみ：evals/evals.jsonはこのスキルを変更するためのものであり、ユーザーのタスクには使いません。