Stress Test Skill

SkillAI & models

Generates comprehensive smoke and stress tests for infrastructure components (sandbox runtimes, container orchestration, firewall rules, etc.), prioritizing end-to-end realism that catches real setup issues across platforms. Activate when the user asks to "stress test", "smoke test", "test the sandbox", "verify isolation", or wants comprehensive infrastructure testing for a component.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Stress Test Skill skill

What this skill tells your AI

The instructions your AI receives, as published by alexandermattturner/agent-glovebox in .claude/skills/stress-test/SKILL.md and read by ahel’s review.

Generate smoke and stress tests for infrastructure components (sandbox runtimes, network isolation, container orchestration, entrypoint hardening, cross-platform setup). Prioritize end-to-end realism over unit-test purity — the goal is catching setup issues that surface on real platforms (Linux, macOS Colima/OrbStack, WSL2). Also fires on "make sure this works on macOS/Linux/WSL2".

General test-quality rules — test behavior not source text, non-vacuity, parametrize repeated patterns, no duplicate coverage, fixtures for repeated I/O — come from the writing-tests skill; follow it. This skill adds the infra-specific shape on top.

Principles

  1. Two tiers, always both. Static config validation (pytest, no Docker, runs everywhere) + live runtime checks (bash, needs Docker, proves isolation actually works).
  2. Assert the operation, not a keyword. assert "chown -R root:root" in content catches the real behavior; assert "chown" in content also matches a comment. Prefer the invariant/relationship (e.g. "proxy env vars reference the firewall's IP", read from both sides) over a hardcoded value that breaks on a legitimate config change.
  3. Guard empty-vs-empty. When comparing values that could be empty (namespace readlinks), assert non-empty first — an empty-vs-empty comparison silently passes.
  4. Bash checks are self-contained. Each check passes/fails/warns independently via a FAILURES counter, not set -e (which kills the whole script on one non-critical failure). Print PASS:/FAIL: prefixes for grep-ability.
  5. Test what breaks per platform. macOS: volume mounts (virtiofs/9p) and runtime install (Colima SSH). Linux: KVM availability and cgroup drivers. WSL2: nested virtualization.

Workflow

1. Identify the component and inventory existing tests

Determine what's under test (the sbx microVM launch and its kata runtime, the guest egress filter, entrypoint hardening, the host-side monitor and audit sink, setup scripts). Search tests/ and bin/check-*.bash for existing coverage and list it, so you extend rather than duplicate.

2. Walk ATLAS against the layer under test

The inventory says what is already tested. MITRE ATLAS says what an adversary would try. Walk one against the other before you write a test, so the suite covers the threat and not just the code you happened to read.

docs/threat-model-crosswalk.md already carries the mapping, the ATLAS release it was read from, and the traps that waste a session's time fetching it. Read it rather than re-deriving it.

  • Read only the techniques for the layer in front of you — the escape row for microVM work, the exfiltration rows for the egress filter. The matrix holds 178 techniques and almost none touch any one component.
  • Ask three questions per technique: is it reachable here, does anything detect it, does anything stop it.
  • A technique nothing detects and nothing stops is either a test you write now or a line in the report saying why it does not apply here. Never leave it unmentioned.
  • Break ties on the maturity field. Realized means someone has done it in the wild; Feasible means nobody has yet.

Worked example. Stress-testing the guest egress filter, the walk reaches AML.T0086 Exfiltration via AI Agent Tool Invocation, whose crosswalk verdict is Partial because the tier check reads the request method and never the body. That becomes a live check that pushes a large POST body at a ro host and asserts the refusal. An inventory of the code alone does not suggest that test, because the code has no body-handling branch to notice.

3. Static config tests (pytest)

Parse config files directly to catch misconfigurations without Docker: the sbx launch config → resource limits, env vars, runtime selection; domain allowlist → access modes, no wildcards, no raw IPs; entrypoint and egress-filter scripts → hardening steps present; setup.bash → platform-detection logic. Parametrize properties that repeat across several config entries.

4. Live runtime tests (bash)

Exercise the actual runtime to prove isolation end-to-end (needs Docker):

  • Container starts with the sandbox runtime
  • Process isolation: /proc shows only container processes
  • Device isolation: no host devices visible
  • Network isolation: internal network blocks egress
  • Filesystem: read-only enforcement holds
  • Volume mounts: bind mounts work (critical on macOS)
  • Capabilities: CapEff=0 under --cap-drop=ALL

5. CI

Add the checks to an existing workflow — do not write a new one. The live checks belong as jobs or matrix legs in .github/workflows/sbx-live-checks.yaml, which already holds real KVM; static tests join the existing pytest legs. The pr-creation skill owns the rule and the narrow cases that justify a new file, and every new pull_request-triggered workflow is a permanent cost on every push to every open PR. Keep paths filters consistent across push and pull_request; always set timeout-minutes.

6. Critique-fix loop

Re-check each Principle against what you actually wrote (not what you intended), plus: missing coverage (an important invariant or platform-specific failure mode untested) and fragile bash (A && B || C instead of if-then-else, missing cleanup for Docker networks/temp dirs). Fix each, then start a fresh pass — fixes introduce their own bugs. Stop when a full pass finds nothing, under at most three passes (.claude/rules/development-workflow.md § Self-critique), then list what remains in the report. Skip for a trivial one-test addition — say so explicitly.

Example: "Stress test the guest egress filter"

  1. Search tests/ and bin/check-*.bash — the allowlist's shape is already covered; the ro/rw decision at runtime is not.
  2. Walk the crosswalk's exfiltration rows. AML.T0086 is Partial on request content, so an unmetered body is the untested case.
  3. Add a pytest file with parametrized allowlist checks (access modes, no wildcards, no raw IPs).
  4. Add a bin/check-*-smoke.bash with live checks: a write to a ro host refuses, a large POST body is the case step 2 found.
  5. Add both as jobs in sbx-live-checks.yaml; write no new workflow.
  6. Run pytest locally; self-critique removes 3 duplicates of the allowlist tests and parametrizes 8 similar tests into 2.

Signals

GitHub stars
63
Forks
11
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
stress-test-alexandermattturner
Source
github.com/alexandermattturner/agent-glovebox
Stress Test Skill by alexandermattturner: Skill · ahel