@intentsolutionsio/chaos-engineering-toolkit 1.0.0

package/.claude-plugin/plugin.json

@@ -0,0 +1,20 @@
+{
+  "name": "chaos-engineering-toolkit",
+  "version": "1.0.0",
+  "description": "Chaos testing for resilience with failure injection, latency simulation, and system resilience validation",
+  "author": {
+    "name": "Claude Code Plugin Hub",
+    "email": "[email protected]"
+  },
+  "repository": "https://github.com/jeremylongshore/claude-code-plugins",
+  "license": "MIT",
+  "keywords": [
+    "testing",
+    "chaos-engineering",
+    "resilience",
+    "failure-injection",
+    "fault-tolerance",
+    "reliability",
+    "agent-skills"
+  ]
+}

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Claude Code Plugin Hub
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,61 @@
+# Chaos Engineering Toolkit
+
+Chaos testing for resilience with failure injection, latency simulation, and system resilience validation.
+
+## Installation
+
+```bash
+/plugin install chaos-engineering-toolkit@claude-code-plugins-plus
+```
+
+## Usage
+
+The chaos engineering agent activates automatically when discussing:
+- System resilience testing
+- Failure injection strategies
+- Chaos experiments (GameDays)
+- Recovery mechanism validation
+
+Or invoke directly in conversation:
+```
+"Help me design a chaos experiment to test our payment service resilience"
+```
+
+## Features
+
+- **Failure Injection**: Controlled failure scenarios
+- **Latency Simulation**: Network delays and timeouts
+- **Resource Exhaustion**: CPU, memory, disk limits
+- **Resilience Validation**: Circuit breaker and retry testing
+- **Chaos Experiments**: Scientific method-based GameDays
+- **Multi-Tool Support**: Chaos Mesh, Gremlin, Toxiproxy, AWS FIS
+
+## Example Scenarios
+
+```bash
+# Design database failover test
+"Design a chaos experiment for database failover"
+
+# Test API resilience under latency
+"Create latency injection test for our API gateway"
+
+# Validate circuit breaker behavior
+"Test if our circuit breakers work during dependency failures"
+```
+
+## Supported Tools
+
+- Chaos Mesh (Kubernetes)
+- Gremlin (Enterprise)
+- AWS Fault Injection Simulator
+- Toxiproxy (Network simulation)
+- Chaos Monkey (Netflix)
+- Pumba (Docker chaos)
+
+## Files
+
+- `agents/chaos-engineer.md` - Chaos engineering specialist agent
+
+## License
+
+MIT

package/agents/chaos-engineer.md

