seo-maker

@rules/seo-workflow.md @rules/validation.md

SEO Maker

従来の検索エンジンと AI 回答エンジン全体における、プロジェクトの検索での可視性を監査し、改善します。

<instruction_contract>

項目	契約
意図	名前を指定した対象について、根拠の確度を評価した SEO／AEO／GEO／LLMO 監査と、優先順位付きの実行可能な最適化レポートを作成します。また、ユーザーが達成可能な最高スコアを求めた場合は、範囲を限定したスコア改善ループを実行します。
範囲	対象の分類、測定方法の選択、オンページ／技術／コンテンツ／Core Web Vitals／AEO／GEO／LLMO の評価、スコアリング、指摘事項、推奨事項、およびレポートの作業領域を担当します。監査対象外での実装、リリース判定、ページや製品の設計、対象サイトまたはコンテンツ一式のない広範な市場調査は担当しません。
権限	システム／ハーネスおよびユーザーの指示 > 監査対象自身のファイルとライブ観測結果 > プラットフォームの公式ドキュメント > このスキル > ヒューリスティックな選好。ツール、ラボ、合成データ、またはヒューリスティックによる観測を、公式要件として扱ってはいけません。
根拠	スコアリングの前に、対象自身のファイル、レンダリングされたページ、およびライブレスポンスを確認し、重大な指摘と警告のそれぞれについて、根拠となるコマンド、URL、ファイルパス、またはプローブ結果を引用します。確認できない項目は unknown、該当しない項目は not-applicable と記録します。スコア、ランキング、掲載実績、引用を捏造してはいけません。
ツール	利用可能な読み取り／検索／ブラウザーツールを使用し、scripts/render-dashboard.mjs <artifact-dir> でダッシュボードをレンダリングします。ウェブ検索、ブラウザーによる検査、フィールド Core Web Vitals、Search Console、AI 引用プローブは、実際に利用できる場合に限り使用します。利用できないものがある場合は、機能上の制限を明記し、利用可能な中で最も確度の高い下位の方法に切り替えます。
ループ	最適化モードのみ：範囲を限定した audit -> fix or recommendation -> re-audit サイクルを、デフォルトでは 3 回のイテレーションを上限として実行します。フィードバック = 比較可能な再監査の根拠、指標 = unknown と not-applicable のカテゴリを除外した 100 点満点のスコア、ガード = 比較可能なカテゴリでの後退がなく、根拠の確度が引き上げられていないこと、停止条件 = 目標達成、予算消化、停滞、ガード失敗、または外部認証情報やビジネス上の判断が必要な作業。
出力	複雑なモードまたは最適化モードでは .hyper/seo-maker/[slug]/ に results.json、results.js、dashboard.html、report.md、sources.md、flow.json を格納します。シンプルモードでは、最低限 report.md と sources.md を作成します。sources.md は、URL、日付、該当する主張、根拠の区分、制限事項を記録した情報源台帳です。
検証	完了時に rules/validation.md を適用します。重大な指摘と警告にはすべて根拠を付け、スコアは観測した根拠から算出し、unknown と not-applicable を明示的に扱います。最適化モードでは、ベースライン、評価者、予算、ガード、破棄したイテレーション、停止理由、および比較可能な検証済み結果のうち最良のものを記録します。パッケージに変更を加えた場合は、対象を絞ったコーパスバリデーター、リポジトリ標準ゲート、およびパッケージテストも実行します。
停止条件	根拠の確度を評価した監査またはレポートが完了し、未解決の重大な不足がなくなった時点、または最適化モードで目標、予算、停滞、ガード条件、外部依存のいずれかに達した時点で停止します。根拠で裏付けられないランキング、AI 機能への掲載、引用を主張して停止してはいけません。

</instruction_contract>

<output_language>

この標準スキルファイルが英語で書かれていても、ユーザー向けの納品物、保存する成果物、レポート、計画、生成ドキュメント、要約、引き継ぎメモ、コミット／メッセージの下書き、検証メモは、特に指定がない限り韓国語にします。

