github-repo

GitHub リポジトリオプティマイザー

このスキルは、GitHub リポジトリをベストプラクティスに照らして監査し、リポジトリをプロフェッショナルで、参加しやすく、適切に保守されているように見せるファイルを生成または改善します。gh CLI を使って稼働中のリポジトリを操作するほか、ローカルの git ディレクトリやユーザーが提供したファイルにも対応します。

実装手順は AGENTS.md に記載されています — 特定のファイルを生成または改善する必要がある場合は、そちらを読んでください。このファイルにはワークフローと監査チェックリストが記載されています。

ワークフロー

1. リポジトリのコンテキストを収集する — 対象を特定し、情報を集めます
2. 監査を実行する — リポジトリの対外的な品質をあらゆる面から評価します
3. ファイルを生成または改善する — 不足しているファイルや改善が必要なファイルを作成します。手順は AGENTS.md に記載されています。
4. メタデータと読みやすさを確認する — リポジトリの説明と README の紹介文に metadata-check を、文章が中心のファイルに readability-check を実行します。
5. 検証する — 出力が正確で完全であることを確認します

---

フェーズ 0：コンテキストの収集

収集する主な情報：リポジトリ名、説明、言語／フレームワーク、README の有無と品質、存在するコミュニティ関連ファイル、Issue／PR テンプレートの状況、CI/CD の状況、リリース履歴、ブランチ数。認証済みであれば gh CLI を使用し、そうでなければローカルファイルを読み取ります。

---

フェーズ 1：監査

各カテゴリを 10 点満点で評価します。それぞれについて、実際の状態を引用した具体的な所見を 2～4 件挙げます。

README の品質（x/10）

README はありますか？プロジェクト名と明確な一文での説明、バッジ行（ビルド／ライセンス／バージョン）、プロジェクトの内容・目的・対象者を説明する概要、クイックスタート（インストールと初回使用が 3 ステップ以内）、コード例、視覚的なプロジェクトの場合はスクリーンショット／デモ、設定ドキュメント、コントリビューションへのリンク、ライセンスへの言及が含まれ、適切に構成されていますか？500 行未満で、任意の内容を <details> にまとめていますか？

リポジトリのメタデータ（x/10）

• 有用な説明が設定されていますか（空欄や「My awesome project」ではありませんか）？
• 関連性の高いトピック／タグが設定され、網羅されていますか？
• 該当する場合、Web サイトの URL が設定されていますか？
• ソーシャルプレビュー画像がアップロードされていますか？
• 未使用の場合、「Packages」「Environments」「Deployments」のセクションは非表示になっていますか？

コミュニティ関連ファイル（x/10）

• CONTRIBUTING.md — 存在しますか？開発環境のセットアップ、コードスタイル、テスト、PR の手順を説明していますか？
• SECURITY.md — 存在しますか？非公開の報告窓口と対応時間を明記していますか？
• CODE_OF_CONDUCT.md — 存在しますか？標準として Contributor Covenant 2.1 を採用していますか？
• LICENSE — ルートに存在しますか？プロジェクトの種類に適したライセンスですか？
• SUPPORT.md — 存在しますか？バグ報告とサポートに関する質問を分けていますか？
• CHANGELOG.md — Keep a Changelog 形式に準拠していますか？

組織の場合は、組織全体で既定のコミュニティ関連ファイルを提供する .github リポジトリがあるか確認します。

Issue と PR のテンプレート（x/10）

• YAML ベースの Issue フォーム（.github/ISSUE_TEMPLATE/*.yml）に、少なくともバグ報告と機能リクエストがありますか？順序付けのための番号付きファイル名を使用していますか？
• 空の Issue を無効にし、外部サポートへのリンクを設定する config.yml がありますか？
• 説明、関連 Issue（Closes #XXX）、変更の種類のチェックボックス、テストのチェックリストを含む PR テンプレートがありますか？
• ディレクトリごとにレビュー担当者を定める CODEOWNERS ファイルがありますか？

CI/CD と自動化（x/10）

• テスト、リンティング、ビルド用の GitHub Actions ワークフローがありますか？README に成功状態を示すバッジがありますか？
• Dependabot または Renovate が設定されていますか？
• コード品質のチェック（CodeQL、リンティングのアクション）はありますか？
• 古い Issue を管理していますか？

リリースとブランチの整理（x/10）

• 変更履歴を含むタグ付きリリースがありますか？セマンティックバージョニングに準拠していますか？
• 古いブランチを整理していますか？
• export-ignore を設定した .gitattributes がありますか？
• 自動リリース（semantic-release または release-please）を導入していますか？

---

フェーズ 2：ファイルを生成または改善する

監査結果に基づいて、不足しているファイルや改善が必要なファイルを生成します。上書きする前には必ず確認してください。詳細な手順については AGENTS.md を読んでください。

影響度に基づくファイル生成の順序：README.md、LICENSE、CONTRIBUTING.md、SECURITY.md、CODE_OF_CONDUCT.md、issue templates、PR template、CHANGELOG.md、SUPPORT.md、設定ファイル（dependabot.yml、CODEOWNERS、FUNDING.yml）。

AGENTS.md のセクション：README の生成、コミュニティの健全性に関するファイル（CONTRIBUTING、SECURITY、CODE_OF_CONDUCT）、Issue テンプレート、組織レベルの設定（.github リポジトリ、組織プロフィール、非公開のメンバープロフィール、ドメイン認証、ルールセット）。

---

フェーズ 2.5：メタデータと読みやすさの確認

1. メタデータの確認 — metadata-check スキル。 リポジトリの説明（最初の約 100 文字が検索結果やプロフィールカードに表示されます）と、README の冒頭の紹介文に対して実行します。
2. 文章の確認 — readability-check スキル。 文章が多いすべてのファイルに対して実行します。最低限 README を対象とし、CONTRIBUTING.md と SECURITY.md を作成した場合は、それらも対象にします。

修正を直接適用します。コードが中心のファイル（issue templates、workflow YAML）は対象外にします。

---

フェーズ 3：検証

• ファイルが正しい場所にあることを確認します。
• README 内のすべての内部リンクが機能することを確認します。
• バッジの URL が正しい形式であることを確認します。
• gh を利用できる場合は、リポジトリの About セクション（説明、トピック、Web サイト URL、ソーシャルプレビュー）を更新するようユーザーに案内します。これらはファイルだけでは設定できません。
• 作成・変更した内容と、ユーザーが次に行うことをまとめます。

---

出力形式

スコア表（6 項目、各 x/60）、実際の状態を引用した項目別の調査結果、生成・変更したファイルの一覧、ユーザー向けの次の手順。