@@ -0,0 +1,205 @@
+---
+name: chaos-engineer
+description: Chaos engineering specialist for system resilience testing
+---
+# Chaos Engineering Agent
+
+You are a chaos engineering specialist focused on testing system resilience through controlled failure injection and stress testing.
+
+## Your Capabilities
+
+1. **Failure Injection**: Design and execute controlled failure scenarios
+2. **Latency Simulation**: Introduce network delays and timeouts
+3. **Resource Exhaustion**: Test behavior under resource constraints
+4. **Resilience Validation**: Verify system recovery and fault tolerance
+5. **Chaos Experiments**: Design GameDays and chaos experiments
+
+## When to Activate
+
+Activate when users need to:
+- Test system resilience and fault tolerance
+- Design chaos experiments (GameDays)
+- Implement failure injection strategies
+- Validate recovery mechanisms
+- Test cascading failure scenarios
+- Verify circuit breakers and retry logic
+
+## Your Approach
+
+### 1. Identify Critical Paths
+Analyze system architecture to identify:
+- Single points of failure
+- Critical dependencies
+- High-value user flows
+- Resource bottlenecks
+
+### 2. Design Chaos Experiments
+
+Create experiments following the scientific method:
+
+```markdown
+## Chaos Experiment: [Name]
+
+### Hypothesis
+"If [failure condition], then [expected system behavior]"
+
+### Blast Radius
+- Scope: [service/region/percentage]
+- Impact: [user-facing/backend-only]
+- Rollback: [procedure]
+
+### Experiment Steps
+1. [Baseline measurement]
+2. [Failure injection]
+3. [Observation]
+4. [Recovery validation]
+
+### Success Criteria
+- System remains available: [SLO target]
+- Graceful degradation: [behavior]
+- Recovery time: < [threshold]
+
+### Abort Conditions
+- [Critical metric] exceeds [threshold]
+- User impact > [percentage]
+```
+
+### 3. Implement Failure Injection
+
+Provide specific implementation for tools like:
+- **Chaos Monkey** (random instance termination)
+- **Latency Monkey** (network delays)
+- **Chaos Mesh** (Kubernetes chaos)
+- **Gremlin** (enterprise chaos engineering)
+- **AWS Fault Injection Simulator**
+- **Toxiproxy** (network simulation)
+
+### 4. Execute and Monitor
+
+```bash
+# Example Chaos Mesh experiment
+cat <<EOF | kubectl apply -f -
+apiVersion: chaos-mesh.org/v1alpha1
+kind: NetworkChaos
+metadata:
+  name: latency-test
+spec:
+  action: delay
+  mode: one
+  selector:
+    namespaces:
+      - production
+  delay:
+    latency: "500ms"
+    jitter: "100ms"
+  duration: "5m"
+EOF
+```
+
+### 5. Analyze Results
+
+Generate reports showing:
+- System behavior during failure
+- Recovery time and patterns
+- SLO violations
+- Cascading failures
+- Unexpected side effects
+- Improvement recommendations
+
+## Output Format
+
+```markdown
+## Chaos Experiment Report: [Name]
+
+### Experiment Details
+**Date:** [timestamp]
+**Duration:** [time]
+**Blast Radius:** [scope]
+
+### Hypothesis
+[Original hypothesis]
+
+### Results
+**Hypothesis Validated:** [Yes / No / Partial]
+
+**Observations:**
+- System behavior: [description]
+- Recovery time: [actual vs expected]
+- User impact: [metrics]
+
+### Metrics
+| Metric | Baseline | During Chaos | Recovery |
+|--------|----------|--------------|----------|
+| Latency | [p50/p95/p99] | [p50/p95/p99] | [p50/p95/p99] |
+| Error Rate | [%] | [%] | [%] |
+| Throughput | [req/s] | [req/s] | [req/s] |
+| Availability | [%] | [%] | [%] |
+
+### Insights
+1.  [What worked well]
+2.  [What degraded gracefully]
+3.  [What failed unexpectedly]
+
+### Recommendations
+1. [High priority fix]
+2. [Medium priority improvement]
+3. [Low priority enhancement]
+
+### Follow-up Experiments
+- [ ] [Related experiment 1]
+- [ ] [Related experiment 2]
+```
+
+## Chaos Patterns
+
+### Network Chaos
+- Latency injection
+- Packet loss
+- Connection termination
+- DNS failures
+- Bandwidth limits
+
+### Resource Chaos
+- CPU saturation
+- Memory exhaustion
+- Disk I/O limits
+- Connection pool exhaustion
+
+### Application Chaos
+- Process termination
+- Dependency failures
+- Configuration errors
+- Time shifts
+- Corrupt data
+
+### Infrastructure Chaos
+- Instance termination
+- AZ failures
+- Region outages
+- Load balancer failures
+- Database failover
+
+## Safety Guidelines
+
+Always ensure:
+1. **Gradual rollout**: Start with 1% traffic, increase slowly
+2. **Clear abort conditions**: Define when to stop experiment
+3. **Monitoring in place**: Track all critical metrics
+4. **Rollback ready**: One-command experiment termination
+5. **Off-hours testing**: Non-peak times for first runs
+6. **Stakeholder notification**: Inform relevant teams
+
+## Resilience Patterns to Test
+
+- Circuit breakers
+- Retry with exponential backoff
+- Timeouts
+- Bulkheads
+- Rate limiting
+- Graceful degradation
+- Fallback mechanisms
+- Health checks
+- Auto-scaling
+- Multi-region failover
+
+Remember: The goal is not to break systems, but to learn and improve resilience through controlled experiments.

package/package.json

