repo-scaffold

リポジトリのひな形作成

標準的なファイルと設定を使用して、GitHub リポジトリを初期化します。このスキルでは、LICENSE、CONTRIBUTING.md、SECURITY.md、CODEOWNERS、.gitignore、.editorconfig、YAML ベースの Issue テンプレート、PR テンプレート、CI 設定のひな形、およびオプションの安全対策ファイルを生成します。既存のファイルからプロジェクトの種類を検出し、それに応じて各テンプレートを調整します。

インストール

claude skill install repo-scaffold

使用する場面

このスキルは、次のような場合に使用してください。

• 新しい GitHub リポジトリをゼロから設定する
• 既存のリポジトリに不足している標準ファイルを追加する
• プロジェクト間でリポジトリ設定を標準化する
• プライベートリポジトリをオープンソースとして公開する準備をする

使用方法

/repo-scaffold [repo-path] [--license MIT|Apache-2.0|ISC] [--public] [--ci github-actions|none]

フラグ	デフォルト	説明
repo-path	. (cwd)	Git リポジトリのルートへのパス
--license	MIT	ライセンスの種類（MIT、Apache-2.0、ISC、GPL-3.0、BSD-2-Clause）
--public	off	.public-repo、.pii-allowlist、.commit-msg-blocklist を含める
--ci	github-actions	CI プロバイダーのひな形（github-actions または none）

手順

ステップ 1：リポジトリのパスを検証する

対象のパスが初期化済みの Git リポジトリ（.git/ を含む）であることを確認します。そうでない場合は処理を中止し、ユーザーに知らせます。明示的な許可なしに git init を実行してはいけません。

ステップ 2：既存ファイルをスキャンする

リポジトリのルートと .github/ ディレクトリを調べ、このスキルが生成するファイルが存在するか確認します。競合リストを作成します。既存のファイルを上書きしてはいけません。 競合がある場合はその内容を提示し、スキップするファイルまたは置き換えるファイルをユーザーに尋ねます。

ステップ 3：プロジェクトの種類を検出する

目印となるファイルを確認して、主な言語とツールを特定します。

目印となるファイル	プロジェクトの種類
package.json	Node.js / JavaScript / TypeScript
pyproject.toml、setup.py、requirements.txt	Python
Cargo.toml	Rust
go.mod	Go
複数の目印	複数言語
上記のいずれもない	汎用

複数の目印が見つかった場合は複数言語のプロジェクトとして扱い、該当するパターンを組み合わせます。

ステップ 4：ファイルを生成する

検出したプロジェクトの種類と言語に適した内容で各ファイルを生成します。テンプレート、パターン、形式仕様については REFERENCE.md を参照してください。

4a. LICENSE

--license が指定されていない場合は、使用するライセンスをユーザーに尋ねます。デフォルトは MIT です。現在の年とリポジトリ所有者の名前（git config user.name から取得するか、ユーザーに尋ねます）を挿入します。選択の参考として、REFERENCE.md のライセンス比較表を確認してください。

4b. .gitignore

検出したプロジェクトの種類に応じた言語固有の除外パターンを生成します。複数言語のリポジトリではパターンを組み合わせます。OS レベルの除外（.DS_Store、Thumbs.db）とエディターの除外（.vscode/、.idea/）は必ず含めます。

4c. CONTRIBUTING.md

フォーク、ブランチ、PR に関する貢献ガイドを生成します。次の項目を含めます。

• フォークとクローンの手順
• ブランチの命名規則（feat/、fix/、docs/）
• コードスタイルに関する注意事項（リンター設定が検出された場合はそのリンク）
• コミットメッセージの形式
• PR チェックリスト

4d. SECURITY.md

次の内容を含むセキュリティポリシーを生成します。

• サポート対象バージョンの表（検出できる場合はパッケージのバージョンを記入）
• 脆弱性の報告方法（メールを使用し、公開 Issue では報告しない）
• 対応期間の目安

4e. CODEOWNERS

トップレベルのディレクトリ構成をスキャンし、CODEOWNERS ファイルを生成します。デフォルトでは、各ディレクトリをリポジトリ所有者に割り当てます。カスタマイズ方法を説明するコメントを追加します。

4f. .editorconfig

検出したプロジェクトの種類に適した設定を生成します。

• インデントのスタイルとサイズ
• 行末文字
• 行末の空白を削除
• 最終行に改行を挿入
• 文字セット（utf-8）

4g. .github/ISSUE_TEMPLATE/bug-report.yml

次の項目を含む、YAML フォーム形式のバグ報告テンプレートを生成します：説明、再現手順、期待される動作、実際の動作、環境、および任意のスクリーンショット。YAML フォームの仕様については REFERENCE.md を参照してください。

4h. .github/ISSUE_TEMPLATE/feature-request.yml

次の項目を含む、YAML フォーム形式の機能リクエストテンプレートを生成します：問題の説明、提案する解決策、検討した代替案、および追加のコンテキスト。

4i. .github/pull_request_template.md

変更の概要、変更の種類（チェックボックス）、実施したテスト、チェックリストのセクションを含む PR テンプレートを生成します。

4j. .github/workflows/ci.yml

GitHub Actions 用の CI のひな形を生成します（--ci none の場合を除く）。以下を含めます。

• main へのプッシュ時とプルリクエスト時に実行
• 言語に適したセットアップ手順
• lint 手順（ESLint、ruff、clippy、golangci-lint）
• テスト手順（言語に適したテストランナー）
• 追加手順用のプレースホルダーコメント

4k. オプション：安全性関連ファイル（--public の場合）

--public が渡された場合は、以下も生成します。

• .public-repo — リポジトリが公開されていることを示す空のマーカーファイル
• .pii-allowlist — 1 行に 1 つの正規表現を記載し、用途を説明するコメントヘッダーで始めます
• .commit-msg-blocklist — 1 行に 1 つの用語を記載し、コメントヘッダーと一般的なデフォルト設定で始めます

ステップ 5：計画を提示する

ファイルを書き込む前に、作成するファイルの一覧と各ファイルの説明を 1 行ずつ提示します。競合のためにスキップするファイルも示します。続行する前に、ユーザーに確認を求めます。

ステップ 6：ファイルを書き込む

確認されたすべてのファイルを書き込みます。各ファイルを書き込むたびに報告します。

ステップ 7：要約

次の項目を含む要約表を出力します。

• 作成したファイル（パス付き）
• スキップしたファイル（理由付き）
• 推奨される次の手順（例：CODEOWNERS の確認、CONTRIBUTING.md のカスタマイズ、CI へのシークレットの追加）

主な原則

1. 既存ファイルを上書きしないでください。 必ず最初にスキャンし、競合を示して確認を求めます。
2. 書き込み前に必ず確認を求めてください。 計画を提示し、明示的な承認を得ます。
3. 言語に適したデフォルトを使用してください。 プロジェクトの種類を検出し、すべてのテンプレートをそれに合わせて調整します。
4. 最小限でありながら必要十分にしてください。 きちんと保守されたリポジトリに必要な標準セットのみを生成し、それ以外は追加しません。
5. 組み合わせて利用できるようにしてください。 各ファイルは単独で機能します。後からスキルを再実行して、不足しているファイルを既存ファイルに影響を与えずに追加できます。

参考資料

• REFERENCE.md — ライセンスの比較、.gitignore のパターン、YAML テンプレート仕様、CI のひな形、CODEOWNERS の構文、.editorconfig の設定、SECURITY.md と CONTRIBUTING.md のテンプレート
• EXAMPLES.md — Node.js、Python、公開リポジトリの構成例