GitHub リポジトリ最適化

あらゆるGitHubリポジトリを、スター、フォロワー、トラフィックを促進する、高コンバージョンかつSEO最適化されたランディングページに変革します。あなたが触れるすべてのリポジトリが、トップ100のオープンソースプロジェクトのように見えるべきです。

このスキルには2つのモードがあります：

最適化 — リポジトリのREADME、メタデータ、構造を最大のコンバージョンに向けて書き換えます
アドバイス — 以下のナレッジベースを使用して、スター成長戦略をユーザーに提供します

目標（優先順位順）

スター数 -- GitHubにおける主要な社会的証明指標
フォロワー数 -- リポジトリ所有者のソーシャルプロフィールへのトラフィックを促進
発見可能性 -- GitHub検索、Google、LLM回答エンジンで上位表示
トラフィック -- 訪問者をユーザー/フォロワーに変換
プロフェッショナルとしての信頼性 -- 構造と洗練さを通じて品質を信号として伝える

ステップ0: ユーザー設定（自己更新）

最適化の前に、このリポジトリの所有者が誰かを知る必要があります。このステップは一度だけ実行されます。その後は設定が再利用されます。

既存の設定を確認

~/.claude/skills/github-optimization/.config.yml を探します。存在する場合は、値をロードしてステップ1にスキップします。ロードされた内容をユーザーに表示し、変更があるかどうかを尋ねます。

設定がない場合、検出して質問

git configとGitHub APIから自動検出:
- gh api user -- 認証されたGitHubユーザー名とプロフィールURLを取得
- gh api repos/<owner>/<repo> -- リポジトリ所有者を取得（ユーザーまたは組織の可能性あり）
- git config user.name -- ローカルのgit表示名を取得
検出できないものをユーザーに尋ねる:
- 表示名 -- 実際の名前または希望するクレジット表記（例：「山田太郎」）
- X/Twitterハンドル -- Followバッジ用（例：「@yamada_taro」）。不要な場合はスキップ。
- 会社または組織名 -- フッターの帰属表示用（省略可）
- 会社URL -- 会社名へのリンク（省略可）
- ウェブサイトURL -- 個人または会社のサイト（省略可）
設定を保存 ~/.claude/skills/github-optimization/.config.yml:

# GitHub 最適化スキル — ユーザー設定
# このファイルは自動生成されます。いつでも編集できます。
author_name: "山田 太郎"
author_github: "yamada_taro"
x_handle: "yamada_taro"          # Followバッジをスキップするには空文字列 "" を設定
company_name: "株式会社エーシーエム"      # スキップするには空文字列 "" を設定
company_url: "https://acme.com"
website_url: "https://yamada-taro.dev"

これらの変数をパイプライン全体で使用:
- {OWNER} -- GitHubユーザー名または組織（リポジトリURLから検出、リポジトリごと）
- {REPO} -- リポジトリ名（リポジトリごとに検出）
- {AUTHOR_NAME} -- 設定から
- {AUTHOR_GITHUB} -- 設定から
- {X_HANDLE} -- 設定から（空の可能性あり）
- {COMPANY_NAME} -- 設定から（空の可能性あり）
- {COMPANY_URL} -- 設定から（空の可能性あり）
- {WEBSITE_URL} -- 設定から（空の可能性あり）

いずれかのフィールドが空の場合は、その要素を出力から完全に省略します。空のプレースホルダーや壊れたバッジは作成しないでください。

設定の更新

ユーザーが「設定を更新して」「Xハンドルを変更して」などと言った場合は、.config.yml ファイルを更新し、変更を確認します。

最適化パイプライン

0. CONFIG       -> ユーザー設定をロードまたは作成（一度実行され、自己更新する）
1. AUDIT        -> 現在のREADME、説明文、トピック、リポジトリ構造を読み取る
2. KEYWORDS     -> このリポジトリのドメインに対するターゲット検索語句を特定
3. METADATA     -> リポジトリ名、説明文（About）、トピックを最適化
4. README       -> 以下のテンプレートに従いランディングページとして書き換え
5. HUMANISE     -> すべての散文に対してhumanise-textスキルを実行し、AIパターンを除去
6. EXTRAS       -> LICENSE、CONTRIBUTING.mdがない場合に追加
7. PUBLISH      -> コミット、プッシュ、gh repo editを実行して説明文とトピックを適用

