chaos-engineer

Name: chaos-engineer
Author: Jeffallan

11kstars971forks

How to install chaos-engineer?

jeffallan/claude-skills/chaos-engineer

$npx -y skills add Jeffallan/claude-skills --skill chaos-engineer

Installs into the current project.

Summary

Designs chaos experiments, creates failure injection frameworks, and facilitates game day exercises for distributed systems — producing runbooks, experiment manifests, rollback procedures, and post-mortem templates. Use when designing chaos experiments, implementing failure injec

Files · 1

View on GitHub

SKILL.md

1	# Chaos Engineer
2
3	## When to Use This Skill
4
5	- Designing and executing chaos experiments
6	- Implementing failure injection frameworks (Chaos Monkey, Litmus, etc.)
7	- Planning and conducting game day exercises
8	- Building blast radius controls and safety mechanisms
9	- Setting up continuous chaos testing in CI/CD
10	- Improving system resilience based on experiment findings
11
12	## Core Workflow
13
14	1. System Analysis - Map architecture, dependencies, critical paths, and failure modes
15	2. Experiment Design - Define hypothesis, steady state, blast radius, and safety controls
16	3. Execute Chaos - Run controlled experiments with monitoring and quick rollback
17	4. Learn & Improve - Document findings, implement fixes, enhance monitoring
18	5. Automate - Integrate chaos testing into CI/CD for continuous resilience
19
20	## Reference Guide
21
22	Load detailed guidance based on context:
23
24	\| Topic \| Reference \| Load When \|
25	\|-------\|-----------\|-----------\|
26	\| Experiments \| `references/experiment-design.md` \| Designing hypothesis, blast radius, rollback \|
27	\| Infrastructure \| `references/infrastructure-chaos.md` \| Server, network, zone, region failures \|
28	\| Kubernetes \| `references/kubernetes-chaos.md` \| Pod, node, Litmus, chaos mesh experiments \|
29	\| Tools & Automation \| `references/chaos-tools.md` \| Chaos Monkey, Gremlin, Pumba, CI/CD integration \|
30	\| Game Days \| `references/game-days.md` \| Planning, executing, learning from game days \|
31
32	## Safety Checklist
33
34	Non-obvious constraints that must be enforced on every experiment:
35
36	- Steady state first — define and verify baseline metrics before injecting any failure
37	- Blast radius cap — start with the smallest possible impact scope; expand only after validation
38	- Automated rollback ≤ 30 seconds — abort path must be scripted and tested before the experiment begins
39	- Single variable — change only one failure condition at a time until behaviour is well understood
40	- No production without safety nets — customer-facing environments require circuit breakers, feature flags, or canary isolation
41	- Close the loop — every experiment must produce a written learning summary and at least one tracked improvement
42
43	## Output Templates
44
45	When implementing chaos engineering, provide:
46	1. Experiment design document (hypothesis, metrics, blast radius)
47	2. Implementation code (failure injection scripts/manifests)
48	3. Monitoring setup and alert configuration
49	4. Rollback procedures and safety controls
50	5. Learning summary and improvement recommendations
51
52	## Concrete Example: Pod Failure Experiment (Litmus Chaos)
53
54	The following shows a complete experiment — from hypothesis to rollback — using Litmus Chaos on Kubernetes.
55
56	### Step 1 — Define steady state and apply the experiment
57
58	```bash
59	# Verify baseline: p99 latency < 200ms, error rate < 0.1%
60	kubectl get deploy my-service -n production
61	kubectl top pods -n production -l app=my-service
62	```
63
64	### Step 2 — Create and apply a Litmus ChaosEngine manifest
65
66	```yaml
67	# chaos-pod-delete.yaml
68	apiVersion: litmuschaos.io/v1alpha1
69	kind: ChaosEngine
70	metadata:
71	name: my-service-pod-delete
72	namespace: production
73	spec:
74	appinfo:
75	appns: production
76	applabel: "app=my-service"
77	appkind: deployment
78	# Limit blast radius: only 1 replica at a time
79	engineState: active
80	chaosServiceAccount: litmus-admin
81	experiments:
82	- name: pod-delete
83	spec:
84	components:
85	env:
86	- name: TOTAL_CHAOS_DURATION
87	value: "60" # seconds
88	- name: CHAOS_INTERVAL
89	value: "20" # delete one pod every 20s
90	- name: FORCE
91	value: "false"
92	- name: PODS_AFFECTED_PERC
93	value: "33" # max 33% of replicas affected
94	```
95
96	```bash
97	# Apply the experiment
98	kubectl apply -f chaos-pod-delete.yaml
99
100	# Watch experiment status
101	kubectl describe chaosengine my-service-pod-delete -n production
102	kubectl get chaosresult my-service-pod-delete-pod-delete -n production -w
103	```
104
105	### Step 3 — Monitor during the experiment
106
107	```bash
108	# Tail application logs for errors
109	k

People who liked this also viewed

6 picks

Type

chaos-engineer

11kstars971forks

View on GitHub

How to install chaos-engineer?

jeffallan/claude-skills/chaos-engineer

$npx -y skills add Jeffallan/claude-skills --skill chaos-engineer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Chaos Engineer
2
3	## When to Use This Skill
4
5	- Designing and executing chaos experiments
6	- Implementing failure injection frameworks (Chaos Monkey, Litmus, etc.)
7	- Planning and conducting game day exercises
8	- Building blast radius controls and safety mechanisms
9	- Setting up continuous chaos testing in CI/CD
10	- Improving system resilience based on experiment findings
11
12	## Core Workflow
13
14	1. System Analysis - Map architecture, dependencies, critical paths, and failure modes
15	2. Experiment Design - Define hypothesis, steady state, blast radius, and safety controls
16	3. Execute Chaos - Run controlled experiments with monitoring and quick rollback
17	4. Learn & Improve - Document findings, implement fixes, enhance monitoring
18	5. Automate - Integrate chaos testing into CI/CD for continuous resilience
19
20	## Reference Guide
21
22	Load detailed guidance based on context:
23
24	\| Topic \| Reference \| Load When \|
25	\|-------\|-----------\|-----------\|
26	\| Experiments \| `references/experiment-design.md` \| Designing hypothesis, blast radius, rollback \|
27	\| Infrastructure \| `references/infrastructure-chaos.md` \| Server, network, zone, region failures \|
28	\| Kubernetes \| `references/kubernetes-chaos.md` \| Pod, node, Litmus, chaos mesh experiments \|
29	\| Tools & Automation \| `references/chaos-tools.md` \| Chaos Monkey, Gremlin, Pumba, CI/CD integration \|
30	\| Game Days \| `references/game-days.md` \| Planning, executing, learning from game days \|
31
32	## Safety Checklist
33
34	Non-obvious constraints that must be enforced on every experiment:
35
36	- Steady state first — define and verify baseline metrics before injecting any failure
37	- Blast radius cap — start with the smallest possible impact scope; expand only after validation
38	- Automated rollback ≤ 30 seconds — abort path must be scripted and tested before the experiment begins
39	- Single variable — change only one failure condition at a time until behaviour is well understood
40	- No production without safety nets — customer-facing environments require circuit breakers, feature flags, or canary isolation
41	- Close the loop — every experiment must produce a written learning summary and at least one tracked improvement
42
43	## Output Templates
44
45	When implementing chaos engineering, provide:
46	1. Experiment design document (hypothesis, metrics, blast radius)
47	2. Implementation code (failure injection scripts/manifests)
48	3. Monitoring setup and alert configuration
49	4. Rollback procedures and safety controls
50	5. Learning summary and improvement recommendations
51
52	## Concrete Example: Pod Failure Experiment (Litmus Chaos)
53
54	The following shows a complete experiment — from hypothesis to rollback — using Litmus Chaos on Kubernetes.
55
56	### Step 1 — Define steady state and apply the experiment
57
58	```bash
59	# Verify baseline: p99 latency < 200ms, error rate < 0.1%
60	kubectl get deploy my-service -n production
61	kubectl top pods -n production -l app=my-service
62	```
63
64	### Step 2 — Create and apply a Litmus ChaosEngine manifest
65
66	```yaml
67	# chaos-pod-delete.yaml
68	apiVersion: litmuschaos.io/v1alpha1
69	kind: ChaosEngine
70	metadata:
71	name: my-service-pod-delete
72	namespace: production
73	spec:
74	appinfo:
75	appns: production
76	applabel: "app=my-service"
77	appkind: deployment
78	# Limit blast radius: only 1 replica at a time
79	engineState: active
80	chaosServiceAccount: litmus-admin
81	experiments:
82	- name: pod-delete
83	spec:
84	components:
85	env:
86	- name: TOTAL_CHAOS_DURATION
87	value: "60" # seconds
88	- name: CHAOS_INTERVAL
89	value: "20" # delete one pod every 20s
90	- name: FORCE
91	value: "false"
92	- name: PODS_AFFECTED_PERC
93	value: "33" # max 33% of replicas affected
94	```
95
96	```bash
97	# Apply the experiment
98	kubectl apply -f chaos-pod-delete.yaml
99
100	# Watch experiment status
101	kubectl describe chaosengine my-service-pod-delete -n production
102	kubectl get chaosresult my-service-pod-delete-pod-delete -n production -w
103	```
104
105	### Step 3 — Monitor during the experiment
106
107	```bash
108	# Tail application logs for errors
109	k

People who liked this also viewed

6 picks

Type