ソースコードの識別子、CLI コマンド、ファイルパス、スキーマキー、JSON／YAML のフィールド名、API 名、パッケージ名、固有名詞、引用したソースの抜粋は、指定された言語または原文の言語のまま保持します。 ユーザーが明示的に別の言語を求めている場合、既存のターゲット成果物を一貫性のために別の言語のままにする必要がある場合、または機械可読な契約で英語のトークンが正確に必要な場合に限り、別の言語を使用してください。ローカライズされたテンプレートや参照資料（例：*.ko.md や *.ko.json）がある場合は、ユーザー向けの成果物ではそちらを優先してください。

</output_language>

• ウェブサイトまたはプロジェクトの SEO を体系的に監査します。
• オンページ SEO、テクニカル SEO、コンテンツ SEO、Core Web Vitals を網羅します。
• 強調スニペット、音声検索、直接回答の表示面に対する AEO の準備状況を評価します。
• 生成 AI の回答で引用される可能性に関する GEO の準備状況を評価します。
• AI クローラーへのアクセス、鮮度、モデルが読み取り可能なコンテキストに関する LLMO の準備状況を評価します。
• 優先度を付けた推奨事項と根拠を .hyper/seo-maker/[slug]/ に保存します。
• 既存のレポートを更新し、SEO 改善の履歴を追跡可能な状態に保ちます。
• ユーザーが最高スコア、最大スコア、満点、完璧なスコア、または継続的な改善を求めた場合は、監査から修正・推奨事項の適用、再監査までのループを実行し、最良の結果を維持します。

<routing_rule>

主な成果が SEO/AEO/GEO/LLMO の監査、最適化レポート、または根拠に基づく検索可視性改善計画である場合は、seo-maker を使用します。

関連する作業は、以下のとおり別の場所に振り分けます。

• ページまたは製品の UI デザイン：designer または該当するフロントエンドデザインスキルを使用します。
• サイト監査を伴わない競合や市場の調査：research を使用します。
• 検索可視性監査ではなく、デプロイの可否判定のみを成果とするリリースゲートの確認：このスキルの対象外です。
• 検索に関する文脈を伴わない純粋なパフォーマンスエンジニアリング：該当するパフォーマンスまたは最適化のワークフローを使用します。
• ターゲットとなるサイトやコンテンツ群を指定しない、広範な AI 検索トレンドの調査：research を使用します。

</routing_rule>

<activation_examples>

該当する例：

• 「このサイトの SEO を監査してください。」
• 「メタデータと構造化データを確認してください。」
• 「SEO 監査レポートを作成してください。」
• 「検索エンジン最適化の状況を確認し、改善案を提示してください。」
• 「Core Web Vitals のスコアを改善する方法をまとめてください。」
• 「AI 検索エンジンが引用できるよう、コンテンツを最適化してください。」
• 「ChatGPT や Perplexity に自社ブランドが表示されるか確認してください。」
• 「AEO と GEO の観点からこのサイトを分析してください。」
• 「SEO スコアが可能な限り高くなるまで、修正を繰り返してください。」
• 「検索最適化スコアがほぼ満点になるまで、監査、修正、再検証を行ってください。」

該当しない例：

• 「このランディングページをデザインしてください。」→ designer を使用します。
• 「競合他社の市場での位置付けを調査してください。」→ research を使用します。
• 「デプロイ前にリリースチェックリストを確認してください。」→ 検索可視性の監査ではなく、デプロイ可否の判定です。

境界となる例：

• 「このページのパフォーマンスを最適化してください。」 SEO/Core Web Vitals への影響を通じてパフォーマンスを評価する場合に限り、seo-maker を使用します。
• 「AI 検索のトレンドを調査してください。」 対象サイト、ページ、またはコンテンツ一覧に結果を結び付ける場合に限り、seo-maker を使用します。

</activation_examples>

<trigger_conditions>

状況	モード
新しいプロジェクトまたはサイトの SEO 全体監査	create
特定のページのオンページ SEO レビュー	create
既存の SEO レポートに新しい分析を追加	update
Core Web Vitals またはテクニカル SEO の重点分析	create
SEO 改善後の再確認	update
最高スコアまたは満点を目指す反復的な改善	optimize
AEO/GEO の引用準備状況の分析	create
既存のレポートに AEO/GEO 分析を追加	update

</trigger_conditions>

<supported_targets>

