mcpField
G
github-codespaces-efficiency

github-codespaces-efficiency

github.com/githubクラウド・DevOps40.5k101 回インストール今日更新
リポジトリ

github-codespaces-efficiency について

リポジトリの GitHub Codespaces の効率を監査し、改善するスキルです。証拠に基づいて起動時間や費用の対策を提案し、日常的な開発ツールと開発体験への配慮も促します。

主な機能

  1. 01devcontainer と Codespaces の利用状況を監査
  2. 02マシンサイズとプリビルド範囲を評価
  3. 03アイドルタイムアウトとイメージサイズを調整
  4. 04根拠のある改善案を最大3件選定
  5. 05変更を検証し期待される影響を報告

活用シーン

  1. 01Codespaces の起動遅延を調査
  2. 02Codespaces の費用要因を確認
  3. 03リポジトリに devcontainer を設定
  4. 04既存の Codespaces 設定を評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill github-codespaces-efficiency

インストール後、Claude Code で/github-codespaces-efficiencyを入力して読み込まれたか確認します。

同梱ファイルreferences/codespaces.mdreferences/review-rubric.md

詳細

GitHub Codespaces の効率化

GitHub Codespaces の効率化に取り組む際の、簡潔な入り口としてこのスキルを使用します。リポジトリを調査して無駄を特定し、必要なリファレンスだけを読み込みます。

.devcontainer/ がまだ存在しない場合は、references/codespaces.md を読み込み、以下の手順に進む前にベースラインを定義してください。

このスキルを使用する場面

  • ユーザーが Codespaces の起動を速くしたい、または Codespaces の利用料金を抑えたい場合。
  • リポジトリに .devcontainer/ がある場合、または Codespaces の設定について明確な質問がある場合。
  • ユーザーが devcontainer の最適化、マシンのサイズ選定、プリビルド戦略、またはアイドルタイムアウトについて尋ねた場合。
  • ユーザーが初めて Codespaces を設定する場合、または新しい .devcontainer/ を一から作成するサポートを必要としている場合。

必要なものだけを読み込む

  • references/codespaces.md — devcontainer、マシンのサイズ選定、プリビルド、アイドルタイムアウトに関するガイダンスとレポート。
  • references/review-rubric.md — レビューを行う場合にのみ読み込みます。

基本的なワークフロー

1. まず計測する
find .devcontainer -maxdepth 2 -type f
gh codespace list
repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
gh api "/repos/$repo/codespaces/machines"

gh の認証に失敗する場合、またはユーザーにリポジトリ管理者スコープがない場合は、.devcontainer/ ファイルの静的解析を進め、マシンタイプとプリビルドに関する推奨事項は未検証として記載します。

確認項目：2 GB を超える devcontainer イメージ、または 10 個を超える機能、利用状況のデータで正当化できるサイズを超えるマシンタイプ、存在しない devcontainer-lock.json（多くのリポジトリはロックファイルのサポート以前から存在するため、追加を推奨します）、対象範囲が広すぎるプリビルド、利用パターンに合っていないアイドルタイムアウト。

2. ガードレールを適用する

推奨する前に、提案する修正が以下のルールをそれぞれ満たしているか確認してください。

  1. チームが日常的に使うツールを削除しない — 必要な開発ツールや拡張機能を取り除く修正は除外します。
  2. 小さいほど常に良いとは考えない — マシンのコストと開発者体験や処理能力のバランスを取ります。
  3. devcontainer を本番用イメージにしない — チームが明示的に必要としている場合を除き、本番環境専用の依存関係を追加する修正は除外します。
  4. 段階的な変更を優先する — .devcontainer/ が存在しない場合に限り、新規作成時のベースラインが適切です。既存の設定を再構成する変更は除外せず、注意点として示します。
  5. リポジトリの変更と組織設定を分ける — リポジトリで編集可能なファイルと、組織またはユーザーレベルの Codespaces 設定を混在させる修正は、明確に分けた 2 つの推奨事項にします。
3. 上位 3 件の修正を選ぶ

以下の 6 つの候補から、手順 1 の監査証拠によって裏付けられ、かつ手順 2 のすべてのガードレールを満たすものだけを残します。候補を、推定される月間コスト削減額（USD）の順に並べます。両方の条件を満たす候補をすべて選びますが、最大 3 件までとします。

  1. devcontainer をスリム化する — 日常的な開発作業に不要な機能、パッケージ、拡張機能を削除し、イメージを 2 GB 未満、機能数を 10 個未満にします
  2. マシンタイプを適切なサイズにする — 観測された利用パターンに合わせます。データがない場合は、前提を明示します
  3. プリビルドの対象範囲を限定する — デフォルトブランチ、過去 14 日間にアクティブだった release/* ブランチ、および週に 5 件を超える Codespaces が作成されるブランチで有効にし、それ以外では無効にします
  4. アイドルタイムアウトを調整する — デフォルトは 30 分、ほとんどのセッションが 30 分未満で終了する場合は 15 分、ほとんどのセッションがより長く続く場合は 60 分にします
  5. 使用されていない拡張機能やポートフォワーディングのルールを削除する
  6. devcontainer イメージのサイズを縮小し、レイヤーキャッシュを改善する
4. 検証する
  • テスト用の Codespace を起動し、devcontainer の変更が想定どおりにビルドおよび起動することを確認します。
  • テレメトリーが利用できる場合は、観測された利用状況に基づいてマシンのサイズを検証します。それ以外の場合は、未検証として記載します。
  • 予期しないビルドや起動の失敗は、設定が正しく見える場合でも実際のバグとして扱います。

必須の出力

無駄の原因： [コストまたは起動時間を最も押し上げる要因]

提案する修正： [監査の証拠に基づき、ガードレールを満たす上位3つの変更]

検証： [実環境で実証済み／静的解析のみ／残るリスク]

影響：

  • 起動時間：[予想値] ／ [入手可能な場合は実測値]
  • 月額費用：[予想値] ／ [入手可能な場合は実測値]
  • リソース使用率：[予想値] ／ [入手可能な場合は実測値]

参考資料

コメント

Markdown 対応