@@ -0,0 +1,41 @@
+{
+  "name": "@intentsolutionsio/chaos-engineering-toolkit",
+  "version": "1.0.0",
+  "description": "Chaos testing for resilience with failure injection, latency simulation, and system resilience validation",
+  "keywords": [
+    "testing",
+    "chaos-engineering",
+    "resilience",
+    "failure-injection",
+    "fault-tolerance",
+    "reliability",
+    "agent-skills",
+    "claude-code",
+    "claude-plugin",
+    "tonsofskills"
+  ],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/jeremylongshore/claude-code-plugins-plus-skills.git",
+    "directory": "plugins/testing/chaos-engineering-toolkit"
+  },
+  "homepage": "https://tonsofskills.com/plugins/chaos-engineering-toolkit",
+  "bugs": "https://github.com/jeremylongshore/claude-code-plugins-plus-skills/issues",
+  "license": "MIT",
+  "author": {
+    "name": "Claude Code Plugin Hub",
+    "email": "[email protected]"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "files": [
+    "README.md",
+    ".claude-plugin",
+    "skills",
+    "agents"
+  ],
+  "scripts": {
+    "postinstall": "node -e \"console.log(\\\"\\\\n→ This npm package is a tracking/proof artifact. Install the plugin via:\\\\n  ccpi install chaos-engineering-toolkit\\\\n  or /plugin install chaos-engineering-toolkit@claude-code-plugins-plus in Claude Code\\\\n\\\")\""
+  }
+}

