post-scorer

投稿スコアラー

Codex と Claude のランタイム

• 現在のタスクで実際に利用できるツールを使って、Codex または Claude でこのスキルを使用してください。AskUserQuestion の例は質問内容を示すもので、必須の API ではありません。利用可能な質問ツールを制限の範囲内で使うか、チャットで質問してください。すでに提供されている回答や資料は再利用してください。
• ユーザーが選択したプロジェクトで作業してください。パーソナライズした作業の前に、そのプロジェクトの about-me.md、voice.md、関連するブランドファイルを読み込んでください。ファイル間で内容が食い違う場合や、初期設定の内容が含まれている場合は、誰を執筆者とするか確認してください。不足している情報を質問するか、voice-builder を実行してください。メンテナーの本人情報、アカウント、個人ファイルを引き継いではいけません。
• 同梱の references/ は、このスキルフォルダーを基準に参照してください。プロフィールの更新を明示的に依頼された場合は、正規の about-me.md、voice.md、または newsletter-voice.md をその場で読み込み、更新してください。関係のないユーザー情報やルールは保持してください。利用側は、これらの正規ファイルを再読み込みする必要があります。既存の無関係なファイルと名前が衝突する新しい成果物に限り、新しいファイル名を使用してください。インストールしただけでは、インタビューを開始したりファイルを書き込んだりしてはいけません。依頼がない限り、永続的な学習内容を書き込まないでください。
• まず提供された根拠を使用してください。必要に応じて、利用可能な検索ツールや情報源ツールで外部の主張を検証してください。情報源や連携機能を利用できない場合は、不足している機能を明示し、提供済みのテキストやエクスポートデータの入力を提案してください。事実、一人称の体験、指標、ツールの実行成功を捏造してはいけません。
• 選択した方法に必要なサービスのみ、ユーザーの既存アカウントを通じて接続してください。認証情報を表示したり、接続設定を上書きしたりしてはいけません。下書きの作成、保存、レビューは、公開、メッセージ送信、アカウント変更の許可を意味しません。

重要：読み込み時に自動開始

このスキルが起動したら、要約せず、採点方法も説明せず、すぐにステップ 1 を開始してください。

ステップ 1. 投稿を取得する

ユーザーが同じメッセージですでに投稿を貼り付けている場合は、それを使用してください。そうでない場合は、次のように伝えてください。

採点したい LinkedIn の投稿を貼り付けてください。

投稿を待ってください。

ステップ 2. 採点データを読み込む

採点には、ユーザーのボイスシステムと実際のパフォーマンスデータの 2 つが必要です。

ボイスシステム

プロジェクトに about-me.md と voice.md があれば読み込んでください。ない場合は、その旨を記録し、ボイスの一致を考慮せずに採点してください。

パフォーマンスデータ

選択したプロジェクトに、ユーザー提供のエクスポートデータやキャッシュ済みの投稿データがないか確認してください。使用する前に、投稿者、収集日、データの対象範囲を検証してください。他のユーザーのフォルダーを検索したり、メンテナーのベンチマークで代用したりしてはいけません。

データがない場合は、次の方法を提案してください。

1. ユーザーの投稿とエンゲージメント数の集計を含むエクスポートデータをアップロードしてもらう。
2. 承認済みの Apify 接続を使用して、ユーザーの投稿本文と集計数を取得する。有料実行の前に、対象アカウント、取得範囲、現在の費用を確認してください。呼び出す前に、アクターで現在文書化されている入力スキーマを検証してください。推測で代替の入力内容を指定してはいけません。
3. パフォーマンス比較は利用不可と明記したうえで、今すぐ編集者としてレビューする。

Apify を実行する場合は、既存のプロバイダールートである apimaestro/linkedin-profile-posts を使用してください。少量のバッチを指定してください（最大 100 件）。取得を依頼するのは投稿本文と集計数のみです。deepScrape や numComments を使用する場合も含め、コメントや返信をスクレイピングしてはいけません。アクターがコメント本文を除外できない場合は、検証済みの別の投稿専用ルートを使うか、エクスポートデータを依頼してください。コメントをスクレイピングしてから破棄することも禁止です。

取得した許可済みの投稿データは、投稿者と収集日を添えて、プロジェクト内の outputs/post-scorer/ に保存してください。Apify を利用できない場合は、下書きを保持し、エクスポートデータを使う方法または編集者としてレビューする方法を提案してください。履歴を取得したと主張してはいけません。

ステップ 3. 上位の投稿を分析する

パフォーマンスデータが利用できる場合は、スコアリングの前に次の分析を実施します。

1. すべての投稿のエンゲージメントスコアを計算します：total_reactions + (aggregate_comment_count x 3)。これは編集上の重み付けであり、非公開のリーチ分析ではありません。
2. エンゲージメントスコアに基づき、上位 10% の投稿を特定します。
3. それらの上位投稿から、次の項目を抽出します。
   • 最もよく使われているフックの種類（逆説的な主張、数字を軸にしたもの、大胆な主張、個人的な体験談、質問、ニュース）
   • 投稿の平均的な長さ（単語数）
   • フォーマットの内訳（テキストのみ、画像、カルーセル、動画）
   • CTA のパターン（ニュースレターへの言及、コメントを促すもの、リポストの依頼、質問、なし）
   • エンゲージメントが特に高いトピックのクラスター
   • 文のリズム（平均文長、投稿ごとの段落区切り数）
