mcpField
O
openclaw-crabbox

openclaw-crabbox

github.com/theangrypitテスト・品質039 回インストール今日更新
リポジトリ

openclaw-crabbox について

Crabboxのテスト環境選択と、分離されたリース管理を支援するコーディングスキルです。ローカルの対象チェックとCIを基本の検証経路とし、信頼境界や認証情報の扱いも定めています。

主な機能

  1. 01設定済みプロバイダーへの検証振り分け
  2. 02タスク専用リースの管理とクリーンアップ
  3. 03信頼済み・未信頼の実行経路の区別
  4. 04同期入力とCI失敗の確認

活用シーン

  1. 01変更に適した検証環境の選択
  2. 02別OSやデバイスでのチェック実行
  3. 03同期テストでのファイル欠落の調査

インストール

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

$npx skills add https://github.com/theangrypit/theangryskills --skill openclaw-crabbox

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
MIRROR.md
references/
diagnostics-and-e2e.md
providers-and-desktop.md
untrusted-aws.md

詳細

Crabbox

  • PR CI = 標準の幅広い検証です。 まず、対象を絞ったローカルテストと、対象を絞った lint/型チェック/フォーマットを行います。チェックに合格し、変更がビルドできたら、準備完了の PR を作成します。その後、CI で幅広いテストスイートを実行します。PR 作成前のテストスイート実行のために PR を保留してはいけません。
  • CI/ローカルのカバレッジに不足がある場合に限り、別の OS/デバイス、稼働中のプロバイダー/チャネル、時間のかかる E2E、負荷の高いベンチマークに Box を使います。実行するコマンドを用意し、すぐに許可が得られる場合に限り取得してください。
  • キューに入った場合:タスク所有のリクエストを停止し、ローカルで実行します。キューを待ったり、Testbox → AWS → その他のプロバイダーと順に試したりしてはいけません。
  • 実際の失敗を修正します。成功表示を得るためだけに再実行/再プッシュしてはいけません。失敗を変更に起因すると判断する前に、利用可能な CI の失敗分類を確認してください。

リポジトリの契約

  • スキルは、移植可能なルーティング、リース、同期、コマンド、クリーンアップを担います。
  • <check-command>、ランタイム/コンテナーイメージ、PR、ブートストラップは、信頼できる利用者向けの手順、パッケージスクリプト、またはハイドレーションワークフローから解決してください。
  • 不足しているコマンドを作り上げたり、別の利用者のセットアップをコピーしたりしてはいけません。
  • プロバイダー、ID、実行 URL、コマンド、結果を必ず報告してください。Testbox を「AWS Crabbox」と呼んだり、ローカル Docker をリモート検証と呼んだりしてはいけません。

承認と分離

  • 通常の設定済みの利用では、タスク所有のリースの作成/再利用/停止、一時状態、検証または必要な Crabbox の修復のためのクリーンなチェックアウト/ワークツリーに、別途承認は不要です。

  • ユーザーのチェックアウト、ブランチ、無関係な編集を保持してください。チェックアウトが未追跡の変更を含む、存在しない、または使用中の場合は、タスク所有のものを使ってください。

  • ソースの信頼性、認証情報、本番環境へのアクセス、予算、公開に関する境界を守ってください。

  • 信頼されていないリポジトリのラッパー/設定を、ローカルまたは認証情報がハイドレーションされた Testbox 上で実行してはいけません。シークレットのないフォーク CI、またはサニタイズ済みの直接 AWS 実行を使ってください。完全な head SHA ごとに新しいリースを使用し、インスタンスロール、Tailscale、ハイドレーションは使わず、転送するのは CI のみとします。

  • 信頼されていないコードを AWS で実行する前に、ロールなしの実行と SHA の証明を含む、完全な信頼されていないコード向け手順を読み、従ってください。証明を利用できない場合は、シークレットのないフォーク CI を使ってください。

  • 稼働中の認証情報を使う場合は、正確なキーを使い、安全な方法で注入する 1 つのコマンドに限ります。シークレットを出力したり、リポジトリ内のファイルやシェル履歴に記録したり、偽のキーを稼働中の検証に使ったりしてはいけません。安全な注入方法がない場合、ライブ認証は使用できません。取得した成果物にシークレットが含まれていないか確認してください。

  • 検証は利用者の一時状態/設定ディレクトリに分離し、オペレーターの通常のインストール環境を変更してはいけません。失敗した場合も含め、使用後は所有するリースを停止してください。

まずルートを決める

  • ソースの信頼性によって使用可能なプロバイダーは制限されますが、プロバイダーは選択されません。解決済みのプロバイダーを確認し、その選択を維持してください。
  • 通常は --provider を省略します。明示的に要求された場合、または検証でバックエンドのセマンティクスが必要な場合に限り、上書きしてください。サイズ、期間、ハイドレーションの失敗、容量を理由に上書きしてはいけません。
  • 先回りしたウォームアップや、プロバイダーの段階的な切り替えを行ってはいけません。