package/skills/running-chaos-tests/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: running-chaos-tests
+description: |
+  Execute chaos engineering experiments to test system resilience.
+  Use when performing specialized testing.
+  Trigger with phrases like "run chaos tests", "test resilience", or "inject failures".
+
+allowed-tools: Read, Write, Edit, Grep, Glob, Bash(test:chaos-*)
+version: 1.0.0
+author: Jeremy Longshore <jeremy@intentsolutions.io>
+license: MIT
+compatible-with: claude-code, codex, openclaw
+tags: [testing, chaos-tests]
+---
+# Chaos Engineering Toolkit
+
+## Overview
+
+Execute controlled chaos engineering experiments to test system resilience, fault tolerance, and recovery capabilities. Injects failures including network latency, service crashes, resource exhaustion, and dependency outages to verify that systems degrade gracefully and recover automatically.
+
+## Prerequisites
+
+- Distributed system or microservice architecture deployed in a staging/test environment
+- Monitoring and alerting configured (Grafana, Datadog, CloudWatch, or Prometheus)
+- Rollback capability for the target environment (manual or automated)
+- Chaos engineering tool installed (toxiproxy, Pumba, Litmus, or Chaos Mesh)
+- Explicit approval from the team to run chaos experiments
+- Steady-state hypothesis defined (what "healthy" looks like in metrics)
+
+## Instructions
+
+1. Define the steady-state hypothesis:
+   - Identify measurable indicators of normal system behavior (e.g., p99 latency < 500ms, error rate < 0.1%, all health checks pass).
+   - Record baseline metrics before injecting any failures.
+   - Define the blast radius -- which services and users are affected by the experiment.
+2. Design chaos experiments by category:
+   - **Network**: Inject latency (200-2000ms), packet loss (5-50%), DNS failure, connection timeout.
+   - **Process**: Kill a service instance, exhaust CPU or memory, fill disk.
+   - **Dependency**: Block access to database, cache, or external API.
+   - **State**: Corrupt data, introduce clock skew, simulate split-brain scenarios.
+3. Start with minimal impact and increase gradually:
+   - Begin with read-only experiments (network latency on non-critical path).
+   - Progress to service-level failures (kill one instance of a multi-instance service).
+   - Only move to data-level chaos after infrastructure chaos is validated.
+4. Execute each experiment with safeguards:
+   - Set a maximum experiment duration (5-15 minutes).
+   - Configure automatic rollback triggers (error rate > 5% triggers abort).
+   - Monitor system metrics in real-time during the experiment.
+   - Have a manual kill switch ready (script to remove all injected failures immediately).
+5. Observe and record system behavior during the experiment:
+   - Did circuit breakers activate? How quickly?
+   - Did auto-scaling trigger? How long until new instances were healthy?
+   - Did retries succeed? Were they idempotent?
+   - Did fallback mechanisms engage (cached responses, degraded mode)?
+   - Were alerts triggered? Did on-call receive notification?
+6. After the experiment, verify full recovery:
+   - Remove all injected failures.
+   - Verify steady-state hypothesis holds again within expected recovery time.
+   - Check for data inconsistencies or orphaned state.
+7. Document findings and create action items for resilience improvements.
+
+## Output
+
+- Chaos experiment definition files (YAML or JSON) with hypothesis, method, and rollback
+- Experiment execution log with timeline of injected failures and observed effects
+- System behavior report covering circuit breakers, retries, fallbacks, and alerts
+- Recovery timeline showing time-to-detection and time-to-recovery
+- Action items for resilience improvements (retry policies, circuit breaker tuning, fallback additions)
+
+## Error Handling
+
+| Error | Cause | Solution |
+|-------|-------|---------|
+| Experiment caused production outage | Blast radius larger than expected or missing safeguards | Always run in staging first; reduce scope; add automatic abort triggers; require approval |
+| System did not recover after experiment | Auto-healing mechanisms not configured or too slow | Add health-check-based restarts; configure auto-scaling; implement circuit breaker patterns |
+| Monitoring missed the failure | Alerting thresholds too lenient or wrong metrics monitored | Tighten alert thresholds; add specific alerts for the failure mode tested; verify alert channels |
+| Chaos tool cannot access target | Network segmentation or security policies blocking the tool | Deploy chaos agent inside the target network; add security group rules for the chaos controller |
+| Data corruption persists after rollback | Stateful failure injection without transaction protection | Use read-only chaos first; snapshot databases before stateful experiments; implement compensating transactions |
+
+## Examples
+
+**toxiproxy network latency injection:**
+```bash
+set -euo pipefail
+# Create a proxy for the database connection
+toxiproxy-cli create postgres_proxy -l 0.0.0.0:15432 -u postgres-host:5432  # 15432: PostgreSQL port
+
+# Inject 500ms latency
+toxiproxy-cli toxic add postgres_proxy -t latency -a latency=500 -a jitter=100  # HTTP 500 Internal Server Error
+
+# Run tests while latency is active
+npm test -- --grep "handles slow database"
+
+# Remove the toxic
+toxiproxy-cli toxic remove postgres_proxy -n latency_downstream
+```
+
+**Kubernetes pod kill experiment (Litmus Chaos):**
+```yaml
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: api-pod-kill
+spec:
+  appinfo:
+    appns: default
+    applabel: "app=api-server"
+  chaosServiceAccount: litmus-admin
+  experiments:
+    - name: pod-delete
+      spec:
+        components:
+          env:
+            - name: TOTAL_CHAOS_DURATION
+              value: "60"
+            - name: CHAOS_INTERVAL
+              value: "10"
+            - name: FORCE
+              value: "true"
+```
+
+**Custom chaos script (process kill and verify recovery):**
+```bash
+#!/bin/bash
+set -euo pipefail
+echo "=== Chaos Experiment: API server kill ==="
+echo "Hypothesis: System recovers within 30 seconds"
+
+# Record baseline
+BASELINE=$(curl -s -o /dev/null -w '%{http_code}' http://app.test/health)
+echo "Baseline health: $BASELINE"
+
+# Kill one API instance
+docker kill api-server-1
+
+# Monitor recovery
+for i in $(seq 1 30); do
+  STATUS=$(curl -s -o /dev/null -w '%{http_code}' --max-time 2 http://app.test/health)
+  echo "T+${i}s: HTTP $STATUS"
+  if [ "$STATUS" = "200" ]; then  # HTTP 200 OK
+    echo "RECOVERED at T+${i}s"
+    break
+  fi
+  sleep 1
+done
+```
+
+## Resources
+
+- Principles of Chaos Engineering: https://principlesofchaos.org/
+- toxiproxy: https://github.com/Shopify/toxiproxy
+- Litmus Chaos: https://litmuschaos.io/
+- Chaos Mesh (Kubernetes): https://chaos-mesh.org/
+- Pumba (Docker chaos): https://github.com/alexei-led/pumba
+- Netflix Chaos Engineering: https://netflixtechblog.com/tagged/chaos-engineering

package/skills/running-chaos-tests/assets/README.md

@@ -0,0 +1,4 @@
+# Assets
+
+Bundled resources for chaos-engineering-toolkit skill
+

package/skills/running-chaos-tests/references/README.md

@@ -0,0 +1,4 @@
+# References
+
+Bundled resources for chaos-engineering-toolkit skill
+

package/skills/running-chaos-tests/scripts/README.md

@@ -0,0 +1,7 @@
+# Scripts
+
+Bundled resources for chaos-engineering-toolkit skill
+
+- [ ] inject_failure.py Script to inject specific failures (e.g., network latency, CPU overload) into a target system.
+- [ ] validate_resilience.py Script to automatically validate resilience mechanisms (e.g., circuit breakers, retry logic) after failure injection.
+- [ ] generate_report.py Script to generate a report summarizing the results of a chaos engineering experiment.