index

Rust house style for repo-owned crates: edition 2024, naming, module layout, unsafe validation (Miri/loom/shuttle), mutation testing, fuzzing. Use when writing or reviewing Rust.

Use this skill to interactively debug Antithesis test runs using the multiverse debugger. Open a debugging-session URL, inspect container filesystems and runtime state, run shell commands, and extract evidence from inside the Antithesis environment. Supports both the simplified debugger (default) and the advanced notebook mode.

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?).

Cross-cutting facts and gotchas for any Antithesis work on the ix repo — credentials, harness structure, `setup_complete` protocol, assertion idioms, randomness rules, workload design, triage via `agent-browser`, signed report URLs, and Test Composer script placement. Loads whenever an Antithesis run, report, property/assertion, `snouty` invocation, or `antithesis_sdk::` call is in play. Complements the task-scoped `antithesis-{setup,workload, launch,triage,debug,query-logs,research,documentation}` skills.

Triage Antithesis test reports to understand what happened in a run: look up runs, check status, investigate failed properties (assertions), view metadata, download logs, inspect findings, and examine environmental details. Load after a run completes or when investigating a failure.

Autonomously drive a pull request to merged by spawning a background subagent (the fork) that watches CI fail-fast, fixes each failure on the PR branch, re-pushes, and merges when green, all without blocking the main session. Use when the user wants to watch and merge a PR, babysit it, fix CI and merge, get a PR in, or otherwise hand off a PR's CI-to-merge loop so they can keep working. The skill never blocks the main thread; it launches the watcher and returns immediately.

House README style: a committed SVG hero that adapts to dark/light via embedded prefers-color-scheme CSS, a hook-question intro with a 2-3 sentence pitch, install lines derived from the flake and crate metadata, and an optional git-log version history. Use when writing, reviewing, or generating any README in this repo, including the mirror generator's output.

Run a disciplined change → measure → decide experiment loop for any change, especially agent/prompt/harness tuning. Use when the user wants to test whether a change actually improves something, A/B two approaches, run rollouts, tune a prompt/skill/system-prompt, or decide keep-vs-revert with evidence rather than vibes. For agent or Claude-performance work, drive the real agent through the index TUI Python harness (tui.harness.Claude) so runs are live-visible on the dashboard, run several rollouts, compare against a baseline, and keep the change only if it measurably wins.

Verify the user actually understands a change before merging; build a short explainer (context, intuition, what was done) then quiz them interactively and grade the answers. Use when the user says quiz me, asks to check their understanding of a change, PR, or session, or wants a comprehension gate before merge.

Run a blind spot pass before starting unfamiliar work; surface the user's unknown unknowns (architecture-changing decisions, what good looks like, prior art, potholes, vocabulary) and end with a rewritten prompt. Use when the user says blind spot pass, unknown unknowns, find my unknowns, what am I missing, or starts work in a domain or codebase area they say they don't know.

Retrospect the current session at its end and file a GitHub issue for everything improvable. Use when the Stop retro gate asks for it, or when asked to run a session retro, retro the session, mine this session for friction, or file issues for what went wrong this session. Walks what happened (corrected mistakes, denied or guarded tool calls, workarounds, retries, missing structured interfaces, hook noise, stalled watches, anything repeated), routes each to the owning repo, dedupes against open issues, and files concise issues per the issues skill with AI attribution.

Predict and pre-draft the GitHub issues a person is about to file by mining their Claude Code conversation history, their previous issues, and their Slack threads, then file the strongest candidates with the inferred-future label. Use when asked to auto-issue, predict or infer future issues, pre-draft issues from history or Slack, or run an inferred-future sweep.

Run a multi-agent adversarial review over the current working-tree changes. Fans out one finder per dimension (correctness, security, performance, maintainability) over the git diff, adversarially verifies each finding to cut false positives, and returns ranked blockers vs warnings. Invoke after completing a substantive change, or when the Stop review gate asks for it. This reviews a finished local diff, not a remote PR (use /review for a PR).

Adopt a conversational, first-principles teaching tone when explaining any technical or STEM concept (math, physics, CS, EE, statistics, crypto, ML, networking, systems, algorithms, data structures, logic, or adjacent fields). Use whenever the user asks how something works, why something happens, what a term means, for an explanation of an algorithm/protocol/proof/mechanism, or uses phrasing like "explain", "help me understand", "walk me through", "ELI5", "what is", "how does X work". Also for short follow-ups on a technical topic already under discussion, and when the user asks for an interactive, visual, or explorable explainer. Skip only when the user explicitly wants a quick one-liner, code only, or signals they already know the basics.

