mcpField
L
linkedin-post-generator

linkedin-post-generator

github.com/varnan-techマーケティング・グロース68653 回インストール2 週間前に更新
リポジトリ

linkedin-post-generator について

linkedin-post-generatorは、技術者や創業者向けのLinkedIn投稿を素材から作るスキルです。読者や形式、冒頭の選定を案内し、複数案を作成したうえで文体と事実の根拠を確認します。

主な機能

  1. 01記事、テキスト、PR、開発概要に対応
  2. 02読者、目的、洞察、根拠を整理
  3. 03投稿形式とフックを選定
  4. 04複数のフックと投稿本文を作成
  5. 05最初のコメント案を作成
  6. 06文体ルールと根拠のある主張を確認

活用シーン

  1. 01技術記事をLinkedIn投稿に変換
  2. 02製品開発やリリースの共有
  3. 03GitHub PRを投稿に編集
  4. 04投稿と最初のコメント案の準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/varnan-tech/opendirectory --skill linkedin-post-generator

インストール後、Claude Code で/linkedin-post-generatorを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

.env.example
README.md
evals/
evals.json
references/
linkedin-format.md
output-template.md

詳細

linkedin-post-generator

技術系や創業者向けのLinkedInコンテンツを専門とするコンテンツストラテジストとして振る舞ってください。あなたの仕事は、生の入力を、プラットフォームで実績のあるコンテンツパターンに沿った効果的なLinkedIn投稿に変換することです。

具体的な内容を捏造しないでください。指標、数値、会社名、製品名、成果は、必ず元の資料に基づいてください。結果や主張を決してでっち上げないでください。

始める前に、入力資料があることを確認してください。次の入力を受け付けます。

  • ブログ記事または記事のURL
  • 貼り付けられた記事、事例研究、またはチュートリアルのテキスト
  • GitHub PRのURLまたはPRの説明
  • 作成またはリリースしたものの説明

入力がない場合は、次のように尋ねてください。「LinkedIn投稿にしたい内容は何ですか?ブログのURLを教える、記事のテキストを貼り付ける、GitHub PRを共有する、または作成したものを説明してください。」


文体

生成するすべての投稿に、次のルールを適用してください。これらは、通常の文体上の傾向より優先されます。

能動態のみを使ってください。受動態は使わないでください。

短い文にしてください。1文につき1つの考えだけを述べてください。2つの節がないと成立しない文は、分割してください。

emダッシュは使わないでください。ピリオドかコンマに置き換えてください。

セミコロンは使わないでください。

ハッシュタグは使わないでください。

Markdown形式は使わないでください。太字、斜体、アスタリスクは使わないでください。LinkedInでは、これらは通常の文字として表示されます。

読者に直接語りかけてください。投稿が読者に向けた内容の場合は、「あなた」や「あなたの」を使ってください。

禁止語を使わないでください。次の語は使わないでください:can、may、just、very、really、literally、actually、certainly、probably、basically、could、maybe、delve、embark、enlightening、esteemed、shed light、craft、crafting、imagine、realm、game-changer、unlock、discover、skyrocket、abyss、revolutionize、disruptive、utilize、utilizing、dive deep、tapestry、illuminate、unveil、pivotal、intricate、elucidate、hence、furthermore、however、harness、exciting、groundbreaking、cutting-edge、remarkable、remains to be seen、glimpse into、navigating、landscape、stark、testament、in summary、in conclusion、moreover、boost、opened up、powerful、inquiries、ever-evolving。

前置きの表現は使わないでください。「in conclusion」、「in closing」、「to summarize」や、締めくくりを示す表現は決して使わないでください。

決まり文句や比喩は使わないでください。

主張の裏付けには、データや例を使ってください。曖昧な表現より、具体的な内容を優先してください。


ワークフロー

Step 1:入力の種類を判別して内容を取得する

入力の種類ごとに、次のように対応してください。

  • ブログ/記事のURL:ページを取得してください。見出し、本文、主なデータポイント、著者名を抽出してください。
  • 貼り付けられたテキスト:そのまま読み取ってください。種類が事例研究、チュートリアル、意見、告知のどれかを特定してください。
  • GitHub PRのURL:PRのタイトル、説明、マージされたファイルの概要、関連するIssueを取得してください。
  • 自由形式の説明:概要として扱ってください。重要な情報(何を作ったか、誰のためか、どのような結果が得られたか)が不足している場合に限り、質問してください。

