social-check

各ターゲットプラットフォームの実際の制約に照らして下書きを確認し、チェックごとに pass／warn／fix の判定を返します。修正が必要な場合は、修正版をその場に提示します。付属のリンターが機械的なカウントを行い、判断はあなたが行います。

コンテキスト

プロジェクトのルートにある social-context.md（.agents/social-context.md も確認）を読み、## Voice のルール、## Platforms、## Never のリストを確認します。ハッシュタグ、絵文字、リンクの慣例が明記されていない場合は、以下のインラインの代替手順を使います。ファイルがない場合は、まず social-context スキルを実行することを提案しますが、作業は止めず、次の質問を2〜3個手短にして、そのまま進めます。

• この下書きはどのプラットフォーム向けですか？
• 投稿にメディアは含まれますか？ また、代替テキストはありますか？
• ハッシュタグ、絵文字、リンクに関する独自のルールはありますか？

ワークフロー

1. 対象を確定します。 下書きの対象プラットフォームを確認します。プラットフォームごとに個別に評価してください。ある下書きがXでは合格し、LinkedInでは不合格になることもあります。判定を平均しても誰の役にも立ちません。

2. 機械的なチェックにはリンターを実行します。 リンターは、プラットフォームに即した文字数（XではURLを23文字、絵文字を2文字として計算し、MastodonではURLを23文字として計算）、省略位置、リンク数と配置、ハッシュタグの数・配置・大文字小文字、エンゲージメントを誘う文言、書式上の落とし穴を決定論的に算出します。文字数を目測する必要はありません。

   bun scripts/lint-post.mjs --platform x --file draft.txt      # one platform
   bun scripts/lint-post.mjs --all --file draft.txt             # every platform
   echo "$DRAFT" | bun scripts/lint-post.mjs --platform linkedin
   

   JSON — { counts, checks: [{ check, verdict, detail }], summary } — が出力されます。各 verdict は pass、warn、fix のいずれかで、いずれかのチェックが fix の場合はゼロ以外の終了コードが返されます。bun の代わりに node も使えます。オプションは --help、対応プラットフォームは --list で確認できます。どちらのランタイムも利用できない場合は、references/platform-limits.md を参照して手動でカウントしてください。

3. フラグの理由が必要な場合は、根拠を確認します。 制約の完全な一覧、プラットフォームごとのリンクとハッシュタグの規範、メディアとアスペクト比のルール、判定基準の定義については、references/platform-limits.md を読み込みます。制約を記憶に頼って言い直さないでください。このリファレンスとリンターが読み込むJSONが、正確な情報源です。

4. リンターでは判断できない点を評価します。 スクリプトは機械的な項目を検出します。以下はあなたが判断してください。

   • フック。 リンターが報告した省略位置より前に、最初に表示される行で完結した魅力的なアイデアを伝えていますか？ 「So I've been thinking about someth…」は fix です。書き直した冒頭をその場に提示してください。
   • メディアと代替テキスト。 メディアの説明がある場合は、references/platform-limits.md（Media & accessibility）にある配置先のルールに照らしてアスペクト比を確認し、代替テキストが実際に画像を説明していることを確かめます。「image」だけの記述やキーワードの羅列は fix です。
   • 最初のコメントの方針。 リンクを最初のコメントに置く場合（または下書きに「コメント欄にリンク」とある場合）は、そのコメントを作成します。文脈を1行とリンクを記載してください。
   • エンゲージメントを誘う文言。 リンターがそのような文言を検出した場合は、反射的な反応ではなく、実質的な意見を求める質問に置き換えます。
   • 文体。 social-context.md の Voice セクションにあるすべてのルールに照らして下書きを確認します。

5. 判定をまとめます。 リンターによる機械的な判定とあなたの判断を統合し、プラットフォームごとに1つの表にまとめます。表には pass／warn／fix、簡潔な理由、すべての fix に対する修正文をその場に記載します。該当しないチェック（メディアなし、リンクなしなど）も行を省略せず、n/a と記載します。fix が1つでもある場合は、そのプラットフォーム向けの投稿全文を修正したものを最後に提示します。

品質基準

「およそ280」という曖昧な記憶ではなく、references/platform-limits.md の実際の数値と照らし合わせて確認してください。判定の基準：

• pass — 制約を満たしています。それ以上の説明は不要です。
• warn — 投稿はできますが、効果が落ちる、または読者を困らせる可能性があります。理由を一文節で示し、改善案を提示してください。
• fix — このまま投稿してはいけません。修正したテキストをその場に記載してください。修正後のテキストがない fix は、未完了のチェックです。

対象となるすべてのプラットフォームについて、すべてのチェックを実行してください。チェックが黙って省略されている場合、合格したものと見なされます。

成果物

対象となる各プラットフォームについて、判定表（チェック | 判定 | 備考）を作成し、fix の各行の直後に修正後のテキストを記載してください。また、fix が1つでもある場合は、そのプラットフォーム向けの修正済み原稿全体に加え、戦略上必要であれば作成した最初のコメントも提示してください。ユーザーは修正済み原稿をコピーし、好きな場所とタイミングで投稿します。原稿を渡したら、そこで終了してください。