chaos-engineering

Provides chaos engineering best practices for resilience testing, fault injection, and game day planning. Use when designing resilience experiments, configuring chaos tools, planning game days, or when user mentions 'chaos engineering', 'resilience', 'litmus', 'game day', 'fault injection', 'chaos monkey', 'blast radius', 'steady state', 'failure mode'.

跳到安装

仓库: Tibsfox/gsd-skill-creator
最近来源活动: 2026年4月14日 07:57
检测到的 SKILL.md 语言: 英语
星标: 69
分支: 9

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill chaos-engineering

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

goal-ambiguity-gate

Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.

2026-07-19

memory-hubness-gate

Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.

2026-07-19

memory-use-warrant

Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.

2026-07-19

查看这个仓库的全部 Skills

Chaos Engineering

Best practices for systematically injecting failures to discover weaknesses before they cause outages, using steady-state hypotheses, controlled experiments, and progressive blast radius expansion.

Chaos Engineering Principles

Chaos engineering is not random destruction. It is disciplined experimentation on distributed systems to build confidence in their resilience.

Define Steady State --> Form Hypothesis --> Design Experiment --> Control Blast Radius --> Run --> Analyze --> Fix --> Repeat

Principle

Description

Why It Matters

Define steady state

Identify measurable normal behavior (latency, error rate, throughput)

Without a baseline, you cannot detect degradation

Hypothesize around steady state

Predict the system will maintain steady state during fault

Forces explicit thinking about expected behavior

Vary real-world events

Inject failures that actually happen (network, disk, process, dependency)

Simulated failures must map to real failure modes

Run in production

Test where real complexity exists (with safeguards)

Staging rarely matches production topology

Minimize blast radius

Start small, expand gradually, have kill switches

Chaos should reveal problems, not cause outages

Automate experiments

Repeatable experiments run in CI/CD or on schedule

Manual experiments don't scale and introduce bias

Build a hypothesis backlog

Track what you want to test and what you've learned

Systematic coverage prevents blind spots

Steady-State Hypothesis Template

Every chaos experiment begins with a hypothesis. This template ensures experiments are structured and measurable.

# Steady-State Hypothesis Document experiment: name: "Payment service database failover" id: "CHAOS-042" date: "2026-02-07" owner: "team-payments" reviewer:

Chaos Engineering

Best practices for systematically injecting failures to discover weaknesses before they cause outages, using steady-state hypotheses, controlled experiments, and progressive blast radius expansion.

Chaos Engineering Principles

Chaos engineering is not random destruction. It is disciplined experimentation on distributed systems to build confidence in their resilience.

Define Steady State --> Form Hypothesis --> Design Experiment --> Control Blast Radius --> Run --> Analyze --> Fix --> Repeat

Principle

Description

Why It Matters

Define steady state

Identify measurable normal behavior (latency, error rate, throughput)

Without a baseline, you cannot detect degradation

Hypothesize around steady state

Predict the system will maintain steady state during fault

Forces explicit thinking about expected behavior

Vary real-world events

Inject failures that actually happen (network, disk, process, dependency)

Simulated failures must map to real failure modes

Run in production

Test where real complexity exists (with safeguards)

Staging rarely matches production topology

Minimize blast radius

Start small, expand gradually, have kill switches

Chaos should reveal problems, not cause outages

Automate experiments

Repeatable experiments run in CI/CD or on schedule

Manual experiments don't scale and introduce bias

Build a hypothesis backlog

Track what you want to test and what you've learned

Systematic coverage prevents blind spots

Steady-State Hypothesis Template

Every chaos experiment begins with a hypothesis. This template ensures experiments are structured and measurable.

# Steady-State Hypothesis Document experiment: name: "Payment service database failover" id: "CHAOS-042" date: "2026-02-07" owner: "team-payments" reviewer:

