Agent Skills

antithesis-launch

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.

Install

npx skills add https://github.com/antithesishq/antithesis-skills --skill antithesis-launch
SKILL.md

Antithesis Launch

Skill version: 2026-09-23 a8fe900

Prerequisites

  • DO NOT PROCEED if snouty is not installed. See https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md for installation options.
  • 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 webhook 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.
docker compose -f "$CONFIG_DIR/docker-compose.yaml" build
snouty validate "$CONFIG_DIR"
snouty launch \
  --json \
  --webhook "$WEBHOOK" \
  --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.

Related skills

azure-diagnosticsmicrosoft608KDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, troubleshoot functions, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, aazure-preparemicrosoft608KPrepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azazure-aimicrosoft608KUse for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.azure-deploymicrosoft607KExecute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: \"run azd up\", \"run azd deploy\", \"execute deployment\",

Search skills and MCP servers

Fuzzy search across 23,137 skills and servers