• HTML ページと Next.js／React コンポーネントのメタデータおよび SEO 要素。
• robots.txt、sitemap.xml、llms.txt、canonical タグ、構造化データ。
• LCP、INP、CLS などの Core Web Vitals シグナル。
• title、meta description、Open Graph、Twitter Card などの <head> 要素。
• h1 から h6 までの見出し階層。
• 画像の代替テキストと内部リンク構造。
• AI の信頼性シグナルを含む Schema.org の JSON-LD マークアップ。
• Q&A 形式、直接回答の構造、強調スニペット向けの最適化などの AEO 要素。
• 引用可能な文章構造、出典付きの統計、エンティティの権威性などの GEO 要素。
• llms.txt、AI クローラーのアクセス性、コンテンツの鮮度などの LLMO 要素。
• 対象セットに Naver が含まれる場合に限り、Naver の検索面：Yeti クローラーのアクセス、Search Advisor の所有権確認、RSS とサイトマップの所有ドメインの一致、og:image の条件、nosourceinfo の適用範囲。
• 対象セットに Bing が含まれる場合に限り、Bing の検索面：IndexNow の変更通知（受領コードであり、インデックス登録や引用の証拠ではありません）、キー ファイルによる所有権の証明、POST ごとの送信上限、Bing のサイトマップフィールドの処理。

</supported_targets>

<complexity_routing>

複雑度	シグナル	対応
シンプル	単一ページのレビュー、SEO 要素が 1 つ、簡易メタデータ監査	直接：すぐに report.md を作成します
複雑	サイト全体の監査、多数のページ、テクニカル SEO とコンテンツ SEO と Core Web Vitals、競合比較	追跡：フェーズの追跡に flow.json を使用します

開始前に、次の内容を記録します。

Complexity: [simple/complex] — [one-line reason]
Mode: [create/update/optimize]
Target: [site/page/project path]
Proof surface: [commands, browser checks, web sources, or local files]

</complexity_routing>

<universal_intake>

プロジェクトのスコアリングを始める前に、このスキルがさまざまなスタックで機能するよう、監査のコンテキストを分類します。

• target_type：live-url、local-static、nextjs、react-spa、docs-site、ecommerce、blog、app-with-marketing-pages のいずれか
• access_level：ライブ URL、ローカルファイルのみ、Search Console を利用可能、アナリティクスを利用可能、フィールド Core Web Vitals を利用可能、AI 引用プローブを利用可能
• allowed_action：audit-only、recommend、edit-code、optimize-loop のいずれか
• measurement_confidence：ライブ URL、Search Console、フィールド Core Web Vitals、AI 引用プローブを利用できない場合は、信頼度を下げます
• evaluator：比較対象セット、スコアリング基準、ツール／バージョン、日付、エビデンスの取得経路

すべての指摘事項とスコアの入力情報は、official、live、field、tool、lab、synthetic、heuristic のいずれか 1 つに分類します。あるクラスを別のクラスのエビデンスとして扱わないでください。ローカルスキャンはライブやフィールドのエビデンスではなく、ツールやラボの結果は公式要件ではありません。

確認できない項目は unknown、該当しない項目は not-applicable として記録し、not-applicable の項目はカテゴリの分母から除外します。エビデンスの不足を隠さないでください。静的ファイル、ラボデータ、合成プローブ、ヒューリスティックに基づく推奨事項は、results.json でその旨を明示します。

ライブブラウジング、Search Console、フィールドデータ、AI プローブ、または名称が指定されたツールを利用できない場合は、利用可能な範囲で最も信頼度の高い下位の方法を使用し、機能上の制約と代替手段を明記します。また、ライブのパフォーマンス、ランキング、掲載、引用について断定しないでください。

</universal_intake>

<artifact_contract>

.hyper/seo-maker/[slug]/ を作成または更新します。

必要なファイル：

.hyper/seo-maker/[slug]/
├── dashboard.html      # Browser-readable dashboard
├── results.json        # Structured audit results
├── results.js          # File URL fallback for browser rendering
├── report.md           # Markdown report
├── sources.md          # Source and evidence log
└── flow.json           # Required for complex or optimize mode

シンプルモードでは、最低限 report.md と sources.md が必要です。複雑モードまたは最適化モードでは、すべてのファイルが必要です。

ファイルのスキーマについては、references/artifact-spec.md に従ってください。

新しいレポートでは、デフォルトで assets/report.template.ko.md を使用します。assets/report.template.md は、英語が明示的に必要な場合にのみ使用します。

レンダリング順：

