github-readme について
GitHubリポジトリのREADMEを生成、監査、更新するClaudeスキルです。プロジェクトのファイルを調べて種類を判定し、品質、見つけやすさ、文体、安全性を体系的に確認します。
主な機能
- 01リポジトリの調査に基づくREADME生成
- 02読み取り専用監査によるREADME採点
- 03承認後に適用するREADME更新案
- 04ファイルと構成からのプロジェクト種別判定
- 05発見性とセキュリティ項目の確認
活用シーン
- 01新規リポジトリのREADME草案作成
- 02公開前のREADME品質確認
- 03プロジェクト変更後のドキュメント更新
- 04公開リポジトリ情報の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/github-readmeを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
EXAMPLES.mdLICENSEREFERENCE.md詳細
GitHub README ジェネレーター
プロジェクトの種類の検出、文体の調整、見つけやすさに関するガイダンス、スコア付きの品質監査を通じて、リポジトリの README を生成、監査、または更新します。
インストール
git clone https://github.com/thatrebeccarae/claude-marketing.git && cp -r claude-marketing/skills/github-readme ~/.claude/skills/
使用する場面
- 新しい公開リポジトリを作成する際に、一からしっかりした README が必要な場合
- 既存の README の品質、見つけやすさ、セキュリティ上の問題を監査する場合
- リポジトリの進化（新しい依存関係、機能、構成）に合わせて README を更新する場合
- 公開リリースに向けてリポジトリを準備し、見つけやすさを最適化したい場合
モード
/github:readme generate [repo-path] # Scan repo, detect type, generate README
/github:readme audit [repo-path] # Score existing README (read-only, 0-100)
/github:readme update [repo-path] # Re-scan, silent audit, patch with approval
repo-path を省略した場合、デフォルトでは現在の作業ディレクトリが使用されます。
ステップ 0：解析と検証
次の形式を想定します：/github:readme {mode} [repo-path]
- モードの抽出 —
generate、audit、またはupdate。それ以外の値、または値がない場合 → 使用方法のヒントとともにエラーを表示します。停止します。 - repo-path の抽出 — 2 番目の引数。省略した場合は現在の作業ディレクトリを使用します。
- 検証 — パスが存在し、ディレクトリであり、
.gitを含むことを確認します。満たさない場合 → エラーを表示します。停止します。
repo_path（絶対パス）と mode を保存します。
ステップ 1：リポジトリのスキャン
利用可能なファイルを読み取ってコンテキストを収集します。ファイルが存在しない場合は、エラーにせずスキップします。
パッケージ／設定ファイル（技術スタックの検出）：
package.json— Node／TypeScript／ReactCargo.toml— Rustpyproject.toml、setup.py、requirements.txt— Pythongo.mod— Gotsconfig.json— TypeScript の確認Dockerfile、docker-compose.yml— コンテナ化Makefile、justfile— ビルドシステム.github/workflows/— CI/CD
ディレクトリ構成：
- リポジトリのルートで
lsを実行し、最上位の構成を確認します - 注目する項目：
src/、bin/、lib/、scripts/、docs/、tests/、skills/、templates/、plugins/、.github/
既存のドキュメント：
README.md、CONTRIBUTING.md、SECURITY.md、LICENSE、ARCHITECTURE.md、CHANGELOG.md、CODE_OF_CONDUCT.md、llms.txt
Git リモート：
git -C {repo_path} remote get-url originを実行します- URL から
{owner}と{repo}を抽出します - 公開／非公開を判定します：
.public-repoマーカーがある場合は公開、-devサフィックスがある場合、またはマーカーがない場合はユーザーに確認します
ステップ 2：プロジェクトの種類を検出
スキャンで得られた情報に基づき、リポジトリを次の種類のうち必ず 1 つに分類します。
| 種類 | 判定材料 |
|---|---|
| ツール／CLI | package.json に bin フィールドがある、CLI のエントリーポイント、man ページ、コマンドパーサー（yargs、clap、cobra）がある |
| ライブラリ／SDK | main／exports／module フィールドがある、npm／PyPI／crates.io で公開されている、CLI エントリーがない |
| コレクション／マーケットプレイス | 独立した項目を複数含む：skills/、templates/、plugins/、recipes/ ディレクトリに 3 つ以上のサブディレクトリがある |
| Web アプリ | React／Vue／Svelte／Next／Nuxt、サーバーフレームワーク（Express、FastAPI、Actix）、デプロイ設定（Vercel、Dockerfile）がある |
| 個人／実験プロジェクト | 小規模なリポジトリ（ファイル数 20 未満）で、パッケージ公開設定がなく、CI がなく、semver タグもない |
判定が曖昧な場合は、ユーザーに確認します。project_type として保存します。
ステップ 3：見つけやすさの監査
README の内容を生成または監査する前に、リポジトリレベルで見つけやすさに関する次の項目を確認します。調査結果と提案をユーザーに提示します。
リポジトリ名：
- キーワードが豊富で検索しやすい名前か確認します（例：
markdown-lint-actionはmy-linterより適切です） - 一般的すぎる名前（
app、project、tool、my-thing）に注意を促します
GitHub の概要／説明：
- 利用可能な場合は
gh repo viewで読み取ります - 3〜8 語にし、主要なキーワードを先頭に置く必要があります
- 説明がない、または一般的すぎる場合は改善案を提案します
トピック：
- GitHub では最大 20 個のトピックを設定できます
- 検出した技術スタック、プロジェクトの種類、分野に基づいて関連トピックを提案します
typescript、cliなどの広いトピックと、markdown-parser、github-actionなどの具体的なトピックを含めます
ソーシャルプレビュー画像：
- 画像がない場合はその旨を伝え、作成を提案します（推奨サイズ：1280x640px）
llms.txt（任意）：
- リポジトリがライブラリ／SDK またはツール／CLI の場合、
llms.txtファイルの生成を提案します - 目的：LLM がプロジェクトを正しく理解し、正確に推奨できるようにします
見つけやすさに関する提案を提示します。ユーザーは提案を受け入れる、スキップする、または後回しにできます。これらの提案は README の生成を妨げません。
ステップ 4：生成／監査／更新
生成モード
4a. 既存の README を確認 — 存在する場合は、上書きするか、代わりに更新モードを使用するかを確認します。
4b. セクションを選択 — プロジェクトの種類に基づいて選択します（下記の「セクションメニュー」を参照）。
4c. 文体の調整：
- デフォルト：プロフェッショナルな製品の文体 — 明快で、直接的で、曖昧な表現や誇張した宣伝文句は使いません
- 個人／実験用リポジトリ、またはユーザーが明示的に許可した場合：一人称の使用を認めます
- 決して使わないもの：問題の記述での受動態、文章中の絵文字、誇張した宣伝文句
4d. 各セクションを生成：
- タイトル＋説明 — パッケージ設定またはディレクトリから名前を取得します。120 文字未満の太字の説明を 1 行で記載します
- バッジ — 下記の「バッジの選択」を参照します
- はじめに／インストール — バージョンを含む前提条件、インストール手順、初回実行コマンドを記載します。20 行未満にします
- 種類別セクション — 「セクションメニュー」に従います。スキャンしたコンテキストが十分にある場合のみ含めます
- 「理由」セクション（個人／実験用のみ）— ユーザーに 2～3 文の説明を求めます。内容を捏造してはいけません
- ライセンス — LICENSE ファイルの種類を確認します。ファイルへのリンクを 1 行で記載します
4e. PII／インフラ情報の除去チェックを実行（下記を参照）。書き込む前に違反箇所を削除します。
4f. 書き込み {repo_path}/README.md を書き込み、概要を表示します。
監査モード（読み取り専用）
既存の README を読み込みます。ファイルは一切変更しないでください。
品質シグナルを確認し、重み付けされた評価基準に照らして採点します。
| カテゴリー | 重み | 確認項目 |
|---|---|---|
| 明確さ | 25 | 1 行の説明は明確か？ タイトルは内容を的確に表しているか？ |
| 使いやすさ | 25 | インストール／セットアップコマンドは機能するか？ コード例はあるか？ はじめには 20 行未満か？ |
| 信頼性 | 15 | バッジはあるか？ バッジの URL は有効か？ ライセンスセクションはあるか？ |
| 最新性 | 15 | バージョン番号はパッケージ設定と一致しているか？ 技術スタックはリポジトリと一致しているか？ 古いリンクはないか？ |
| セキュリティ | 20 | PII やインフラ情報の漏えいはないか？ API キー／トークンはないか？ 非公開のホスト名／IP アドレスはないか？ |
採点： 各カテゴリーを 0～100 点で採点し、最終スコアは加重平均とします。
=== README Audit: {repo-name} ===
Score: {X}/100
Clarity: {X}/25
Usability: {X}/25
Credibility: {X}/15
Currency: {X}/15
Security: {X}/20
PASS:
- {passing checks}
WARN:
- {warnings with specific detail}
FAIL:
- {failures with specific detail and fix suggestion}
更新モード
- リポジトリを再スキャンし（ステップ 1）、現在の状態を検出します
- サイレント監査を実行 — 結果を保存し、表示しません
- 更新計画を生成 — カテゴリーごとに diff 形式で分類します：
[STRUCTURE]— セクションの欠落／古い内容、バッジの変更[CONTENT]— 古いバージョン番号、古くなった技術情報[VOICE]— 曖昧な表現、誇張した宣伝文句、受動態[SECURITY]— PII／インフラ情報に関する違反（自動的に適用）
- プレビューを表示 — 提案する変更を番号付きリストで表示します
- ユーザーの承認 —
y（すべて）、N（キャンセル）、またはカンマ区切りの番号 - 適用し、最終的な PII チェックを実行して、ファイルを書き込み、概要を表示します
プロジェクトの種類別セクションメニュー
| セクション | ツール／CLI | ライブラリ／SDK | コレクション | Web アプリ | 個人用 |
|---|---|---|---|---|---|
| タイトル＋説明 | 必須 | 必須 | 必須 | 必須 | 必須 |
| バッジ | 必須 | 必須 | 必須 | 必須 | 任意 |
| はじめに／インストール | 必須 | 必須 | 必須 | 必須 | 必須 |
| 使用方法／コマンド | 必須 | -- | -- | -- | -- |
| API リファレンス | -- | 必須 | -- | -- | -- |
| カタログ／索引 | -- | -- | 必須 | -- | -- |
| 機能 | 推奨 | 推奨 | -- | 必須 | -- |
| 設定 | 推奨 | 推奨 | -- | 推奨 | -- |
| アーキテクチャ | -- | -- | -- | 推奨 | -- |
| これを作った理由 | -- | -- | -- | -- | 必須 |
| 対象ユーザー | 推奨 | 推奨 | 推奨 | -- | -- |
| コントリビューション | 推奨 | 必須 | 推奨 | 推奨 | -- |
| ライセンス | 必須 | 必須 | 必須 | 必須 | 必須 |
音声ガイドライン
| 種類 | デフォルトのトーン | 冒頭の例 |
|---|---|---|
| ツール／CLI | 直接的、実用的 | 「CI パイプライン向けの高速な Markdown リンティング。」 |
| ライブラリ／SDK | 技術的、正確 | 「Stripe API 向けの型付き HTTP クライアント。」 |
| コレクション | 整理され、見やすい | 「再利用可能な GitHub Actions ワークフローを 50 個以上収録。」 |
| ウェブアプリ | 製品を中心に、明快 | 「チーム分析機能を備えたリアルタイムのプロジェクトダッシュボード。」 |
| 個人向け | 一人称、意見を明確に | 「読書習慣を記録するもっと良い方法が必要でした。」 |
必ず守ること： 直接的で具体的、意見を明確にし、段落は短く（最大 4 文）。 避けること： 曖昧な表現、誇張した宣伝文句、問題の説明での受動態、本文中の絵文字。
バッジの選定
検出された技術スタックに基づき、技術バッジを 1〜3 個、ライセンスバッジを最低 1 個生成します。
すべてのバッジに style=for-the-badge を使用します。一般的なパターン：
バッジの順序：技術スタック（左）→ スター数 → ライセンス（右）。
個人情報／インフラ情報の除去
すべてのモードで実行します。生成済みまたは既存の README テキストをスキャンして、以下を確認します。
- 非公開のホスト名
- IP アドレス（特に 10.x、172.16-31.x、192.168.x、100.x の Tailscale）
- 内部ネットワーク／VLAN 名
- デバイス識別子またはシリアル番号
- 公開すべきでないクライアント名または雇用主名
- 個人のメールアドレス
- API キーまたはトークン（
sk-、token_、ghp_、Bearer、長い英数字の文字列） - 内部の Docker／サービス設定（非公開のポートマッピング、コンテナ名）
- SSH 設定の参照（エイリアス、秘密鍵のパス）
違反が見つかった場合： それぞれを列挙し、削除または伏せ字にして、削除した内容をユーザーに示します。 セキュリティ違反への対応は任意ではありません。 更新モードでは自動的に適用します。
主要原則
- 推測せず、検出する。 リポジトリをスキャンし、実際に存在する内容に合わせて構成を調整します。
- デフォルトでプロフェッショナルに。 一人称の語り口は任意であり、デフォルトではありません。
- 見つけやすさを重視する。 リポジトリ名、説明、トピック、llms.txt も README の一部です。
- 完全さより品質を重視する。 空のプレースホルダーが並ぶ肥大化した README より、よく書かれたセクションを絞って掲載します。
- セキュリティは譲れません。 個人情報／インフラ情報の除去は、毎回、すべてのモードで実行します。
- 監査モードは読み取り専用です。 監査中にファイルを変更してはいけません。