Read this when:
- changing
crabbox init; - adding or renaming repo-local config keys;
- changing the generated workflow stub or agent instructions.
crabbox init prepares a repository for Crabbox so contributors and agents do not have to
memorize the full command surface. It writes a small set of repo-local files, then leaves
project-specific behavior in version control where it can be reviewed like any other config.
crabbox init writes three files (paths are overridable; defaults shown):
.crabbox.yaml # --config
.github/workflows/crabbox.yml # --workflow
.agents/skills/crabbox/SKILL.md # --skill
Each path can be relocated with the matching flag, and existing files are protected: init
exits with an error if a target file already exists. Pass --force to overwrite. See the
init command reference for the full flag list.
The generated config holds the project-specific defaults that should travel with the repo:
profile(defaults to<repo>-check) andclass(beast);capacitymarket/strategy/fallback defaults;actionshydration settings (workflow path, hydrate job, runner labels, runner version, ephemeral flag);syncoptions (delete, checksum, gitSeed, fingerprint, timeout) and the size guardrails (warnFiles/warnBytes/failFiles/failBytes);sync.excludepaths (seeds.cache,.turbo,dist,node_modules, plus any detected package-manager caches);env.allow(seedsCIandNODE_OPTIONS);sshuser/port and the orderedfallbackPortslist (["22"]by default; set[]to disable fallback).
The generated skill points agents at the warmup/reuse workflow rather than ad-hoc commands:
warm a box early with crabbox warmup, reuse the returned slug for interactive checks, run
checks with crabbox run --id <slug> -- <command>, inspect a failure over crabbox ssh, and
crabbox stop <slug> when finished. It also instructs agents not to debug product failures on
a reused box that fails its sync sanity check: stop it, warm a fresh box, and rerun.
crabbox init --detect inspects the repository for runnable checks and, when it finds any,
writes a jobs.detected entry plus matching run.preflightTools so crabbox run --preflight
can verify the tools the detected job expects. Run the resulting job with
crabbox job run detected.
The detector walks the repo (skipping .git, node_modules, dist, bin, .cache,
.turbo, .venv, target, and similar) and recognizes:
- Go modules (
go.mod) ->go test ./..., preflight toolgo. - Node packages (
package.json) -> install + run the first available script amongtest:ci,test,check,build(placeholdertestscripts are ignored). The package manager is inferred from thepackageManagerfield or lockfile (npm,pnpm,yarn,bun); preflight tools and cache excludes are set accordingly. - Rust crates (
Cargo.toml) ->cargo test, preflight toolcargo, excludestarget. - Makefiles with a root
testtarget ->make test, preflight toolmake.
Each detected command is scoped to its manifest directory, so monorepos with packages in
subdirectories get correctly nested commands. When nothing runnable is found, init reports
that and leaves the jobs section for you to fill in manually.
The generated .github/workflows/crabbox.yml is the bridge to Actions-backed hydration. By
default Crabbox runs supported setup steps locally; the self-hosted GitHub runner path is used
when full Actions semantics are required. The stub exposes a hydrate job triggered by
workflow_dispatch, which checks out the requested ref, installs dependencies, writes the
hydration state file ($HOME/.crabbox/actions/<lease-id>.env) that Crabbox polls for
readiness, and keeps the job alive for the requested window. See
Actions hydration for the runtime flow.