github-repo-launch-page

GitHub リポジトリのローンチページスキル

目的

リポジトリを単なる「コードの置き場」から、次の質問に順番に答える公開プロジェクトページへと変えます。

1. これは何ですか？
2. 誰を対象にしていますか？
3. 今、注目する価値があるのはなぜですか？
4. 信頼できますか？
5. 5 分以内に試せますか？
6. 次にどこへ進めばよいですか？

このスキルでは、GitHub リポジトリを構成する以下の要素全体を扱います。

• リポジトリ名と製品名
• GitHub の About 説明
• ホームページ URL
• トピック
• README
• スクリーンショット、デモ、図、ソーシャルプレビュー
• ドキュメントの構成
• ライセンス、コントリビューション、セキュリティ、サポート関連のファイル

命名については、先に、または並行して github-repo-product-naming を実行してください。優れた README でも、弱い名前を完全に補うことはできません。

使用するタイミング

ユーザーから次の依頼があった場合に、このスキルを使用します。

• リポジトリの README を新規作成、または書き直す
• GitHub リポジトリをより魅力的で信頼できるものにしたり、「バズる」ようにしたりする
• ローンチ、共有、採用担当者、Hacker News、Reddit、LinkedIn、X 向けにリポジトリを準備する
• リポジトリの SEO や見つけやすさを改善する
• GitHub の About 説明、トピック、ウェブサイト、ピン留めしたリポジトリの見え方、ソーシャルプレビュー、ドキュメント、スクリーンショット、バッジ、Issue テンプレート、コントリビューション関連ファイルを設定する
• 成功しているオープンソース README のパターンをリバースエンジニアリングする

作成前の調査

利用可能な場合は、以下を確認してください。