1. 根拠を収集し、results.json を作成または更新します。
2. ローカルブラウザーで直接表示するための results.js を生成します。
3. 現在の結果から dashboard.html をレンダリングします。
4. リンクまたはファイル参照を記載した report.md と sources.md を作成します。sources.md は出典台帳です。外部または公式の主張ごとに、URL、アクセス日または公開日、該当する主張、証拠の分類、適用範囲または利用可能性に関する制限を記録します。

results.json が確定したら、scripts/render-dashboard.mjs <artifact-dir> でダッシュボードをレンダリングします。

複雑モードまたは最適化モードでは、flow.json で各フェーズを順番に追跡します。scope → measurement → technical → platform_policy → onpage → content → aeo → geo → report。

</artifact_contract>

<support_file_read_order>

次の順序で読み込みます。

1. コアの SKILL.md を読み、タスクが SEO／AEO／GEO 監査、最適化レポート、またはスコアループのいずれであるかを確認します。
2. 実行フェーズについては rules/seo-workflow.md を読みます。
3. E-E-A-T、Core Web Vitals、ランキング要因、エンティティ SEO、スキーママークアップの基準については references/seo-fundamentals.md を読みます。
4. AEO／GEO／LLMO 戦略、GEO CORE フレームワーク、プラットフォームのベンチマーク、llms.txt のガイダンスについては references/aeo-geo-guide.md を読みます。
5. 実践的な監査チェックリストについては references/seo-checklist.md を読みます。
6. results.json、ダッシュボードのライフサイクル、ワークスペースのスキーマについては references/artifact-spec.md を読みます。
7. 新しいレポートを作成する場合、デフォルトで assets/report.template.ko.md を読みます。英語が明示的に必要な場合に限り、assets/report.template.md を読みます。
8. ダッシュボードをレンダリングする際は、assets/dashboard-template.html を読みます。
9. 完了前に rules/validation.md を読みます。

</support_file_read_order>

フェーズ	タスク	出力
0	対象、モード、複雑さ、証拠の対象範囲、共通の初期入力項目を特定する	実行概要
1	測定方法と信頼度の限界を確立する	measurement_methods
2	ローカルコード、ページ、ブラウザーチェック、ウェブソースから証拠を収集する	証拠ログ
3	テクニカル SEO、プラットフォームポリシー、AEO、GEO、LLMO、Core Web Vitals、構造化データを監査する	構造化された指摘事項
4	公式要件を、現場／ツール／ラボ／合成／ヒューリスティックによる指摘事項と区別する	証拠レベル別の指摘事項
5	影響度、信頼度、工数、出典のランクに基づいて問題の優先順位を決める	推奨事項
6	成果物とダッシュボードを作成する	.hyper/seo-maker/[slug]/
7	最適化モードの場合、修正を適用または推奨し、再監査する	検証済みの最良結果
8	スコア、成果、信頼度の限界、リスク、次のアクションをまとめる	最終レポート

<audit_dimensions> 対象に関連する場合は、次の観点を監査します。テクニカルSEO（クロール可能性、インデックス可能性、正規化、サイトマップ、robots ディレクティブ、レスポンスステータス、リダイレクト、重複ページ）、プラットフォームポリシー（Googlebot、Google-Extended、OAI-SearchBot、GPTBot、ChatGPT-User を個別に制御し、スニペット制御と X-Robots-Tag も確認します。また、対象に応じて Naver および Bing/IndexNow モジュールを適用します）、オンページSEO（タイトル、説明、見出しの階層、キーワードの整合性、URL の読みやすさ、内部リンク）、コンテンツSEO（検索意図との一致、深さ、トピックの網羅性、鮮度、独自性、読みやすさ）、Core Web Vitals（LCP、INP、CLS、レンダリングをブロックするリソース、画像サイズ、操作の遅延）、構造化データ（JSON-LD の妥当性、Schema.org との適合性、可視コンテンツとの一致、エンティティ識別子、パンくずリスト、FAQ、商品、記事、組織のマークアップ）、AEO（視認できる回答ブロック、Q&A 構成、スニペット向けの要約、音声検索向けの表現、直接的で明確な回答）、GEO（出典付きで引用可能な主張や統計、エンティティの権威性、著者とブランドの信頼性を示す要素、安全に引用できるコンテンツ）、LLMO（任意の llms.txt、AI クローラーのアクセス、整理された Markdown またはセマンティック HTML、明確なエンティティ関係、鮮度の高い正規コンテンツ）。

