ピラーランディングページ

ピラーランディングページ は何をしますか？

複数の機能、ピラー、またはサブ製品をカバーする1つのポジショニングブリーフを、各ピラーごとのスタンドアロンランディングページブリーフに展開します。各ブリーフには独自のURL、キーワードターゲティング、およびヒーローから最終的なCTAまでのコピーが含まれます。

入力

まず company-context.md（リポジトリルート、またはワークスペース内を検索）を読み、このスキルに適用されるフィールドを使用してください。ファイルまたは行が欠落している場合は、一度質問してから、回答をファイルに保存することを提案してください。会社に関する仮定でギャップを埋めないでください。

連携

• 入力： ポジショニングブリーフ、capability-pillar-researchからのピラードキュメント、およびuse-case-evidence-researchからのエビデンスドキュメント。すべてのページのすべての主張は、これらに遡って追跡可能でなければなりません。
• 出力： ピラーごとに1つのページブリーフ。主張タグが引き継がれます。必要に応じて、結合された親ページも生成します。
• 次へ： コピーライティングとデザイン。製品の事実が変更されるたびに、これらのブリーフ全体で claim-propagation-sweep を実行します。

ピラーまたはエビデンスドキュメントが存在しない場合は、メモリからページを作成するのではなく、最初にそれらを作成してください。

これが1つの結合ページと異なる理由

結合ページでは、最も強い2つまたは3つの機能がそれを支え、弱い機能が組み込まれます。Nページに分割すると、その安全弁がなくなります。すべてのピラーは、エビデンスが等しいかどうかに関係なく、同じ領域を取得します。薄いピラーは独自のページを持つことができますが、そのページはそれについて正直でなければなりません。

プロセス（ピラーごと）

1. URL。 一貫した親パスで、最後のセグメントがピラーとなるようにします。これにより、ページはファミリーとして読まれます。
2. このピラーのキーワード調査。 製品の包括的な用語をどこでも使い回すのではありません。ボリューム、難易度、CPCを取得します（ツールの通貨単位を確認してください。一部のAPIはCPCをセントで返します）。フラグを立てます：
   • ブランドのポジショニングと競合するキーワード（最適なキーワードが「チケットシステム」だが、製品がチケットキューに反対している場合）：タイトル、メタ、およびサポートする見出しに保持するか、人間にフラグを立てます。
   • 検索結果が別のフォーマット（リスト記事、比較記事）で支配されている用語：製品ページを競合させる代わりに、その用語に別のアセットを推奨します。
3. タイトルタグとメタディスクリプションをプライマリキーワードから生成します。
4. ポジショニングサマリー： ソースブリーフ、ピラーのコアクレーム、および最も強いエビデンスからの3～5文。
5. ページは、ファミリー全体で同じように構成されます：
   • ヒーロー（H1、サブ、CTA）：ピラーの最もシャープで具体的なクレーム。メカニズムに名前を付けます。
   • プルーフストリップ： 3～4つの短く、ソースが明確なクレーム。統計が存在するが未承認の場合は、そのように述べてください。使用したり、黙って削除したりしないでください。
   • 2～4つのボディセクションをこのピラーの実際のエビデンスから作成：何をするか（機能カタログから）、なぜ明白な代替案よりも優れているか、このピラーが答えなければならない反論。
   • トラストまたはセキュリティセクション。ピラーが権限、コンプライアンス、またはAI安全性に関する反論に触れる場合は、上部に配置します。
   • 正直なスコープセクション。 ピラーのエビデンスが兄弟ページよりも薄い場合のみ。
   • 兄弟ページへのクロスリンク。
   • 最終CTA。
6. すべてのクレームにタグを付け（共有ルール4）、使用された顧客引用に対して引用チェックを実行します。
7. ページ固有の未解決項目を各ブリーフの最後に追加します：未確認の数値、承認待ちの顧客、またはピラーが独自のページに値するかどうかについての実際の質問。

完了条件

• すべてのページが独自のキーワード調査を持っている。
• すべてのヒーローとプルーフのクレームがソースドキュメントに遡って追跡できる。
• ピラーが不均一な場合、不均一なエビデンスが少なくとも1つの正直なスコープ注記で可視化されている。
• ページが相互にクロスリンクしている。

共有ルール（このセットの4つのスキルで同一）

1. エビデンスの前にコピー。 すべての製品クレーム、統計、引用は、名前付きソースに遡って追跡されます。能力、数値、顧客事例、引用を発明しないでください。エビデンスがない場合は、そのように述べてください。
2. 出荷済みは出荷済み。 機能のステータス（出荷済み、進行中、計画中）は、ソースが述べているとおりにのみ述べてください。製品が満たせないバイヤーの要求は、能力の下ではなく、希望または要望の下に置いてください。
3. 引用は逐語的かつバイヤー側。 正確な言葉をコピーします。「...」でカットしますが、決して変更しないでください。ベンダーのスタッフをバイヤーとして引用しないでください。終了する前に、引用チェック（スクリプトはuse-case-evidence-researchに verify_quotes.py として同梱されています）を実行し、見つからなかったものを修正するか削除してください。
4. クレームタグ。 コピーとクレームに SAFE、NEEDS VERIFY:（何が決着するか）、または INTERNAL ONLY（署名のない名前付き顧客資料）のマークを付けます。1つのスキルの出力から次のスキルにタグを引き継ぎます。削除しないでください。
5. 薄いエビデンスは率直に述べる。 引用ではなく、個別のアカウントを数えます。弱い領域を強い領域に合わせるために水増ししないでください。
6. 完成したドキュメント、変更履歴ではない。 参照用に読まれることを意図したドキュメントには、「更新」、「追加」、「新規」、バージョン番号、スイープ、またはセッション参照を含めないでください。バージョン履歴はそれらを保持します。
7. 外部セーフモード（ユーザーが外部向け、広告向け、顧客向けに「外部」と言った場合、クリーンに保つ）：役職と会社名のみ、個人名はなし。日付はなし。引用内の競合他社名は、「[旧ツール]」などの中立な括弧に置き換えます。署名、ソース、または使用法に関するメモはなし。返信で、顧客引用にはまだ署名が必要であることをユーザーに伝えてください。
8. トーン。 平易で直接的。ダッシュなし。ヘッジワードなし。バイヤー自身が言う以上に競合他社を特徴付けないでください。ドキュメントの本文にファイル名を含めないでください。

4つのスキルの連携方法

1. use-case-evidence-research: ユースケースまたは機能ごとにエビデンス（製品機能、バイヤーの悩み、希望、反応）を収集および検証します。
2. capability-pillar-research: そのエビデンスを動詞（製品が何をするか）で再グループ化し、機能ではなく動作でポジショニングします。
3. pillar-landing-pages: ポジショニングを、ステップ1～2のクレームのみを使用して、ピラーまたは機能ごとの1つのページブリーフに変換します。
4. claim-propagation-sweep: 製品の事実が変更されるたびに、ステップ1～3で生成されたすべてのものを実行し、修正をエビデンスドキュメントにフィードバックします。

あるステップの出力は、次のステップの入力です。後のステップを要求され、前の出力が存在しない場合は、メモリから作成するのではなく、前のステップを最初に構築するか（またはユーザーに不足していることを伝えてください）。