name: Resilience Tests on: push: branches: [main] schedule: - cron: '0 10 * * 1' # Every Monday at 10:00 UTC permissions: contents: read jobs: chaos-tests: runs-on: ubuntu-latest timeout-minutes: 30 steps: - uses: actions/checkout@v4 - name: Set up test cluster uses: helm/kind-action@v1 with: cluster_name: chaos-test config: test/kind-config.yaml - name: Deploy application run: | kubectl apply -f k8s/namespace.yaml kubectl apply -f k8s/deployment.yaml kubectl apply -f k8s/service.yaml kubectl wait --for=condition=available deployment/payment-service \ -n payments --timeout=120s - name: Install LitmusChaos run: | kubectl apply -f https://litmuschaos.github.io/litmus/litmus-operator-v3.0.0.yaml kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=litmus \ -n litmus --timeout=120s - name: Verify steady state run: | # Check application health before chaos kubectl exec -n payments deploy/payment-service -- \ curl -sf http://localhost:8080/health || exit 1 - name: Run chaos experiment run: | kubectl apply -f chaos/pod-delete-experiment.yaml # Wait for experiment to complete kubectl wait --for=jsonpath='{.status.engineStatus}'=completed \ chaosengine/payment-chaos -n payments --timeout=300s - name: Verify resilience run: | # Check experiment verdict VERDICT=$(kubectl get chaosresult payment-chaos-pod-delete \ -n payments -o jsonpath='{.status.experimentStatus.verdict}') echo "Experiment verdict: $VERDICT" if [ "$VERDICT" != "Pass" ]; then echo "CHAOS TEST FAILED: System did not maintain steady state" kubectl logs -n payments -l app=payment-service --tail=100 exit 1 fi - name: Collect results if: always() run: | kubectl get chaosresult -n payments -o yaml > chaos-results.yaml - uses: actions/upload-artifact@v4 if: always() with: name: chaos-results path: chaos-results.yaml retention-days: 30

name	chaos-engineering
description	Provides chaos engineering best practices for resilience testing, fault injection, and game day planning. Use when designing resilience experiments, configuring chaos tools, planning game days, or when user mentions 'chaos engineering', 'resilience', 'litmus', 'game day', 'fault injection', 'chaos monkey', 'blast radius', 'steady state', 'failure mode'.
type	skill
category	ops
status	stable
origin	tibsfox
modified	false
first_seen	"2026-02-07T00:00:00.000Z"
first_path	examples/chaos-engineering/SKILL.md
superseded_by	null

name	chaos-engineering
description	Provides chaos engineering best practices for resilience testing, fault injection, and game day planning. Use when designing resilience experiments, configuring chaos tools, planning game days, or when user mentions 'chaos engineering', 'resilience', 'litmus', 'game day', 'fault injection', 'chaos monkey', 'blast radius', 'steady state', 'failure mode'.
type	skill
category	ops
status	stable
origin	tibsfox
modified	false
first_seen	"2026-02-07T00:00:00.000Z"
first_path	examples/chaos-engineering/SKILL.md
superseded_by	null

Level	Scope	Example	Risk	When to Use
1 - Unit	Single container/process	Kill one pod replica	Minimal	Starting out, new experiments
2 - Service	All replicas of one service	Delete all pods in deployment	Low	After Level 1 succeeds
3 - Dependency	Degrade a dependency	Add latency to database connection	Medium	Testing circuit breakers, retries
4 - Zone	Entire availability zone	Drain all nodes in one AZ	High	Quarterly DR exercises
5 - Region	Full region failure	Redirect all traffic to secondary region	Critical	Annual DR exercises, game days

Level	Name	Practices	Experiments	Frequency
0	None	No chaos practice	None	Never
1	Exploratory	Ad-hoc experiments in staging	Pod kills, restarts	Quarterly
2	Systematic	Hypothesis-driven, documented	Network faults, dependency failures	Monthly
3	Automated	Chaos in CI/CD, scheduled experiments	Multi-service scenarios, zone failures	Weekly
4	Advanced	Production chaos, game days, culture of resilience	Region failover, data plane chaos	Continuous

Failure Mode	Tool/Method	What It Validates
Pod termination	LitmusChaos pod-delete	Auto-scaling, health checks, restart policies
Network latency	tc netem / LitmusChaos	Timeouts, circuit breakers, retry logic
Network partition	iptables / LitmusChaos	Split-brain handling, quorum mechanisms
DNS failure	CoreDNS manipulation	DNS caching, fallback resolution
CPU stress	stress-ng / LitmusChaos	Autoscaling triggers, throttling behavior
Memory pressure	stress-ng / LitmusChaos	OOM handling, graceful degradation
Disk I/O saturation	fio / LitmusChaos	Write-ahead log performance, disk alerts
Dependency unavailable	Network block / mock	Circuit breakers, fallback responses, bulkheads
Clock skew	chrony manipulation	Certificate validation, token expiry, cron jobs
Configuration drift	Mutate ConfigMap/Secret	Config reload, graceful failure on bad config

chaos-engineering

安装方式

检查来源文件