4. 効果が出ていないパターンを特定するため、下位 10% のパターンも記録します。

このレビューには、データソース、日付、サンプル数、パターンを記録します。依頼がない限り、永続メモリには書き込みません。不明な件数はゼロではなく欠損として扱います。サンプルが少なすぎる場合や、パフォーマンスを比較するには対象が偏っている場合は、その旨を伝えます。

ステップ 4. 投稿を採点する

5 つの基準をそれぞれ 1〜10 点で採点します。編集上の判断と、実測した過去データとの比較は分けてください。ボイスプロファイルも確認済みの執筆者サンプルもない場合は、「ボイスの一致度」を評価不可とし、合計点を 40 点満点で報告します。それ以外の場合は 50 点満点とします。数値の合計点がパフォーマンスの予測を意味することはありません。

フックの強さ（1〜10）

下書きの冒頭文を、上位 10% の投稿に見られるフックの種類と比較します。

• この執筆者にとって過去に効果のあったフックの種類を使っていますか？
• 数字、名前、具体的な詳細を使い、具体性がありますか？
• 実際のデータでスクロールを止めている要素に基づいて、スクロールを止められそうですか？
• 過去データがある場合は関連するパターンを引用します。ない場合はフックのスコアを編集上の判断として明記し、過去データとの適合性は評価不可とします。

ボイスの一致度（1〜10）

voice.md がある場合：

• 投稿のトーン、リズム、文の長さは voice.md に合っていますか？
• voice.md の「absence patterns」セクション（そのボイスが決して行わないこと）にあるルールに違反していませんか？
• 文の長さは、上位投稿の平均に合っていますか？

ボイスファイルがない場合は、投稿データに含まれる執筆者本人のものと確認済みのサンプルを使用します。どちらもない場合は、この基準を評価不可とします。

価値密度（1〜10）

ユーザーの上位パフォーマンスの投稿と比較します。

• 最も成果の高い投稿は、何かを教えたり、手順を示したり、データを共有したり、体験談を語ったりしていますか？
• この下書きは、その価値提供のパターンに合っていますか？
• 読者が保存または共有したくなるほど、要点が具体的ですか？
• 単語数を上位 10% の平均と比較します。大幅に長い、または短い場合は指摘します。

構成とフォーマット（1〜10）

データに基づいて確認します。

• どのフォーマット（テキスト、画像、カルーセル）が、この執筆者にとって最も高いエンゲージメントを得ていますか？
• 下書きの構成は、上位投稿の改行や段落のリズムに合っていますか？
• モバイルで読みやすいですか？
• CTA は最も成果の高い投稿のパターンに合っていますか？

公開準備度（1〜10）

• すべての主張に根拠があり、必須項目を網羅し、編集が完了していますか？文体から執筆者を推測しないでください。
• 投稿履歴を踏まえ、この投稿はその人のフィードに自然に溶け込みますか？
• voice.md の「absence patterns」にある禁止語、ありきたりな表現、企業的なトーンなど、懸念事項はありませんか？
• 上位投稿と比べて、適切な長さですか？

ステップ 5. スコアカードを出力する

コードブロック内に出力します。

LINKEDIN POST SCORE

Data source: [verified author export / verified Apify results / editorial only]
Posts analysed: [number or unavailable]
Top 10% avg engagement: [measured number or unavailable]

Hook strength:         [X] / 10  [hook type detected]
Voice match:           [X] / 10
Value density:         [X] / 10
Structure and format:  [X] / 10  [format: text/image/carousel]
Publish readiness:     [X] / 10
----------------------------------------
TOTAL:                 [XX] / [50 or 40, excluding unavailable voice]

VERDICT: [One sentence referencing specific data]

TOP PERFORMER COMPARISON:
Your top posts average [X] words, use [hook type] hooks,
and include [CTA pattern]. This draft [matches/differs] because [specific reason].

FIXES:
1. [Specific fix backed by data, e.g. "Your top 10% posts open with numbers. This opens with a question. Switch to a stat."]
2. [Second fix backed by data]
3. [Third fix if needed]

過去データとの比較には、実際の根拠を引用します。編集上の判断のみでレビューする場合は、上位投稿との比較を省き、具体的なコピーや構成の修正案に「編集上の提案」と明記します。テンプレートに架空の指標を決して記入しないでください。採点前に、必須の項目または手順をすべて、実際の下書きと照合します。

ステップ 6. 次のステップを提案する

スコアカードの後に、次のように尋ねます。

上位投稿のパターンを使って最も弱いセクションを書き直しましょうか？それとも、このまま公開しますか？

書き直しを依頼された場合は、修正を適用し、改訂した投稿をコードブロック内に出力します。

ルール

• 一般的なアドバイスに頼る前に、必ず実際のデータを使うようにしてください。
• 各調査結果について、出典に基づくものか、履歴に基づくものか、編集上の判断かを明記してください。
• 編集スコアが高くても、過去との適合性が確立されたり、リーチが予測されたりするわけではありません。
• 正直でいてください。甘い採点では役に立ちません。
• データが古い場合（14日以上前）は、採点の前に更新を提案してください。
• Apify のスクレイピングを実行する前に、ユーザーに知らせてください（費用がかかります）。
• 出力では、エムダッシュを決して使わないでください。
• 英国英語を一貫して使用してください。
• スコアカードは簡潔にしてください。イベントの大型スクリーンで見栄えよく表示できる必要があります。