social-calendar

ユーザーのテーマ、プラットフォーム、無理のない投稿頻度に基づいて、現実的な2週間のコンテンツ計画を作成します。スケジューラーではなく、計画を作成します。

コンテキスト

プロジェクトのルートにある social-context.md（.agents/social-context.md も確認してください）を読み、## Voice、## Pillars、## Platforms、## Audience、## Cadence、## Goals の各セクションを確認します。ファイルが見つからない場合は、まず social-context スキルを実行するか提案します。ただし、作業は止めず、次の簡単な質問を2～3個その場で行い、作成を進めます。

• コンテンツのテーマを2～4個教えてください。
• どのプラットフォームを使っていますか。また、最も重視しているのはどれですか？
• この1か月、実際に週あたり何件の投稿を続けられましたか？

ワークフロー

1. まず、実際に守れる投稿頻度を確認します。 ## Cadence に記載された数を額面どおりに受け取ります。これはユーザーの正直な投稿数なので、尊重します。ユーザーが申告した頻度を超える量を求めた場合（頻度が週3回なのに「毎日投稿して」と言う場合など）は、一度はっきりと伝えます。現実離れした投稿カレンダーは、何もないより悪いものです。予定した投稿を逃すと、ユーザーは計画全体を無視するようになるからです。実際に続けられる頻度、またはユーザーがあらためて明言した頻度に合わせて計画します。
2. 日付の範囲を決めます。 次の自然な投稿開始日から2週間を設定します。通常は明日、週の後半なら次の月曜日です。基準日が曖昧な場合に限り、タイムゾーンを確認します。
3. 投稿の軸となる予定を確認します。 期間中に、ローンチ、イベント、ウェビナー、リリース、またはオーディエンスが実際に祝う祝日などがあるか尋ねます。予定に紐づくコンテンツを先に配置し、残りの計画をその周りに組み立てます。重要な予定には、1回だけでなく小さな流れを持たせます。
   • 2〜4日前に予告投稿を1本（告知そのものではなく、課題をほのめかします）。
   • 予定当日の投稿を1本。
   • 1〜3日後にフォローアップを1本（結果、学び、または舞台裏を取り上げます）。
4. 投稿の柱を分散します。 同じプラットフォームで同じ柱が連続して登場せず、ユーザーが特定の柱を意図的に重視していると言わない限り、どの柱も全投稿枠の約40％を超えないようにします。## Goals にある主な目標に合わせて構成の比重を調整します。リード獲得が目標なら、製品の動作を示す柱に重点を置きます。認知度や権威性が目標なら、意見や解説に重点を置きます。柱が4つ以上あり、投稿枠が少ない場合は、すべての柱を1回だけの短い投稿にするのではなく、今後2週間は最も弱い柱を外し、どの柱を外すのか、その理由も伝えます。
5. 投稿形式を分散します。 各プラットフォームが実際に対応している形式を交互に使い、柱に合った形式を選びます。解説コンテンツにはスレッド、カルーセル、ドキュメント投稿が向いています。意見やストーリーには単独のテキスト投稿が向いています。
   • LinkedIn： テキスト投稿、ドキュメント／カルーセル投稿、画像投稿
   • X： 単独投稿、スレッド、画像投稿
   • Instagram： カルーセル、リールのアイデア、単独画像
   • Threads / Bluesky： 短いテキスト投稿、短いスレッド
   • Facebook： テキスト投稿、画像投稿、リンク投稿 プラットフォームが対応していない形式は割り当てません。また、同じプラットフォームで2週間ずっと同じ形式を使うことも避けます。
6. すべての投稿枠に、仮タイトルまたはフックを書きます。 トピック名だけではなく、ユーザーが書き出しに使える実際の一文を用意します。「最高の機能を廃止した理由」は「製品から学んだこと」より適しています。ブランドの声が文脈からわかる場合は、その声に合わせてフックを書きます。Neverリストがある場合は、ここでも遵守します。
7. 臨機応変に対応するための余裕を確保します。 投稿枠のおよそ20％、少なくとも2枠を、トピックを割り当てない reactive として残します。話題になっている会話、投稿にする価値のある返信、ユーザーの分野のニュースに対応するための枠です。計画の注記で、これは空きではなく対応可能な枠だと明記します。
8. 整然さよりも実行しやすい順序を優先します。 1週目には強いフックを優先して配置します。早い段階で成果が出ると、計画を続けやすくなります。準備に時間のかかる形式（カルーセル、長いスレッド）は、ユーザーが時間を取れそうな日に配置します。わからない場合は尋ねます。1つのアイデアを2つのプラットフォームに使う場合は、フックを練り直したうえで1〜3日ずらします。同じ日にコピーして投稿してはいけません。
9. 最後に、計画が現実的か確認します。 提示する前に、品質基準の各項目に照らして計画を確認します。投稿量、柱の間隔（約40％の上限を含む）、形式のバランス、フック、臨機応変に対応する枠、予定、クロスポストの間隔をチェックします。詰め込む前に削ります。ユーザーがやり遂げる9枠の計画のほうが、途中で放棄する14枠の計画より優れています。
10. .ics へのエクスポートは提案しますが、頼まれる前に作成しません。 ユーザーがカレンダーへの登録を希望する場合は、各投稿枠につき1件の終日イベントを含む .ics ファイルを作成し、イベント名を [platform] hook とします。そうすれば、普段使っているカレンダーに計画を反映できます。

品質基準

チェック項目	制約
投稿数	指定された頻度に正確に合わせ、決して超過しないこと
柱の間隔	プラットフォームごとに同じ柱を連続させないこと。各柱は投稿枠の約40％を超えないこと
形式の多様性	2週間の間に、プラットフォームごとに少なくとも2種類の形式を含めること
フック	各投稿枠に、話題のラベルではなく、そのまま使える書き出しを用意すること
余裕枠	投稿枠の約20％に reactive の印を付け、最低2枠を確保すること
日付の反映	ユーザーが挙げた日付ごとに投稿枠を設けること。重要な日付には事前投稿と事後投稿を用意すること
クロスポスト	2つのプラットフォームで同じアイデアを扱う場合、1〜3日ずらし、フックを作り直すこと

すべてのフックが「スクロールを止めるだろうか？」というテストに合格する必要があります。具体的で、明確な主張や緊張感を含めてください。

不合格例	合格例
「生産性について思うこと」	「30日間、すべての会議を記録しました。そのうち11時間は完全な茶番でした。」
「私たちのローンチの話」	「ローンチ時の申し込みは4件。状況を好転させたメールを紹介します。」
「創業者へのアドバイス」	「私たちに6か月の損失をもたらしたアドバイス：「もっとユーザーと話そう。」」

成果物

Date | Platform | Pillar | Format | Working title / hook | Status の列を含むMarkdownテーブルを作成し、すべての行のステータスを idea にしてください。例：

Date	Platform	Pillar	Format	Working title / hook	Status
Mon Jul 20	LinkedIn	Build-in-public	Text post	"We shipped the wrong feature first. On purpose."	idea
Tue Jul 21	X	Teaching	Thread	"7 pricing-page mistakes I keep seeing (with fixes):"	idea
Wed Jul 22	X	—	—	reactive	idea

テーブルの下に短い Notes セクションを設け、計画した投稿頻度とその理由、（該当する場合）見送った柱、余裕枠の活用方法を記載してください。.ics 形式でのエクスポートも選択肢として提案してください。これはユーザー自身が実行するための計画です。ユーザーに渡したら、そこで終了してください。