| name | repo-onboarding |
| description | 既存リポジトリの構造、主要技術、ビルド方法、テスト方法、重要ファイルを短時間で把握する。 新しいリポジトリを理解したいとき、最初の地図を安全に作りたいとき、 または作業開始前に repo bootstrap まで完了したいとき。
|
| license | Personal |
repo-onboarding
この skill は、未知のリポジトリを短時間で安全に理解するための手順です。
repo を読むだけでなく、共同作業の場として触り始める依頼では
bootstrap 完了までを onboarding の一部として扱います。
こんなときに使う
- 新しいリポジトリの入口を短時間で把握したいとき
- README と設定ファイルから build / test の根拠を拾いたいとき
- 後続の実装や調査に入る前に「最初の地図」を作りたいとき
目的
- 主要言語と技術スタックを把握する
- エントリーポイント、ビルド方法、テスト方法を把握する
- 重要な設定ファイルとドキュメントを特定する
- 後続作業のための「最初の地図」を作る
- 必要なら repo bootstrap を実行し、共同作業に必要な safety valve をそろえる
作業モード
- Read-only onboarding: repo の構造や build / test 方法を把握する依頼。調査を主に進める。
- Bootstrap onboarding: 「ここを作業場所にしたい」「repo として整えたい」「共同開発の場にしたい」のように、
repo を今後触る前提の依頼。
repo-secure-check で不足が出たら、提案で止めず script 実行まで進める。
ワークフロー
ステップ 1 — 入口ファイルを確認する
まず README、docs、solution / workspace / manifest 系ファイルを確認します。
ここで全体像をつかんでから詳細へ入ると、後段の build / test 調査がぶれにくくなります。
ステップ 2 — build / test / dependency の根拠を拾う
ビルド・テスト・依存関係・lint に関わる設定ファイルを確認します。
コマンドは推測で作らず、README や設定ファイルに根拠があるものを優先します。
ステップ 3 — bootstrap が必要かを判定する
target repo を今後触る依頼なら、repo-secure-check で
repo instructions / Copilot hooks / .githooks / core.hooksPath / GitHub Actions workflows の不足を確認します。
この判定を先に置く理由は、安全弁が欠けたまま onboarding を完了扱いにしないためです。
ステップ 4 — 不足があれば bootstrap を実行する
不足がある場合は onboarding を続ける前に bootstrap task として次を実行します。
以下は home sync 済みの %USERPROFILE%\.copilot\scripts\ から実行する前提とし、
script の既定値で %USERPROFILE%\.copilot を SourceRoot として扱います。
- git repo でなければ
git init
%USERPROFILE%\.copilot\scripts\sync-to-repo.ps1 -TargetRepoPath <repo>%USERPROFILE%\.copilot\scripts\install-git-hooks.ps1 -TargetRepoPath <repo>%USERPROFILE%\.copilot\scripts\repo-secure-check.ps1 -TargetRepoPath <repo>
ここでは 「提案した」で止めず、script 実行結果まで確認する のが重要です。
repo-secure-check の各項目がすべて OK になるまでを bootstrap 完了条件として扱います。
.github/workflows/*.yml|*.yaml が不足している場合は、repo の技術スタックに合う workflow template を明示的に選び、
必要な skill または sync-to-repo.ps1 の導線で導入します。CI workflow は組織・言語ごとに差が出るため、
ユーザーに黙って汎用 workflow を追加せず、意図と対象 runtime を確認してから実行します。
ステップ 5 — ディレクトリと入口を要約する
repoInstructions / Copilot hooks / .githooks / core.hooksPath / GitHub Actions workflows がすべて OK になったら、
主要ディレクトリの役割を要約し、エントリーポイント候補を特定します。
ステップ 6 — テスト導線を確認する
テストの場所、実行手段、カバレッジの有無を確認します。
未確認のものは推測で埋めず、「未確認事項」として分離します。
特に見るファイル
- C#:
*.sln, *.slnx, *.csproj, Directory.Build.*, global.json
- Python:
pyproject.toml, requirements.txt, setup.cfg, pytest.ini
- C:
Makefile, CMakeLists.txt, meson.build
- TypeScript:
package.json, tsconfig.json, eslint.config.*, vite.config.*
- Rust:
Cargo.toml, Cargo.lock, rust-toolchain.toml
出力形式
以下の順で短くまとめる。
- Bootstrap 状態（Read-only か Bootstrap 実行済みか。実行した場合は
repo-secure-check の結果）
- リポジトリの目的
- 主要言語と主要技術
- ディレクトリ構造の要点
- ビルド方法
- テスト方法
- 重要な設計上の注意点
- 未確認事項
方針
- まず全体像をつかみ、細部に潜りすぎない
- 見つけたコマンドは、設定ファイルや README に根拠があるものを優先する
- 学習用の説明では「何が入口か」を明確にする
- local safety valve や GitHub Actions workflow が不足している repo は、その事実を先に明示し、必要なら repo bootstrap を提案してから深掘りする
- ただし downstream repo を触る flow では、提案で止めず
.github/ と .githooks/ の同期、core.hooksPath 設定、再チェック完了までを bootstrap の一部として扱う
.github がない repo を「onboarding 完了」とは扱わない。最低でも repo-secure-check の各項目が OK になってから本調査へ進む%USERPROFILE%\.copilot\scripts\ が存在しない、または script 実行に失敗した場合だけ、その事実を block として明示して止まる