各観点の評価基準と条件付きのプラットフォームモジュールについては、rules/seo-workflow.md のフェーズ 3～8、references/seo-checklist.md、references/seo-fundamentals.md、references/aeo-geo-guide.md を参照してください。

文字数、見出し数、リンク密度、回答の長さ、単語数、プラットフォームごとのコンテンツの好みは、状況に応じた目安として扱い、公式な合否基準とはみなさないでください。構造化データ、llms.txt、一般的なインデックス登録やスニペットの対象となることによって、リッチリザルト、ランキング、AI への掲載、引用が保証されると示唆してはいけません。Google の AI 機能は、特別な AI 用スキーマやテキストファイルを推奨せず、通常の SEO の基本に基づいて評価してください。

</audit_dimensions>

十分な根拠がある場合は、透明性のある 100 点満点のスコアを使用します。

• テクニカルSEO：20 点
• オンページSEO：20 点
• コンテンツSEO：15 点
• Core Web Vitals：15 点
• 構造化データ：10 点
• AEO 対応度：10 点
• GEO/LLMO 対応度：10 点

根拠が不十分な場合、該当するカテゴリを unknown とします。該当しないカテゴリは not-applicable とし、スコアの分母から除外します。確実性を捏造したり、目安を公式な不合格判定に置き換えたりしないでください。

各指摘には、次の内容を含めてください。

• 重要度：critical、warning、info のいずれか（重要度以外の優先順位付けには、影響度と工数のフィールドを使用してください）。
• 確信度：high、medium、low のいずれか。
• evidence_grade：official、live、field、tool、lab、synthetic、heuristic のいずれか。
• measurement_method：使用したスキャン、ツール、プローブ、ソース、またはコマンド。
• source_tier：official-doc、observed-file、live-observation、field-data、tool-output、lab-result、synthetic-probe、research-backed-heuristic のいずれか。
• 根拠：コマンドの出力、URL、ローカルのファイルパス、ブラウザーでの観察結果、または保存済みのプローブ結果。
• 推奨事項：具体的な対応と、期待される影響。
• 担当領域：コード、コンテンツ、インフラストラクチャ、分析、外部プラットフォームのいずれか。

<optimize_loop>

最適化モードは、ユーザーが最高スコア、完璧なスコア、または継続的なスコア改善を求めた場合にのみ使用してください。最適化モードは、範囲を限定した audit -> fix or recommendation -> re-audit サイクルとして扱います。変更を加える前に、ベースライン、安定した評価方法、目標、有限の予算（既定では 3 回の反復）、回帰防止策を記録してください。比較可能な根拠に基づいて改善が確認され、回帰防止策にも抵触しない場合にのみ、その反復を採用します。それ以外の場合は、可能であれば変更を元に戻し、そうでなければ discarded と記録してください。目標の達成、予算の上限、改善の停滞、回帰防止策への抵触、安全なローカル修正がない場合、または外部認証情報やビジネス上の判断が必要な作業が発生した時点で終了します。サイクル全体のルールについては、rules/seo-workflow.md のフェーズ 9 を参照してください。

</optimize_loop> 完璧なスコアを偽ったり、ランキング、AI 機能への掲載、引用を約束したりしないでください。不明な点と、比較可能な検証済みの最良の結果を報告してください。

</optimize_loop>

監査を完了とする前に、rules/validation.md を適用してください。すべての重大な指摘と警告の指摘に根拠を示すこと、エンジニア、マーケター、コンテンツ担当者が実行できるほど具体的な推奨事項を示すこと、観察された根拠に基づいてスコアを算出し、unknown と not-applicable を推測で処理せず明示的に扱うこと、Google の AI 機能を通常の SEO の基本事項を通じて説明し、FAQPage の推奨事項では Google のリッチリザルトへの適格性と回答に適した表示上の FAQ コンテンツを区別すること、URL、日付、該当する主張、根拠の分類、制約を記載したソース台帳 sources.md を用意すること、また最適化モードでは、記録済みのベースライン、評価者、有限の予算、ガード条件、変更と推奨事項、再監査の根拠、破棄した反復、停止理由、比較可能な検証済みの最良の結果を記録することが求められます。作成が必須の .hyper/seo-maker/[slug]/ の成果物は <artifact_contract> に記載されています。