antithesishq

Authenticate `agent-browser` against an Antithesis tenant and read data from Antithesis web pages (triage reports, runs page, logs viewer, causality reports). Only invoke this skill when explicitly requested by another skill or the user. Requires interactive browser authentication and is unsuitable for fully headless workflows.

Interactively debug an Antithesis test run in the multiverse debugger (MVD): launch a session from a run, open a debugging-session URL, and inspect container filesystem and runtime state from inside the run.

Use Antithesis documentation efficiently for product, workflow, and integration questions. Prefer the snouty docs CLI when available, and otherwise request markdown versions of documentation pages directly.

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.

Search across all timelines in an Antithesis test run to find events, correlate property failures, and answer temporal questions about ordering and causation (e.g., did event A always precede failure B? do failures occur even without a preceding fault?).

Analyze a codebase to figure out how it should be tested with Antithesis: map the system, identify failure-prone areas and testable properties, and produce the research artifacts needed for workload and environment planning.

Scaffold the Antithesis harness for customers running Kubernetes: Convert helm charts, kustomize templates, or raw Kubernetes manifests into a minimized set of manifests for Antithesis. Verify the Kubernetes manifests are in the correct shape with snouty validate and a local cluster deploy. Hands it off to antithesis-launch if the user wants to submit a run. At the end, the user is ready to run antithesis-workload to build tests. If the desired setup is docker-compose, defer to the antithesis-setup skill.

Scaffold the Antithesis harness with docker-compose: initialize the working directory, write Dockerfiles and docker-compose.yaml with build directives, and prepare to submit your first Antithesis test run. If the desired setup is Kubernetes, defer to the antithesis-setup-k8s skill.

Investigate CI failures on a PR using gh and bk CLI tools. Trigger when the user asks about failing checks, Buildkite failures, or CI issues — including casual phrases like "why is CI red", "build broken", "checks failing", "what went wrong in CI", "nightly broke", "tests failing on this PR", or pastes a Buildkite URL. Also trigger when the user mentions a specific PR number and wants to understand why it's failing.

General guide for running tests and choosing the right test framework in Materialize. Trigger when the user wants to "run tests", "run testdrive", "run sqllogictest", "run mzcompose", "run cargo test", "run pgtest", "rewrite test results", "add a test", "reproduce a bug", "write a regression test", or mentions testing, testdrive, sqllogictest, mzcompose, pgtest, cargo test, nextest, flaky tests, or test failures. Use this skill even if the user just says "test this" or "how do I verify this works" without naming a specific framework. For deep guidance on specific frameworks, see the dedicated skills: mz-platform-checks (upgrade/restart survival), mz-parallel-workload (concurrent stress testing), and mz-limits-test (scaling to many objects).

Correctness invariants and architectural guidance for the adapter layer, coordinator, pgwire, peek paths, and timestamp oracle. Trigger when the user works on or asks questions about these subsystems — including "how does the coordinator work", "what are read holds", "explain the peek path", "how does timestamp selection work", "why does this query block". Also trigger when editing files in src/adapter/, src/pgwire/, or src/timestamp-oracle/.

Add, modify, or debug benchmark scenarios for measuring Materialize performance. Covers three frameworks: Feature Benchmark (single-operation micro-benchmarks), Scalability Test (SQL throughput under concurrency), and Parallel Benchmark (sustained latency over time via scenarios.py). Trigger on "benchmark", "feature benchmark", "scalability test", "parallel benchmark", "performance regression", "micro-benchmark", "TPS", "latency test", or when editing files in feature_benchmark/scenarios/, scalability/workload/workloads/, or parallel_benchmark/scenarios.py. Note: this is about benchmark measurement frameworks, not the parallel-workload stress-testing framework (which tests for panics under concurrency, not performance).

This skill should be used when the user wants to "commit", "prepare a commit", "create a PR", "push", "open a pull request", or mentions committing, pre-commit checks, or pull requests in the Materialize repository. Use this skill even if the user just says "ship it" or "ready to merge" without being specific. Note: for reviewing code, use mz-pr-review instead.

This skill should be used when the user wants to add, modify, or debug a limits test. Trigger when the user mentions "limits test", "Generator subclass", "many objects", "scaling test", or wants to stress-test Materialize with large numbers of objects (tables, views, sources, indexes, etc.). Also trigger when the user edits test/limits/mzcompose.py.

Extend the parallel-workload stress-testing framework, which runs random SQL actions concurrently to catch panics and unexpected errors (not performance measurement — see mz-benchmark for that). Trigger when the user mentions "parallel workload", "parallel-workload", "action.py" in the context of parallel workload, or wants to test for panics or unexpected query errors under concurrency. Use this skill even if the user just says "add this to parallel workload" or references a bug that panics under concurrent DDL/DML.

This skill should be used when the user wants to create, modify, or debug a platform check. Trigger when the user mentions "platform check", "platform-checks", "upgrade check", "restart check", or wants to write a Check class that tests feature survival across restarts/upgrades. Also trigger when the user edits files in misc/python/materialize/checks/all_checks/.

This skill should be used when the user asks to "review snouty's output", "run a satisfaction review", "judge the gallery", "how good is snouty's CLI output", or wants an LLM-driven subjective review of snouty's human-facing command output. Reviews each gallery story for user satisfaction (correctness, follow-up readiness, terminal rendering) and writes a per-story + overall report.

This skill should be used when the user asks to "release snouty", "cut a release", "bump the version", "create a release", or provides a version like "release snouty v0.2.0". Handles version validation, Cargo.toml bump, build, test, commit, and tagging.

Run project level linters, formatters, and static analysis tools. Then fix any issues raised.