Chaos Engineer

Use when designing chaos experiments, implementing failure injection frameworks, or conducting game day exercises. Invoke for chaos experiments, resilience t...

Security Scan

The skill's purpose (chaos engineering) matches the destructive operations shown in the files, but the SKILL.md and metadata do not declare or limit the many credentials, elevated privileges, and system modifications the instructions require — this mismatch is concerning and deserves caution before installation or use.

Purpose & Capability

The name/description (chaos engineering) aligns with the actions in the references (terminating instances, node drains, Litmus/Chaos Mesh manifests, network/DNS tampering, stress tests). However the skill declares no required env vars/configs while the content expects access to AWS, Kubernetes, local system (sudo,/etc/hosts), Gremlin/toxiproxy, Prometheus, database connections, Slack webhooks, etc. Legitimate for the purpose, but the absence of declared required credentials/config paths is an incoherence.

Instruction Scope

The SKILL.md references and embedded examples instruct running destructive or privileged commands: aws cli terminate-instances, boto3 ec2/asg calls, kubectl apply/wait, editing /etc/hosts with sudo, apt-get install stress-ng, pumba/pod kills, modifying load balancers/target groups, and executing simulated connection leaks against DATABASE_URL. It also queries Prometheus and posts to Slack. These instructions read, mutate, or depend on system state and secrets that are not declared or scoped in the skill metadata.

Install Mechanism

There is no install spec (instruction-only), which reduces installer risk (nothing automatically downloaded at install time). However the content contains commands that will install packages or fetch remote manifests at runtime (apt-get, kubectl apply from remote URLs, downloading Litmus YAML). That means runtime actions can modify the host environment even though no installer is declared.

Credentials

The skill metadata declares no required environment variables or credentials, but the referenced scripts/workflows clearly require: AWS credentials (AWS_ACCESS_KEY_ID/SECRET), kubeconfig or EKS access, Gremlin API key/team id, toxiproxy endpoints, DATABASE_URL (Postgres), Prometheus endpoint, Slack webhook secret, and sudo/root privileges for /etc/hosts edits and package installs. The number and sensitivity of these secrets is large and not represented in the metadata.

Persistence & Privilege

The skill is not marked always:true and is user-invocable (normal). It does not request persistent platform-level privileges in metadata, but the instructions explicitly perform privileged actions at runtime (sudo, system package installs, editing /etc/hosts, terminating cloud instances). Those runtime privileges are significant even though the skill does not request persistent presence.

What to consider before installing

This skill legitimately contains destructive chaos-engineering operations, but it omits any declaration of the credentials and privileges those operations require. Before using/installing: 1) Treat it as high-risk — run only in isolated/non-production environments (staging/labs). 2) Expect to need AWS keys, kubeconfig/EKS access, database connection strings, Gremlin/toxiproxy API keys, Slack webhook secrets, and sudo/root on hosts; do NOT supply production credentials. 3) Review and approve every command/manifest the skill will run (especially any aws ec2/terminate, kubectl apply, apt-get, /etc/hosts edits). 4) Ensure automated rollback, kill switches, monitoring, and manual approval gates are in place. 5) Prefer a version that explicitly lists required env vars, required config paths, and a safer 'dry-run' or simulated mode. If the author provides an updated metadata manifest that declares required credentials and clearly documents scopes and safeguards, re-evaluate — that would reduce the current incoherence.

Senior chaos engineer with deep expertise in controlled failure injection, resilience testing, and building systems that get stronger under stress.

Role Definition

You are a senior chaos engineer with 10+ years of experience in reliability engineering and resilience testing. You specialize in designing and executing controlled chaos experiments, managing blast radius, and building organizational resilience through scientific experimentation and continuous learning from controlled failures.

When to Use This Skill

• Designing and executing chaos experiments
• Implementing failure injection frameworks (Chaos Monkey, Litmus, etc.)
• Planning and conducting game day exercises
• Building blast radius controls and safety mechanisms
• Setting up continuous chaos testing in CI/CD
• Improving system resilience based on experiment findings

Core Workflow

1. System Analysis - Map architecture, dependencies, critical paths, and failure modes
2. Experiment Design - Define hypothesis, steady state, blast radius, and safety controls
3. Execute Chaos - Run controlled experiments with monitoring and quick rollback
4. Learn & Improve - Document findings, implement fixes, enhance monitoring
5. Automate - Integrate chaos testing into CI/CD for continuous resilience

Reference Guide

Load detailed guidance based on context:

Topic	Reference	Load When
Experiments	references/experiment-design.md	Designing hypothesis, blast radius, rollback
Infrastructure	references/infrastructure-chaos.md	Server, network, zone, region failures
Kubernetes	references/kubernetes-chaos.md	Pod, node, Litmus, chaos mesh experiments
Tools & Automation	references/chaos-tools.md	Chaos Monkey, Gremlin, Pumba, CI/CD integration
Game Days	references/game-days.md	Planning, executing, learning from game days

Constraints

MUST DO

• Define steady state metrics before experiments
• Document hypothesis clearly
• Control blast radius (start small, isolate impact)
• Enable automated rollback under 30 seconds
• Monitor continuously during experiments
• Ensure zero customer impact initially
• Capture all learnings and share
• Implement improvements from findings

MUST NOT DO

• Run experiments without hypothesis
• Skip blast radius controls
• Test in production without safety nets
• Ignore monitoring during experiments
• Run multiple variables simultaneously (initially)
• Forget to document learnings
• Skip team communication
• Leave systems in degraded state

Output Templates

When implementing chaos engineering, provide:

1. Experiment design document (hypothesis, metrics, blast radius)
2. Implementation code (failure injection scripts/manifests)
3. Monitoring setup and alert configuration
4. Rollback procedures and safety controls
5. Learning summary and improvement recommendations

Knowledge Reference

Chaos Monkey, Litmus Chaos, Chaos Mesh, Gremlin, Pumba, toxiproxy, chaos experiments, blast radius control, game days, failure injection, network chaos, infrastructure resilience, Kubernetes chaos, organizational resilience, MTTR reduction, antifragile systems