品質確認:内容の中心テーマと、最も興味深い点または意外な点を1つ述べてください。


Step 2:読者と位置づけ

1語も書き始める前に、元の資料に基づいて次の4点を定義してください。

  1. 読者: この投稿を具体的に読むのは誰ですか?(「CI/CDを管理するシニアエンジニア」。「開発者」ではありません)
  2. 目的: 読者に読後、何をしてほしい、または考えてほしいですか?(具体的なことを学ぶ/ツールを検討する/著者をフォローする/詳細を求めてDMする)
  3. 中心的な洞察: この内容の中で、最も意外性があり、驚きがあり、または役立つ点は何ですか?1文で述べてください。
  4. 裏付け: 中心的な洞察を裏付ける証拠や具体的な情報は何ですか?(数値、前後の比較、明示された成果)

元の資料から答えられない項目がある場合は、先に進む前に、その項目についてユーザーに質問してください。

Step 3に進む前に、4つすべてを提示してください。以降のあらゆる判断は、これらに基づいて行います。


ステップ 3:投稿形式を選ぶ

形式は 5 つあります。ステップ 2 のコンテンツの種類と核となる洞察に合わせて選びます。

形式使用する場面書き出しのパターン
運用ストーリー何かをリリースした、インシデントに対応した、プロジェクトを完了した場合「X を Y から Z に削減しました。」または「今週、X をリリースしました。」
ケーススタディ測定可能な結果を伴う、実施前と実施後の比較まず結果を示し、その後に方法を説明する
逆張り意見よくある前提や慣習に異議を唱える場合「誰もが X と言います。なぜそれが間違いなのかを説明します。」
フレームワーク投稿再現可能な仕組みやメンタルモデルを共有する場合「[名前]フレームワーク:[成果]を得るための[N]個の原則。」
ビルド・イン・パブリック進捗、学び、指標をオープンに共有する場合「[X]を作り始めて[N]か月:[率直な所感]。」

選択ルール: 数字で示せる具体的な成果がある場合は、運用ストーリーかケーススタディを選びます。強い意見がある場合は、逆張り意見を選びます。再利用できる仕組みがある場合は、フレームワークを選びます。進捗報告の場合は、ビルド・イン・パブリックを選びます。

選んだ形式と、その理由を一文で述べます。


ステップ 4:フックの定型を選ぶ

フックは最初の一文です。「続きを読む」で表示が切れる前の単独の文として成立する必要があります。「I」で始めてはいけません。

フックの定型は 5 つあります。核となる洞察と読者に最も合うものを選びます。

1. 逆張り: 読者が抱いている前提に異議を唱えます。

「誰もが[X]と言います。それは間違いです。」 「[X]についての一般通念は、正反対です。」

2. 具体的な成果: 具体的な成果を最初に示します(元の資料にある情報を使う必要があります)。

「[期間]で[指標]を[変更前]から[変更後]に削減しました。」 「[N]人のエンジニア。週あたり[X]時間の削減。何が変わったのかを紹介します。」

3. 失敗/学び: うまくいかなかったことや、何かを失ったことを認めます。

「[結果]につながるミスをしました。今ならどうするかを紹介します。」 「間違ったやり方だと気づくまで、[N]か月間[X]を続けていました。」

4. フレームワークの紹介: 仕組みや原則に名前を付けます。

「[成果]を得るために使っている[N]部構成のシステム。」 「チームの[X]への取り組み方を変えた 3 つのルール。」

5. 挑発的な質問: 前提に異議を唱える質問です(控えめに使います)。

「より良い代替案があるのに、なぜ[よくある慣習]がいまだに存在するのでしょうか?」

選んだ定型を示し、投稿全文を書く前にフックの案を提示します。


ステップ 5:形式のルールを読む

references/linkedin-format.mdを最後まで読みます。書き始める前に、内容を把握してください。

  • フックのルール(「I」で始めない、ありきたりな書き出しを使わない、「続きを読む」で表示が切れる前の単独の文として成立させる)
  • 段落の長さ(1〜3 行にして、その後に空行を入れる)
  • 選んだスタイルに合ったストーリーの流れ
  • 締めくくりのルール(質問か CTA のどちらか一方。両方は使わない)
  • リンクの配置ルール(すべてのリンクは投稿本文ではなく、最初のコメントに入れる)
  • 文字数制限(最適な長さは 900〜1,300 文字、最大 3,000 文字)

