mcpField
D
devcontainer-exec

devcontainer-exec

github.com/liaoann開発042 回インストール4 週間前に更新
リポジトリ

devcontainer-exec について

Devcontainer 内でプロジェクトコマンドを実行するための運用スキルです。コンテナ、ユーザー、作業ディレクトリを先に確認し、ホスト側への誤ったフォールバックや曖昧な対象指定を防ぎます。

主な機能

  1. 01Devcontainer の特定と検証
  2. 02コンテナのユーザーと作業場所の確認
  3. 03docker exec によるコマンド実行
  4. 04ホスト作業とコンテナ作業の区別
  5. 05コンテナのライフサイクルに関する安全規則

活用シーン

  1. 01コンテナ内でプロジェクトをビルドまたはテストする
  2. 02コンテナ内で lint や型チェックを実行する
  3. 03ワークスペースのマウントと実行パスを確認する
  4. 04起動や対象選択が曖昧な状況に対処する

インストール

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

$npx skills add https://github.com/liaoann/skills --skill devcontainer-exec

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

同梱ファイルlifecycle.mdresolution.md

詳細

Devcontainer Exec

コンテナを一度特定したら、プロジェクトのコマンドはそのコンテナ経由で実行します。ソースがバインドマウントされている場合は、ホストで編集し、コンテナで実行します。.devcontainer/ ディレクトリは、プロジェクトの環境ポリシーを確認する目印であり、無関係なコンテナ作業を実行する理由ではありません。

ホスト：ファイルツール、git、gh、docker。コンテナ：インストール、ビルド、テスト、リント、型チェック、コード生成、マイグレーション、アプリの実行。

特定と検証

ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
docker ps --filter "label=devcontainer.local_folder=$ROOT" --format '{{.ID}}\t{{.Names}}'

VS Code と devcontainer CLI は、このラベルをコンポーズのサイドカーではなく、開発コンテナに設定します。完全一致するものがない場合は、resolution.md を読んでください。複数一致する場合は、推測せず、必ず確認してください。バインドマウントを共有しているだけでは、同一である証明にはなりません。

選択したコンテナを調べます。

docker inspect -f '{{index .Config.Labels "devcontainer.metadata"}}' <container>
docker inspect -f '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' <container>
  • ユーザー： 現在の devcontainer.json に明示された remoteUser／containerUser。それがなければメタデータフラグメント内の最後の remoteUser（なければ containerUser）。それもなければ .Config.User。それもなければ root です。メタデータは JSON 配列、または古いコンテナではオブジェクトです。.Config.User がエディターのユーザーを反映しているとは限りません。root として実行すると、ホスト上のファイルが root 所有のままになることがあります。
  • 作業ディレクトリ： リポジトリを含むバインドマウントから導出します：Destination + (host_path − Source)。/workspaces/<repo> と決めつけたり、空の .Config.WorkingDir を信用したりしないでください。docker exec -u <user> -w <container_path> <container> ls で検証します。
  • ボリュームが裏付けるワークスペース： 停止して報告します。ホスト側のコピーは、コンテナにおける信頼できるソースではありません。

実行

docker exec -i -u <user> -w <container_path> <container> bash -lc '<command>'

非 TTY ツールでは -t ではなく -i を使用します。環境変数は -e KEY=value で渡し、コンテナ内の相対パスを使用します。パイプライン全体は、1 つのシェルコマンドとして引用符で囲みます。長時間実行されるコマンドも docker exec 経由で実行します。

シェル／PATH の解決に失敗した場合は、resolution.md を読んでください。コンテナが消失または停止した場合は再特定します。コマンドごとに再特定する必要はありません。

ライフサイクルと安全上の境界

実行中のコンテナがない場合、またはコンテナの起動、作成、停止、削除が必要な場合は、操作する前に lifecycle.md を読んでください。ホストでの実行に切り替えないでください。環境の変更や永続的な影響を伴うコマンドを実行する前に、承認を得てください。コンテナでの実行は、テストの隔離を保証するものでも、本番環境へのアクセスを許可するものでもありません。

そのコンテナを明示した承認なしに、コンテナを削除してはいけません。agent の所有者ラベルは削除の権限を与えるものではなく、排他的に使用されている証明にもなりません。エディターがコンポーズコンテナを共有していることがあります。

出力

最初のプロジェクトコマンドを実行する前に、一度だけ報告します。

Devcontainer: <name> (<short-id>)
Workspace:    <host_path> → <container_path>
Exec:         docker exec -i -u <user> -w <container_path> <name> bash -lc '<cmd>'

完了条件

すべてのプロジェクト実行で、検証済みのコンテナ、ユーザー、ワークスペースを使用したか、コマンドを一切実行せずにブロッカーを明示していること。ホストでの代替実行、曖昧な対象の選択、ボリュームに基づくソースの不一致、未承認のコンテナ削除が発生していないこと。

コメント

Markdown 対応