How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/antithesishq/antithesis-skills --skill antithesis-launchBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Antithesis Launch
Skill version: 2026-10-15 84b188a
Prerequisites
- DO NOT PROCEED if
snoutyis not installed. Seehttps://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.mdfor installation options. - DO NOT PROCEED if
snoutyis older than 0.8.0. Usesnouty --versionto find the version. Usesnouty updateto update. - Run
snouty doctor. It checks the container runtime and the compose CLI. Report both to the user and build with that same pair. This skill writesdocker compose; usedocker-composeinstead when that is the CLI snouty names.
Goal
Launch an Antithesis run in this order only:
docker compose build(skip if directed to use pre-built images)snouty validate- if validation fails, stop and report the error
snouty launch
Required Input
durationin minutes is required. If the user did not provide it, ask before submitting the run.
Discovery
- Start from any user-provided path, command, or Antithesis directory name.
- Otherwise, inspect the repo to understand how the harness is wired. Check nearby
AGENTS.md,README*,Makefile*, and Antithesis-specific scripts before choosing commands. - Find the config directory by locating the
docker-compose.yamlintended for Antithesis. Prefer directories likeantithesis/config, but support non-standard layouts. - Treat these as strong Antithesis signals: nearby
scratchbook/ortest/directories, compose content mentioning/opt/antithesis,ANTITHESIS_env vars,setup_complete, or existingsnoutyexamples. - If multiple compose files look plausible, prefer the one referenced by repo docs or existing
snouty launchexamples. If the choice is still ambiguous, ask the user instead of guessing. - Use the directory containing
docker-compose.yamlas thesnouty validate <CONFIG>andsnouty launch --config <CONFIG>argument. - Build against that exact file:
docker compose -f <CONFIG>/docker-compose.yaml build. - snouty never builds or pulls images, so every image must already be in the store of the engine snouty selects. snouty prefers podman when both engines are installed.
- Use
SNOUTY_CONTAINER_ENGINE=dockerto force snouty to use docker's store. - When using podman, build with
podman compose -f <CONFIG>/docker-compose.yaml build. That wrapper execs Docker Compose v2 against podman's API socket, so the image lands in podman's store. Check the provider first:podman compose versionmust printDocker Compose version ..., because podman falls back to thepodman-composePython tool when it finds no Compose v2 binary.
Run Arguments
- Determine the launcher in this order: explicit user input, existing repo docs/scripts/examples, otherwise default to
basic_testwhen using a docker-compose.yaml file and tobasic_k8s_testwhen using a kubernetes setup. - If explicitly directed to launch a run against a pre-built image, run
snouty launch --config-image <CONFIG_IMAGE>with the user-supplied image reference. - Otherwise, use
snouty launch --config <CONFIG>, which requiresANTITHESIS_REPOSITORY. Reuse the current environment if it is already set. If not, stop and ask the user for it. - Always set all of these explicitly:
--duration: the user-provided duration--source: repo name--test-name: repo name plus branch or config name--description: short, readable description of the run, including details such as the branch name, current goal, or what you changed since the last run.
- Allow overrides: When the user or another skill invoking this one specifies a launch parameter, use what they
gave you instead of the defaults described above.
Execution
- These commands can take a long time. Prefer background execution or generous timeouts instead of assuming quick completion.
- Do not run
snouty launchunless the build succeeded andsnouty validateexited successfully.
docker compose -f "$CONFIG_DIR/docker-compose.yaml" build
snouty validate "$CONFIG_DIR"
snouty launch \
--json \
--launcher "$LAUNCHER" \
--config "$CONFIG_DIR" \
--duration "$DURATION" \
--source "$SOURCE" \
--test-name "$TEST_NAME" \
--description "$DESCRIPTION"Output
- Report the config directory, compose build command, validate command, and final
snouty launchcommand shape before submission. - If validation fails, stop immediately and show the failing command plus the key error.
- The
--jsonflag makessnouty launchemit machine-readable output containing arun_id. Parse and report the run_id — it's needed to triage the run when it is done.
Self-Review
- The chosen config directory is the one that actually contains the Antithesis
docker-compose.yaml. - The build, validate, and run steps all point at the same config.
snouty validatesucceeded beforesnouty launchwas invoked.- The run set
source,test-name,description, anddurationexplicitly, using any caller-supplied values in preference to the defaults as well as any caller-supplied additional parameters. - The build used the compose CLI and container engine
snouty doctorreported. - Missing blockers such as
duration,ANTITHESIS_REPOSITORY, or an ambiguous config location caused a stop instead of a bad submission.




