---
name: antithesis-launch
description: >
  Launch an Antithesis run with snouty by discovering the harness layout,
  building the right Docker Compose config, running `snouty validate`,
  bailing on validation failure, and then submitting `snouty launch` with sane
  metadata. Use when the user wants to send, submit, or launch an Antithesis
  run. This skill takes duration in minutes as input.
compatibility: Requires Docker Compose v2, a container engine (docker or podman), and snouty (https://github.com/antithesishq/snouty).
metadata:
  version: "2026-10-21 4f8d80b"
---

# Antithesis Launch

**Skill version:** `2026-10-21 4f8d80b`

## Prerequisites

- DO NOT PROCEED if `snouty` is not installed. See `https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md` for installation options.
- DO NOT PROCEED if `snouty` is older than 0.8.0. Use `snouty --version` to find the version. Use `snouty update` to 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 writes `docker compose`; use `docker-compose` instead when that is the CLI snouty names.

## Goal

Launch an Antithesis run in this order only:

1. `docker compose build` (skip if directed to use pre-built images)
2. `snouty validate`
3. if validation fails, stop and report the error
4. `snouty launch`

## Required Input

- `duration` in 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.yaml` intended for Antithesis. Prefer directories like `antithesis/config`, but support non-standard layouts.
- Treat these as strong Antithesis signals: nearby `scratchbook/` or `test/` directories, compose content mentioning `/opt/antithesis`, `ANTITHESIS_` env vars, `setup_complete`, or existing `snouty` examples.
- If multiple compose files look plausible, prefer the one referenced by repo docs or existing `snouty launch` examples. If the choice is still ambiguous, ask the user instead of guessing.
- Use the directory containing `docker-compose.yaml` as the `snouty validate <CONFIG>` and `snouty 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=docker` to 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 version` must print `Docker Compose version ...`, because podman falls back to the `podman-compose` Python 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_test` when using a docker-compose.yaml file and to `basic_k8s_test` when 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 requires `ANTITHESIS_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 launch` unless the build succeeded and `snouty validate` exited successfully.

```sh
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 launch` command shape before submission.
- If validation fails, stop immediately and show the failing command plus the key error.
- The `--json` flag makes `snouty launch` emit machine-readable output containing a `run_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 validate` succeeded before `snouty launch` was invoked.
- The run set `source`, `test-name`, `description`, and `duration` explicitly, 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 doctor` reported.
- Missing blockers such as `duration`, `ANTITHESIS_REPOSITORY`, or an ambiguous config location caused a stop instead of a bad submission.