Nix code style, general and mechanical: a design and idiom checklist for new code, plus the rules enforced by astlog and lint (no with/rec/mkForce, derivation hygiene, typed options, fetchers, licenses). Use when writing or reviewing Nix, or fixing a lint failure.

Rework a change as if the intended UX and architecture existed from day one, deleting compatibility cruft and accidental complexity. Use when the user asks for zero tech debt, no legacy path, a clean end-state refactor, or wants a patch reshaped around the intended final product surface instead of the historical path that produced it.

Running the repo lint (nix run .#lint) and that the pre-commit hook and CI share the entry point. Use before committing or when a lint check fails.

Repository directory layout and where each kind of file lives. Use when unsure where a file belongs or how the tree is organized.

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.

Interview-driven assistant for customers with Kubernetes-based production setups who are getting started with Antithesis. Helps the customer (and the Antithesis engagement team) figure out what their k8s setup contains, what to keep, drop, or stub for testing, and produces structured questions for ops plus an escalation packet when stuck.

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.

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: initialize the working directory, write Dockerfiles and docker-compose.yaml with build directives, and prepare to submit your first Antithesis test run.

File a bug report or feedback on the Antithesis skills by opening a pre-filled GitHub issue URL (skill name, skill version, agent, short summary). Load when the user wants to report a problem with, or give feedback on, any Antithesis skill. Does not auto-submit — presents the URL for the user to review.

Implement Antithesis workloads by turning the property catalog into SDK assertions and test commands, then refine coverage after triage.

The craft bar and defaults for every change: clear ownership, typed boundaries, checked defaults, root-cause fixes, no silent fallbacks.

Debugging running ix VMs: ix ls/shell, rendered units, journals, nix run nixpkgs#tool. Use when a VM service is failing or you need to inspect a guest.

Adding external dependencies: owners, fetchers, real hashes, generated catalogs, updateScripts, impure boundaries. Use when adding or updating a dependency, fetcher, or prebuilt binary.

Compress and deduplicate an instruction document (CLAUDE.md, AGENTS.md, a skill, a memory, a system prompt, any rules file) without losing behavior. Use when the user wants to tighten, distill, dedupe, generalize, shrink, clean up, or say something more concisely for any instruction or rules doc, or when one has grown sprawling and repetitive. The goal is the smallest text that still produces the same behavior, by generalizing specifics into the rule they illustrate, factoring shared conditions, merging duplicates to one source of truth, cutting completeness theater, and keeping every load-bearing handle (trigger, action, the non-obvious why, and the concrete command, path, or flag).

Pushing over HTTPS without reusing a read-only bot credential (gh auth setup-git). Use when git push fails with a permission or credential error.

ix VM image conventions: NixOS closures as OCI, networking, no at-rest encryption default, port topology, platform defaults. Use when adding or editing an image under images/.

House rules for code comments: explain why a line exists, cite external constraints, delete narration. Use when writing or reviewing inline comments.

What this repo is: pre-built OCI images for ix VMs plus composable NixOS modules.

Linux io_uring async I/O. Use when working with io_uring in C (liburing) or Rust (tokio-rs/io-uring). Covers setup, submission/completion queues, operations, and best practices.

Drive a physical iPhone/iPad (over USB cable or Wi-Fi) from the kernel iphone helper: screenshots, app launch, GPS, and real taps/typing via WebDriverAgent. Use when controlling a physical iOS device, automating an app, requesting a ride, or filling a form on a real iPhone, including cable-free over the network. Covers the one-time human gates, going wireless, and the WDA gotchas.

Filing and formatting GitHub issues: short bodies, repro steps, labels, multiline input. Use when creating or editing an issue.

NixOS module conventions: options vs config, auto-discovery, typed options, service families, port claims. Use when adding or editing a module under modules/.

Nix design philosophy: flake.nix as manifest, standard outputs, pure eval, data before commands, one source of truth, IFD boundaries. Use when designing flake structure or outputs.

Nix patterns to improve when touching nearby code: precise types, source filtering, getExe, mkPackageOption/mkEnableOption, follows. Use when writing or refactoring Nix.

Evaluate whether a prompt or instruction change actually works by spawning a fresh, clean-context Claude agent and checking if it produces the intended behavior. Use when the user edits a CLAUDE.md, a skill, an agent or subagent definition, a system prompt, a tool description, or a memory and wants to verify the change took effect, test that Claude now follows the new rule, A/B a prompt tweak, or confirm the output comes out in the form they wanted. Spawns separate sessions with neutral tasks and reports a pass rate.