スキルチェーン

このスキルは実行中に他のスキルを呼び出します：

humanise-text -- READMEのドラフト作成後、すべての散文セクションに対して humanise-text スキルを呼び出します。これによりAIによるライティングパターンが除去され、実際の人間が書いたかのようなコピーになります。必須です。すべてのREADMEはこれを通過しなければなりません。

ステップ1: 監査

現在の状態を読み取ります：

README.mdの内容と構造
リポジトリの説明文（Aboutセクション）
トピック/タグ
ライセンス
ファイル構造
既存のバッジ

何が欠けているか、何が弱いか、何が良いかをメモします。

ステップ2: キーワード調査

開発者がこのプロジェクトを検索するために使うであろう、3〜5個のターゲットキーワードを特定します。以下を考慮します：

これはどのような問題を解決するか？
どのような技術を使用しているか？
どのようなドメインに属するか？

これらのキーワードは以下に含まれている必要があります：リポジトリ名（可能であれば）、About説明文、READMEのH1およびH2ヘッダー、トピックタグ。

ステップ3: メタデータ最適化

About説明文

理想は120文字未満、最大250文字
「何であるか」ではなく「何をするか」で始める
主要キーワードを自然に含める
形式：<アクション動詞> <何を> <誰/何のために>。<主な差別化要因>

トピックタグ

3つのカテゴリから10〜20個のタグを選択：

目的タグ -- プロジェクトの機能
技術スタックタグ -- 使用技術
ドメインタグ -- 分野または業界

以下で適用：

gh repo edit {OWNER}/{REPO} --add-topic tag1 --add-topic tag2 ...

ステップ4: README書き換え

READMEはランディングページであり、ドキュメントではありません。

READMEテンプレート

設定で利用可能なユーザー情報に基づいてバッジを調整：

<div align="center">

# <プロジェクト名>

**<一行ピッチ -- 平易な英語で何をするか>**

<br />