• リポジトリ名、パッケージ名／アプリケーション名、CLI 名
• GitHub の About 説明、ホームページ URL、トピック、ライセンス、公開設定、アーカイブ状態
• README.md
• LICENSE
• CONTRIBUTING.md
• CODE_OF_CONDUCT.md
• SECURITY.md
• CHANGELOG.md
• .github/ISSUE_TEMPLATE/*
• .github/PULL_REQUEST_TEMPLATE.md
• docs/
• examples/
• demo/
• assets/
• screenshots/
• pyproject.toml、package.json、Cargo.toml、go.mod、Dockerfile、docker-compose.yml などのパッケージ関連ファイル
• テストと CI ワークフロー
• 既存のスクリーンショット、図、デモ GIF、動画、ランディングページ、ドキュメントページ、リリース
• プロジェクトに非公開情報、雇用主が所有する情報、秘密情報、または安全でない情報が含まれているかどうか

メタデータを自動で読み取れない場合は、手動チェックリストを求めるか、提示してください。

命名に関する依存関係

README を確定する前に、名前自体が望ましいイメージを伝えているか確認してください。

次のいずれかに当てはまる場合は、github-repo-product-naming を使用してください。

• リポジトリ名が社内ドキュメントのように聞こえる
• 名前が engineering-methods や workstation-setup のようなカテゴリ名にすぎない
• 名前が長すぎる
• 名前から誤ったイメージが連想される
• 名前から製品のアイデンティティが伝わらない
• ユーザーがより「強そう」で、覚えやすく、バズりやすい、またはオープンソースらしい名前を求めている
• リポジトリが複数リポジトリのエコシステムの一部で、命名の一貫性が必要である

README の中に命名の問題を埋もれさせないでください。命名は戦略的なレイヤーです。

リバースエンジニアリングしたローンチページのパターン

優れた公開リポジトリでは、通常、ページ上部に以下の要素が組み合わされています。

1. ヒーローブロック

一般的なパターン：

# ProjectName — concrete promise

> Memorable one-line tagline.

[badges]

![screenshot or banner](...)

One short paragraph explaining what it is, who it is for, and the concrete outcome.

優れたヒーローブロックは具体的です。内部アーキテクチャから説明を始めません。

効果的なバリエーション：

• 製品／ツールのページ：名前、気の利いたタグライン、バッジ、スクリーンショットを並べ、その後に具体的な運用上のメリットを示します。
• フレームワーク／プラットフォームのページ：中央にロゴを配置し、簡潔なカテゴリ説明、インストールコマンド、エコシステムへのリンクを示します。
• 研究／モデルのページ：論文／ブログ／モデルカードへのリンク、簡潔なモデル説明、図、セットアップ方法、モデル表、CLI と Python の使用方法を示します。
• コミュニティ／開発ツールのページ：ロゴ、個性、互換性、インストールコマンド、手動での確認／セキュリティに関する注意を示します。
• 開発者向けユーティリティのページ：最初にスクリーンショットを置き、「理由」を説明する箇条書き、簡単なインストール方法、プライバシー／セキュリティに関する注意、ドキュメントへのリンクを示します。

2. ポジショニングの段落

次の形式を使います。

<Project> is a <category> for <target user> who need to <job-to-be-done>. It helps them <outcome> by <mechanism/differentiator>, while <constraint or trust factor>.

例：

RepoPilot is a local-first CLI for maintainers who need to triage many GitHub issues quickly. It mirrors issues into SQLite, clusters duplicates, and produces reviewable summaries without sending private repository content to a hosted backend.

ProofStack turns private work evidence into public-safe career signal: resumes, LinkedIn sections, portfolio stories, articles, and interview material that preserve proof without leaking private details.

3. Why セクション

機能を網羅的に列挙する前に、## Why を使います。

優れた「Why」の箇条書きでは、困りごとが生じる場面を明確にします。

## Why

- Stop guessing which command to run first.
- Keep private data local by default.
- Make the happy path copy-pasteable.
- Give maintainers a quick mental model before they read the code.

よくない「Why」の箇条書きは曖昧です。

- Easy to use
- Fast
- AI-powered
- Modern

4. 詳細なドキュメントより前にクイックスタートを配置する

可能であれば、README の最初の約 100～150 行以内に、実際に動かせるクイックスタートを配置します。

クイックスタートに最低限含める内容：

## Quickstart

```bash
# install
...

# run
...
```

Expected result:

```text
...
```

セットアップが複雑な場合は、次のいずれかを用意します。

• Docker のクイックスタート
• ホステッドデモ
• GitHub Codespaces
• 入力と出力の例
• ドライランモード
• まだプロジェクトを実行できない場合は、スクリーンショットのみ

5. スクリーンショットやデモによる実証

次のうち少なくとも 1 つを追加します。

• ヒーロースクリーンショット
• 短い GIF
• CLI の録画
• アーキテクチャ図
• 変更前と変更後の画像
• 出力例
• ホステッドデモへのリンク
• ソーシャルプレビュー画像

すべてのビジュアルに、内容が伝わる alt テキストを付けます。説明のない装飾的なスクリーンショットは避けます。

6. 機能を示す箇条書き

成果とその実現方法を組み合わせた箇条書きを 5～7 項目使用します。

## Features

- **Local archive** — mirrors issues and PRs into SQLite for offline triage.
- **Duplicate clustering** — groups related reports before maintainers read them manually.
- **Reviewable output** — writes Markdown summaries instead of taking irreversible actions.

導入の判断に関係しない限り、実装の詳細は列挙しないでください。

7. 信頼性に関する情報

事実に基づき、関連性のある信頼性情報だけを記載します。

• ライセンス
• プライバシーモデル
• セキュリティモデル
• データの保存場所
• 必要な権限
• 制限事項
• 現在のステータス：アルファ、ベータ、本番、実験、アーカイブ
• 既知のリスク
• 対応 OS／Python／Node のバージョン
• テスト／CI の状況
• メンテナンス担当者

スター数、ダウンロード数、本番環境での利用者、スポンサー、ベンチマーク、所属などを捏造しないでください。

8. 次のステップへのリンク

上部付近に、直接アクセスできるリンクを記載します。

<p align="center">
  <a href="#quickstart">Quickstart</a> ·
  <a href="docs/">Docs</a> ·
  <a href="examples/">Examples</a> ·
  <a href="CHANGELOG.md">Changelog</a> ·
  <a href="CONTRIBUTING.md">Contributing</a>
</p>

README の推奨構成

リポジトリの種類に応じた別の構成が必要でない限り、次の標準構成を使用します。

# ProjectName — one-line concrete promise

> Memorable tagline.

[badges]

![Hero screenshot or banner](assets/social-preview.png)

Short positioning paragraph: what it is, who it is for, outcome, differentiator.

<p align="center">
  <a href="#quickstart">Quickstart</a> ·
  <a href="#features">Features</a> ·
  <a href="docs/">Docs</a> ·
  <a href="#contributing">Contributing</a>
</p>

## Why

## Features

## Quickstart

## Demo

## How it works

## Use cases

## Requirements

## Configuration

## Documentation

## Privacy and security

## Roadmap / status

## Contributing

## License

README の種類別構成

製品またはアプリ

ユーザー向けアプリを提供するリポジトリで使用します。

順序：

1. ヒーロー画像
2. ひと目で伝わる約束
3. スクリーンショット
4. 背景や理由
5. インストール
6. 初回実行手順
7. 機能
8. 権限／プライバシー
9. ドキュメント
10. サポート
11. ライセンス

フレームワークまたはライブラリ

開発者向けプラットフォーム、SDK、パッケージのリポジトリで使用します。

順序：

1. ロゴ／名前／タグライン
2. インストールコマンド
3. 最小限のコード例
4. エコシステムの構成図
5. 選ぶ理由
6. API ドキュメント／リファレンス
7. インテグレーション／使用例
8. コントリビューション
9. ライセンス

研究／モデルのリポジトリ

モデル、論文の実装、ベンチマーク、ML アーティファクトのリポジトリで使用します。

順序：

1. プロジェクト名
2. リンク：論文、ブログ、モデルカード、デモ、データセット
3. 短い概要
4. 図／アプローチ
5. セットアップ
6. モデル／データの表
7. CLI の使用方法
8. Python／API の使用方法
9. 評価／制限事項
10. 引用方法
11. ライセンス

CLI／開発ツール／設定のリポジトリ

ターミナルや開発ワークフロー向けツールのリポジトリで使用します。

順序：

1. 印象的でありながら正確なタグライン
2. アニメーションデモまたはスクリーンショット
3. インストールコマンド
4. よく使う 3 つのコマンド
5. 設定
6. 例
7. 安全性／手動確認に関する注意
8. トラブルシューティング
9. コントリビューションガイド

スキル／プラグインのリポジトリ

AI エージェント向けスキル、Claude Code プラグイン、Codex プラグイン、プロンプト、コマンド、再利用可能な指示をパッケージ化するリポジトリで使用します。

順序：

1. 製品名と具体的な用途
2. エコシステムとの互換性：Codex、Claude Code、OpenCode、ChatGPT、MCP など
3. インストールコマンド
4. 含まれるスキルの表
5. ワークフローの例
6. 安全性／プライバシーモデル
7. ローカル開発環境のセットアップ
8. コントリビューションと拡張ガイド

GitHub メタデータのチェックリスト

これらは README.md とは別に準備します。

リポジトリ名

リポジトリ名は github-repo-product-naming に従って選びます。

基本的な条件：

• 短い
• 発音しやすい
• 検索しやすい
• 覚えやすい程度に具体的
• 必要な場合を除き、-app、-tool、-repo などの不要な接尾辞を付けない
• README、パッケージ名、CLI 名、ドキュメント、ウェブサイト、インストールコマンドで大文字／小文字の表記を統一する

GitHub の「概要」説明

推奨文字数：70～140 文字。

形式：

<Category> for <target user> to <outcome> with <differentiator>.

例：

Local-first GitHub issue triage CLI for maintainers drowning in duplicate reports.

Engineering methods for code, agents, docs, security, reviews, and system architecture.

次のような表現は避けます。

• 「シンプルなツール……」
• 「AI を活用したアプリ……」
• 「このリポジトリには……が含まれています」
• 実装についてしか説明していない文

ホームページ URL

次のいずれかがある場合は、ホームページを追加します。

• ドキュメントサイト
• デプロイ済みアプリ
• デモ
• ブログ記事
• プロジェクトのランディングページ
• パッケージページ

トピック

トピックは最大20個まで設定できます。トピックは小文字で、単語をハイフンで区切り、見つけやすいものにしてください。

次のカテゴリを組み合わせてください。

• 分野：agentic-ai、developer-tools、workflow-automation
• 言語／フレームワーク：python、typescript、swift、langchain
• 成果物の種類：cli、macos、chrome-extension、github-profile
• 課題：issue-triage、browser-automation、readme-generator
• 対象ユーザー：maintainers、data-engineering、ai-agents

関連性のない人気トピックは追加しないでください。

ソーシャルプレビュー

リポジトリのソーシャルプレビュー画像を作成してください。

推奨事項：

• 1280 x 640 px
• PNG または JPG
• 1 MB 未満
• リンクプレビューで読める大きさのプロジェクト名
• 1文で伝える価値
• 役立つ場合はスクリーンショットやプロダクトのビジュアル
• 透明背景を意図的にテストする場合を除き、単色の背景

バッジ

バッジは控えめに使ってください。次のものを優先してください。

• パッケージのバージョン
• ライセンス
• CI
• ドキュメント
• リリース
• 対応プラットフォーム
• パッケージのダウンロード数。ただし、意味がある場合に限ります

バッジを20個並べて先頭に置かないでください。

再現可能な監査チェック

README の冒頭チェック

• 最初の5行以内に H1 がある。
• 最初の15行以内に1行の価値提案がある。
• 最初の100語で、カテゴリ、対象ユーザー、得られる成果、差別化要因を説明している。
• 詳細なドキュメントより前に、スクリーンショット、図、GIF、ロゴ、サンプル出力のいずれかが少なくとも1つある。
• リポジトリが実行可能でない場合を除き、150行目より前にクイックスタートまたはインストールへのリンクがある。
• 「TODO」、「lorem ipsum」、プレースホルダーのバッジ、リンク切れのデモが残っていない。

命名チェック

• 名前が単なるフォルダー名やカテゴリ名ではない。
• 名前から望ましいイメージが伝わる。
• 名前が、より強く誤ったイメージを想起させない。
• 名前に、文字どおりのカテゴリを説明するサブタイトルがある。
• リポジトリのスラッグが小文字で、URL に使用でき、インストールコマンドに適している。
• エコシステムの一部である場合、名前がそのエコシステムに合っている。
• 命名の判断が簡単でない場合、github-repo-product-naming の出力がある。

必須セクションのチェック

README には、最低限、次のセクションまたは同等のリンクを含めてください。

• 理由／動機
• 機能／できること
• クイックスタート／インストール
• 使い方／使用例
• 要件
• ドキュメント／その他の例
• ステータス／制限事項（成熟していない場合）
• コントリビュート／サポート
• ライセンス

リンクとアセットのチェック

• 相対リンクがすべて解決できる。
• 画像がすべて表示できる。
• 画像の代替テキストが内容を適切に説明している。
• ソーシャルプレビュー画像がある。
• README が GitHub の切り捨て制限を超えていない。
• README からリンクされているローカルドキュメントが存在する。
• コードスニペットに言語タグがある。

コマンドのチェック

• シェルコマンドをそのままコピーして実行できる。
• インストールコマンドがパッケージマネージャーのメタデータと一致している。
• クイックスタートが新規クローンから実行できるか、前提条件が明確に記載されている。
• 危険なコマンドを避けるか、説明を加えている。
• .env.example がない場合、コマンドがシークレットの存在を前提としていない。

メタデータのチェック

• 説明が得られる成果を中心にしている。
• 利用可能な場合、ホームページが設定されている。
• トピックが関連性のあるもので、小文字、ハイフン区切りで、20個以下になっている。
• ライセンスが存在し、README の記載と一致している。
• コントリビューターを募集する場合、Issue テンプレートとコントリビューションガイドラインがある。

主張内容のチェック

次のような主張は削除するか、書き換えてください。

• 検証できない
• 誇張されている
• 雇用主の機密情報に関わる
• 非公開の指標に基づいている
• 実際にはないスター数、ダウンロード数、ユーザー数を示している
• 許可なく提携関係を示唆している

出力形式

このスキルを適用する場合は、次の内容を作成してください。

1. 診断：現状で採用を妨げている要因。
2. 命名とポジショニング：
   • 現在の名前の評価
   • 提案するプロダクト名
   • リポジトリのスラッグ
   • キャッチフレーズ
   • 1文で説明するポジショニング
   • 採用しなかった名前とその理由
3. README：完全な README.md またはパッチ。
4. GitHub UI の設定：
   • About の説明
   • ホームページ URL
   • トピック
   • ソーシャルプレビューの提案
5. 作成するアセット：
   • スクリーンショット
   • バナー／ソーシャルプレビュー
   • デモ GIF
   • 図
6. リポジトリの整備に関する TODO：
   • ライセンス
   • コントリビューション
   • Issue テンプレート
   • ドキュメント
   • 変更履歴
   • セキュリティ／プライバシー
7. 再現可能なチェックの結果。

トーンのルール

次のようにします。

• 具体的な名詞を使います
• 観察できる成果を示します
• 段落を短くします
• 誇張より先に根拠を示します
• 制約を正直に伝えます
• 平易な英語を使います
• コピーして貼り付けられるコマンドを示します

次のことは避けます。

• 「革命的」
• 「ゲームチェンジャー」
• 説明を添えずに「シームレス」
• AI がどのタスクを実行するかを説明せずに「AI 搭載」
• プロジェクトの重要性をユーザーが理解する前に、膨大なアーキテクチャの説明をすること
• 個人的な実験を本番環境で使えるもののように装うこと

Arthur 固有のデフォルトの位置付け

Arthur Zakirov の公開リポジトリでは、リポジトリの根拠が異なることを示していない限り、次の公開向けに安全な位置付けをデフォルトとします。

Practical data/cloud engineer building small automation systems for high-friction personal and developer workflows.

よく使うテーマ：

• データエンジニアリング
• クラウドのワークフロー
• Python による自動化
• ブラウザー／タスクの自動化
• エージェント型 AI アプリケーション
• 個人生産性システム
• 開発者向けツール
• 公開ラボ／実践的な実験

既知のエコシステムの方向性：

• ProofStack — キャリアの実績と公開向けに安全な位置付け
• AgentDesk — マシンと AI エージェントのワークステーション設定
• SystemSmith — コード、エージェント、アーキテクチャのエンジニアリング手法

ユーザーが公開向けに安全な根拠を明示的に提示しない限り、非公開の雇用主への帰属、非公開企業のコード、本番環境での指標を主張しないでください。