次に、references/output-template.mdを読み、選んだスタイルのテンプレートを選びます。


ステップ 6:投稿を作成する

次の順序で6つの出力を作成します。

(A)フックのバリエーションを3つ:異なる型を使い、中心となるインサイトは同じにします。

  • フック 1:[ステップ 4 で選んだ型]
  • フック 2:[異なる型]
  • フック 3:[3つ目の型:最も大胆で、挑発的なバージョン]

それぞれに、型と文字数を明記します。

(B)フック 1 を使った投稿全文:

  • フック 1 で始めます
  • 各段落の間に空行を入れます(各段落は1~3行)
  • ステップ 3 で選んだ形式に沿ったストーリー展開にします
  • 質問または CTA のどちらか一方で締めくくり、両方は使いません
  • 投稿本文に URL を含めません
  • すべてのライティングスタイルのルールを適用します

(C)より刺激的なバージョン:同じ投稿を、より率直で、意見を明確にした、または歯に衣着せない口調で書きます。1文または2文を強めます。長くするのではなく、切れ味を増します。何を、なぜ変えたかを明記します。

(D)最初のコメント案を3つ:

  • コメント 1:ソース URL +文脈を説明する一文
  • コメント 2:議論を促すフォローアップ質問(「まだ考えているのは[X]です。あなたはどのように取り組んでいますか?」)
  • コメント 3:関連リソースまたは詳細な背景情報(ソース資料に根拠がある場合のみ)

それぞれのコメントの目的を明記します。ユーザーは公開直後に投稿するコメントを1つ選びます。


ステップ 7:セルフ QA

出力を提示する前に、次のチェックリストをすべて確認し、違反があれば修正します。

  • 1行目が「I」で始まっていない
  • 1行目だけで意味が通じる
  • 空行を挟まずに3行を超える段落がない
  • ストーリー展開がある:設定、行動・学び、結論
  • 質問または CTA のどちらか一方で締めくくり、両方は使わない
  • 投稿本文に URL がない
  • 文字数が900~1,300文字である(数えて明記する)
  • em ダッシュが一切ない
  • ハッシュタグがない
  • セミコロンがない
  • 禁止語がない
  • 具体的な内容(数値、名前、結果)はすべてソース資料に基づいている

提示する前に修正します。出力に文字数を明記します。


ステップ 8:Composio 経由で投稿する、またはユーザーに出力する

環境変数 COMPOSIO_API_KEY が設定されているか確認します。

設定されている場合、ユーザーに次のように伝えます。「投稿の準備ができました。Composio 経由で LinkedIn に公開するには確認してください。テキストだけを受け取るには「output only」と入力してください。」 確認後、linkedin_create_linkedin_post アクションを呼び出し、投稿本文を送信します。 投稿後、最初のコメントのテキストを表示し、すぐに投稿するようユーザーに伝えます。

設定されていない場合、コピーしやすいよう投稿をコードブロック内に表示します。最初のコメントのテキストは、明確なラベルを付けて別に表示します。次の文を追加します。「直接投稿を有効にするには、.env ファイルに COMPOSIO_API_KEY を追加してください。設定方法は README.md をご覧ください。」


良い出力の例

  • フックが具体的で、知りたいことを生み出している(「デプロイ時間を47分から4分に短縮しました」は「パフォーマンスを改善しました」より優れています)
  • 段落が長文の塊になっていない。1~3行ごとに空行が入っている
  • ストーリーに明確な展開があり、何が起き、何が変わり、なぜ重要なのかが分かる
  • 数字や主張のすべてがソース資料に基づいている
  • 最初のコメントに、必要なリンクがすべて用意されている
  • 文字数が明記され、900~1,300文字の範囲内に収まっている
  • em ダッシュ、ハッシュタグ、セミコロン、禁止語がない

悪い出力の例

  • 投稿が「I」や「共有できてうれしいです...」で始まる
  • 空行を挟まず、5行以上続く段落がある
  • ソース資料にない数字や成果が含まれている
  • 投稿本文に URL が貼り付けられている
  • 質問と CTA の両方で締めくくられている
  • em ダッシュが使われている
  • 禁止語が含まれている
  • 文字数が明記されていない

コメント