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
آخر نشاط في المصدر: ١٤ أبريل ٢٠٢٦ في ٠٧:٥٧
لغة SKILL.md المكتشفة: الإنجليزية
النجوم: ٦٩
التفرعات: ٩

خيارات التثبيت

يُحدَّد 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

عرض الكل من هذا المستودع

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

خيارات التثبيت

مراجعة ملفات المصدر