Crabbox

Crabbox

Use Crabbox when a project needs remote proof, larger cloud capacity, a fresh PR checkout, a reusable warmed box, GitHub Actions-style setup, durable run logs/results, UI proof artifacts, or sync from a dirty local checkout.

Detect Crabbox

• Treat repo-root crabbox.yaml or .crabbox.yaml as an intentional signal to use this skill for validation work. .crabbox.yml is not a supported config filename.
• If neither config exists, command -v crabbox still identifies an installed CLI. Run crabbox doctor before depending on it for remote work.
• Inspect config before executing it. Detection does not imply permission to expose secrets, bypass command approval, or start paid infrastructure.

Source Of Truth

• Run Crabbox from the repository root; sync mirrors the current checkout.
• Treat repo-local crabbox.yaml or .crabbox.yaml as executable project automation. Review it before remote runs, especially provider, actions, jobs, profiles, env.allow, artifacts, and cleanup policy.
• Verify the installed binary before relying on examples: command -v crabbox && crabbox --version && crabbox --help | sed -n '1,120p'.
• Use crabbox providers or crabbox providers --json for the current provider/capability matrix; provider docs can lag the compiled binary.
• Use crabbox doctor for live readiness checks and crabbox config show to inspect merged config without printing secrets.
• Prefer local targeted tests for tight edit loops. Move to Crabbox for broad suites, package-heavy checks, Docker/E2E/live-provider proof, cross-OS proof, UI proof, or commands that bog down the local machine.

Auth And Config

Brokered operation needs a coordinator URL and token. First login usually needs an explicit broker URL:

crabbox login --url <broker-url>
crabbox whoami