[![このリポジトリにスターを付ける](https://img.shields.io/github/stars/{OWNER}/{REPO}?style=for-the-badge&logo=github&label=%E2%AD%90%20%E3%81%93%E3%81%AE%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%AB%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%92%E4%BB%98%E3%81%91%E3%82%8B&color=yellow)](https://github.com/{OWNER}/{REPO}/stargazers)

{X_HANDLE} が設定されている場合、スターバッジの隣に追加：

&nbsp;&nbsp;
[![@{X_HANDLE} をフォロー](https://img.shields.io/badge/Follow_%40{X_HANDLE}-000000?style=for-the-badge&logo=x&logoColor=white)](https://x.com/{X_HANDLE})

{X_HANDLE} が空の場合は、Followバッジを完全にスキップします。

次にクレデンシャルバッジを続けます：

<br />

[![<バッジ1>](shields-url)](<リンク>)
&nbsp;
[![<バッジ2>](shields-url)](<リンク>)

---

<一段落のピッチ。どのような問題を解決するか？なぜ気にする必要があるのか？>

[インストール](#install) | [仕組み](#how-it-works) | [機能](#features) | [貢献](#contributing)

</div>

バッジルール

行1（CTA -- 大きく目立つように）：

ライブカウント付きスター数バッジ -- 常に最初、style=for-the-badge、黄色
Xでのフォローバッジ -- {X_HANDLE} が設定されている場合のみ

行2（クレデンシャルバッジ -- 同じサイズ）：

すべてのバッジは style=for-the-badge を使用 -- サイズを混在させない
2〜4個の関連するものを選択：ライセンス、PR歓迎、言語/フレームワーク、ビルドステータス

セクションの順序

なぜこれが存在するか / 問題 -- ペインポイントについて2〜3文
Before vs After（任意） -- 比較表
インストール / クイックスタート -- 5ステップ未満、理想的には1コマンド
仕組み -- 視覚的なワークフロー（ASCII図、表、番号付きステップ）
機能 / ユースケース -- 表または箇条書き、スキャン可能
内部構成 / 構造 -- 必要に応じてファイルツリー
設定 / オプション（任意）
セキュリティ（任意）
コントリビューティング -- 短く、歓迎する感じで
ライセンス -- 一行
CTA付きフッター -- スター + フォローバッジを繰り返す

フッターテンプレート

設定から動的に構築：

---

<div align="center">

帰属行 -- 利用可能な設定フィールドから構築：

作者 + 会社 + ウェブサイトの場合：[NAME](GITHUB) が [COMPANY](COMPANY_URL) で制作 | [WEBSITE](WEBSITE_URL)
作者 + 会社（ウェブサイトなし）の場合：[NAME](GITHUB) が [COMPANY](COMPANY_URL) で制作
作者 + ウェブサイト（会社なし）の場合：[NAME](GITHUB) 制作 | [WEBSITE](WEBSITE_URL)
作者のみの場合：[NAME](GITHUB) 制作
何もない場合：github-optimization スキルで制作

<br />

**これが役に立つなら：**

[![このリポジトリにスターを付ける](star-badge-url)](stargazers-url)

{X_HANDLE} が存在する場合は、ここにもFollowバッジを追加します。

</div>

ライティングルール

絶対に守るべきものです。これらが文体を定義します。

やるべきこと：

人間が友人に説明するように書く。短い文。能動態。
各セクションをメカニズムではなく価値から始める
「あなた」を使って読者に直接語りかける
抽象よりも具体を優先
パラグラフは最大2〜3文に抑える
比較には表を使用する

やってはいけないこと：

AIの決まり文句を使わない：「活用」「効率化」「強化」「シームレス」「堅牢」「最先端」「革命」「パワーを活用」「ワークフローを向上」「スーパーチャージ」
文を「このプロジェクトは...」や「このツールは...」で始めない
文章の壁を作らない
受動態を使わない
間投詞を使わない：「基本的に」「本質的に」「単に」「ただ」
感嘆符を使わない

ヘッダーにおけるSEO：

H1には主要キーワードを含める必要がある
H2には二次キーワードを自然に含める
人間のために書くが、配置は意図的に行う

ステップ5: 追加要素

不足している場合に追加：

LICENSE -- ユーザーが特に指定しない限りMIT
CONTRIBUTING.md -- 短く、歓迎する感じで、3ステップのプロセス

以下のものは、依頼がない限り追加しない：CODE_OF_CONDUCT.md、SECURITY.md、.github/ISSUE_TEMPLATE/

ステップ6: 公開

すべての変更を説明メッセージとともにコミット
リモートにプッシュ
gh repo edit でリポジトリメタデータを更新
ユーザーに報告：変更点、新しい説明文、追加されたトピック、ライブURL

完了前のチェックリスト

スター成長ナレッジベース

ユーザーが「どうやったらもっとスターを獲得できますか？」「ローンチ戦略」「リポジトリを宣伝する」などと尋ねた場合、このナレッジベースを使用してアドバイスします。このセクションは参考資料であり、最適化パイプラインの一部ではありません。

チャネルランキング（ROI順）

順位	戦術	労力	期待スター数	リスク
1	一斉ローンチ（HN + Reddit + X + PH 同日）	高（1日準備）	200〜2,000以上	なし
2	Awesomeリストへの登録	低（PR）	ゆっくり増加、複合効果	なし
3	README最適化 + ソーシャルプレビュー	中（1時間）	その他すべての取り組みに3倍の効果	なし
4	GitHub SEO（名前、トピック、説明文）	低（30分）	長期的な受動的発見	なし
5	README内のデモGIF/動画	中	劇的にコンバージョン率向上	なし
6	独自のAwesomeリストを作成	中	ゆっくり増加 + 相互プロモーション	なし
7	ニュースレターへの投稿	低（メール）	フィーチャーあたり50〜500	なし
8	YouTubeチュートリアル	高	長期的持続性に最も効果的	なし
9	Xでの相互リスト mentions	低	ネットワーク依存	なし
10	Hacktoberfestタグ付け（10月）	低	50〜200季節変動	スパムPR
11	Discord/コミュニティ構築	高（継続的）	維持/アドボカシー	なし
12	カンファレンス登壇	高	直接的には低、複合効果は高	なし

Hacker News プレイブック

最適な時間帯： 火曜日〜木曜日、太平洋時間午前8〜10時。日曜日午後6〜9時は競合が少ない。

タイトル形式： Show HN: [名前] — [具体的に何をするか]

効果的な方法： マーケターではなく同僚のように書く。バズワードは使わない。問題から始める。最初の1時間はすべてのコメントに返信する。最初の5分以内に自分自身で実質的な最初のコメントを投稿する。

閾値： トップ10に入るには、最初の30分で8〜10の正当なupvote + 2〜3の思慮深いコメント。

アカウント要件： 最良の結果を得るには、技術的なコメント履歴がある250以上のカルマ。新しいアカウントはモデレーションの対象となることが多い。

リング検出は厳格。 「私のHN投稿をupvoteしてください」とツイートしてはいけない。プライベートチャンネル（メール、Slack、Discord）で人に知らせる。

実際の結果：

Lago: 48時間以上1位、1,000スターへの主要なドライバー
Encore: 単一のShow HNから1週間で1,500スター
平均: 24時間で121スター、1週間で289スター

Reddit プレイブック

投稿の2週間以上前からカルマを積む。 Redditの90/10ルール：90%が正当なアクティビティ、10%が自己宣伝。

サブレディット	備考
r/SideProject（453K）	自己宣伝を明示的に許可
r/programming（600万以上）	宣伝厳禁、「どうやってXを構築したか」が効果的
r/selfhosted（50万以上）	非常に高いコンバージョン率
r/webdev	「Showoff Saturday」のみ
r/opensource	リンク掲示に好意的、ボリュームは低め
r/coolgithubprojects	GitHubリポジトリ専用

期待値： 成功した投稿あたり50〜300スター。サブレディットごとにメッセージを調整する。

Product Hunt プレイブック

投票リセット： 毎日PST午前12時1分。最初の4時間はupvoteが非表示。

1位に必要なupvote数： 平日600〜800、週末400〜600。

最適な曜日： 火曜日〜木曜日。

期待値： 「今日の製品」トップ5から200〜1,000スター。1位は500〜2,000以上を生み出す可能性あり。

タイムライン：

4〜6週間前：200〜500人のメール登録者を構築
1週間前：すべてのアセットを準備
ローンチ当日：PST午前12時1分に公開、すべてに返信、PST午前6時に一斉メール

Twitter/X プレイブック

効果的なもの： 短いデモ動画/GIFはテキストよりも効果的。サポーターからのツイートは自己ツイートよりも多くのスターを生む。米国時間の平日朝（東部時間午前9〜11時）。

期待値： ツイートによるスター獲得の7%増加。バイラル動画ツイートは6時間で1,600スターに達する可能性あり。

一斉ローンチ戦略

急成長しているすべてのリポジトリが使用したメタ戦略：

タイミング	アクション	期待スター数
前週	ニュースレターに投稿（TLDR、Console.dev、Changelog）	--
ローンチ当日午前	HNに「Show HN」を投稿（火〜水、東部時間午前8〜11時）	平均121、最大1,500
ローンチ当日午後	Redditに投稿（r/programming、r/selfhosted、ドメインサブ）	50〜300
ローンチ当日	デモ動画をツイート + サポーターに共有を依頼	50〜500以上
ローンチ当日	Product Huntに公開	200〜1,000
ローンチ週	AwesomeリストのPRを送信	ゆっくり増加、複合効果

このスキルは 199-biotechnologies/github-optimization-skill に基づいています。

お気に入りのAIに質問する

プレビュー

ドキュメント