stress-test

Generates smoke and stress tests for sandbox runtimes, firewalls, and infrastructure components.

64|11|Updated May 24, 2026
One-click install
npx skills add https://github.com/AlexanderMattTurner/agent-glovebox --skill stress-test-alexandermattturner
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stress-test
Source: https://github.com/AlexanderMattTurner/agent-glovebox/tree/main/.claude/skills/stress-test
Command: npx skills add https://github.com/AlexanderMattTurner/agent-glovebox --skill stress-test-alexandermattturner

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Infrastructure components like sandbox runtimes, egress filters, and container orchestration often pass unit tests yet fail on real platforms due to misconfiguration, missing isolation, or platform-specific quirks. This Skill generates end-to-end smoke and stress tests that catch real setup issues across Linux, macOS, and WSL2 before they reach production. ## Core Features & Use Cases - Two-tier test generation: Produces static config validation tests (pytest, no Docker required) plus live runtime checks (bash scripts that prove isolation actually works with Docker). - Threat-informed coverage: Walks MITRE ATLAS techniques against the component under test so the suite covers adversarial scenarios, not just code paths already visible. - Platform-specific failure modes: Targets what actually breaks per platform — virtiofs volume mounts on macOS, KVM availability on Linux, nested virtualization on WSL2. - Use Case: When asked to "stress test the guest egress filter", the Skill inventories existing tests, walks the ATLAS exfiltration rows to find untested cases (like an unmetered POST body to a read-only host), then adds parametrized pytest checks and a live bash smoke script wired into the existing CI workflow. ## Quick Start Ask the AI to stress test the sandbox runtime and verify network isolation works on macOS and Linux.

Frequently Asked Questions about stress-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I stress test a sandbox runtime or container isolation?

Generate two tiers of tests: static pytest checks that parse launch configs for resource limits and runtime selection, plus live bash checks that start the container and verify process, device, network, and filesystem isolation actually hold. The Skill structures both tiers and wires them into CI.

How to test network isolation and egress firewall rules?

Write live bash checks that attempt egress through the internal network and assert it is blocked, plus pytest checks validating the domain allowlist has correct access modes, no wildcards, and no raw IPs. Walking MITRE ATLAS exfiltration techniques reveals untested cases like unmetered request bodies.

Does this testing approach work on macOS and WSL2?

Yes, the generated tests target platform-specific failure modes: virtiofs/9p volume mounts and Colima runtime install on macOS, KVM availability and cgroup drivers on Linux, and nested virtualization on WSL2. Static pytest tests run everywhere without Docker.

Why do bash test scripts avoid set -e for infrastructure checks?

Using set -e kills the entire script on the first non-critical failure, hiding later results. Each check instead passes, fails, or warns independently via a FAILURES counter with PASS:/FAIL: prefixes, so one failure does not mask the rest of the isolation report.

Should I create a new CI workflow for live sandbox checks?

No. Add the live checks as jobs or matrix legs in the existing sbx-live-checks.yaml workflow, which already provides real KVM. Every new pull_request-triggered workflow is a permanent cost on every push, so keep paths filters consistent and always set timeout-minutes.