プロバイダー用途
blacksmith-testboxCI の準備が整っている、信頼できるメンテナーのソース。tbx_...
awsブローカー経由の直接実行、新しい PR、カスタム同期/環境変数/キャプチャ。cbx_...
local-container設定済み/要求されたローカル Docker。リモート検証ではありません
sshオペレーターが既に使用している macOS/Windows/WSL2 ホスト

事前確認

リポジトリのルートから、信頼できるインストール済みバイナリを 1 度選択します。

export CRABBOX="$(command -v crabbox)"
test -n "$CRABBOX"
"$CRABBOX" --version
"$CRABBOX" config show --json | jq '{provider, profile, target}'
"$CRABBOX" run --help
  • .crabbox.yaml と、ユーザー/環境の設定を含む解決済みの設定を読みます。
  • Testbox の場合は、command -v blacksmith と blacksmith --version も確認します。
  • 利用者が信頼できるラッパーを指定している場合、それが見つからない、または動作しないときは、信頼できるインストール/更新手順に従います。クリーンなタスク用チェックアウトでビルドする前に、正規のアップストリームを確認してください。
  • 隣接するチェックアウトを信頼できるものと見なしたり、オペレーターのバイナリをタスクのビルドで置き換えたりしてはいけません。
  • ラッパーの失敗は、同じ解決済みプロバイダー上でインストール済み CLI を使って切り分けてください。

信頼済み Testbox

解決済み/リクエスト済みの Testbox 専用です。プロバイダー中立のコマンドでは設定を保持し、明示的に上書きする場合のみ --provider blacksmith-testbox を追加してください。

"$CRABBOX" run --timing-json -- CI=1 <check-command>

複数のコマンドを使用する場合:ID を保存して再利用し、停止します。

"$CRABBOX" warmup --keep --timing-json
"$CRABBOX" run --id <tbx_id> --timing-json -- <check-command>
"$CRABBOX" stop <tbx_id>
  • 1 つのリースにつき、アクティブなコマンドは 1 つです。実行中に同期/再取得しないでください。--reclaim は、チェックアウトパスの所有権を意図的に移転する場合に限って使用します。
  • Testbox ネイティブの実行では、ID を再利用しても同期が行われます。ベースラインでは、変更のない再実行でも --no-sync に依存しないでください。無視される場合があります。
  • ベースまたはヘッドが変更された場合は、停止して再度ウォームアップしてください。古いリースを上書きしないでください。warmup --ref で指定できるのはブランチ/タグのみで、生の SHA は指定できません。同期済みルートで refs をチェックアウトしないでください。
  • Testbox ネイティブのステータス/停止コマンドでは --id を使用します。status に --json はありません。blacksmith testbox list --all または blacksmith testbox status --id <tbx_id> を使用してください。
  • 委任された Testbox では --fresh-pr、--full-resync、--script*、--env-helper、capture/download フラグは使用できません。Crabbox の stop は --timing-json を受け付けません。
同期済み入力を検証する
  • モジュール/フィクスチャが不足している場合は、必要な入力を凍結済みソースと比較し、Git の ignore ルールの否定指定を含め、同期の除外設定を調べてください。同期が成功しても、追跡対象ファイルが除外されている場合があります。
  • 不足しているパスと凍結済み Git blob をそれぞれ記録してください。レビュー済みの必要な入力のみを、タスク専用のリモートチェックアウトに復元し、バイト列を検証してください。変更済み/未追跡の入力は別途考慮してください。ネイティブ同期のたびに再確認してください。
  • ベースラインを再生成したり、無関係な状態をコピーしたり、除外設定を無効にしたり、不足しているファイルがすべて安全だと想定したりしないでください。
  • 同期のタイムアウトはテスト結果ではありません。ペイロードが送信されたかどうかを確認してください。不明な場合は、再試行する前にリース/呼び出しを調べてください。完了した証明はソースの識別情報とともに保持し、不足している検証のみ実行してください。

専門的な証明と診断

関連するレシピのみを読みます。ルーティングと即時利用可能性のルールは引き続き適用されます。

  • AWS への直接接続、コンテナ、デスクトップ、クロス OS:プロバイダーごとの正確なコマンド、ブローカー認証、有料 macOS クォータ/費用発生前の事前確認、デスクトップへの引き継ぎ。黙って代替しないでください。証明用アセットを製品リポジトリにコミットしないでください。
  • 診断と実際の E2E:キャプチャ/環境フラグ、障害レイヤー、ユーザーパスの証明。「Crabbox でテスト」は、実際のインストール/更新/オンボーディング/CLI/サービス/API の経路を意味し、リモートのユニットテストだけでは不十分です。全画面 CLI では実際の PTY を使用してください。Testbox のリビジョンを比較する場合は、1 回の同期済み呼び出し内で、デタッチされた一時的なワークツリーを使用してください。後続の実行では、ローカルソースが再同期されます。

コメント