Chaos Engineering Fault Injection

Problem

During code generation, refactoring, or service requirement design, performance issues often stay invisible in ordinary calls: CPU hot spots, memory leaks, slow IO, network jitter, lock contention, N+1 queries, and rate-limiting or circuit-breaker misconfiguration. This skill turns fault injection into an explicit development checkpoint: it asks whether the current task should create controlled bottlenecks, then selects injection type, language, and placement so engineers can observe stressed behavior before committing changes.

How It Works

The skill activates for new code, code modification, and requirements involving APIs, backend services, or data pipelines. The workflow first asks whether fault injection should be used. If accepted, it selects from CPU, memory leak, IO blocking, network latency, concurrency contention, database bottlenecks, rate limiting / circuit breaker, resource exhaustion, or all injections, then chooses a target language such as Python, Go, Java, TypeScript, Rust, or C++.

Implementation options include:
- Automated script: for existing files, detects the language, chooses a function or method insertion point, adds [FAULT_INJECT] marked code, and produces a JSON report.
- Manual templates: for generated code, embeds language-specific bottleneck patterns.
- Framework middleware: for web services, uses templates for Flask, Express, Gin, Django, Spring Boot, and similar stacks, closer to real request paths.

Injected code is gated by environment variables, defaulting to FAULT_INJECT_ENABLED=false, so normal behavior is unchanged. Typically each file receives the first matching method for each bottleneck type, making cleanup easier.

Boundaries

This is best used in development, integration testing, or pre-load-test validation, not as a production incident-replay tool. For online traffic, evaluate middleware side effects, resource cost, and switch strategy; keep [FAULT_INJECT] markers so injected code can be found and removed later.