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

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？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

このリポジトリのすべてを見る

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

インストール方法

ソースファイルを確認