agentleFS
manastalukdarmanastalukdar/ai-devstudio/skills/chaos-test/SKILL.md

chaos-test

Skill1 starsChanged 7 months agoMITView on GitHub

Analyze codebase for resilience gaps — missing retry logic, absent timeouts, circuit-breaker opportunities, single points of failure, and degradation-mode blind spots

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Early exit: If git diff --staged --name-only returns no files and no $ARGUMENTS path is given, report "No staged changes to analyze" and …

    line 100

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Chaos Test — Resilience Gap Analysis

Scan the codebase for failure modes that would surface under real-world stress: network partitions, dependency outages, slow consumers, and burst traffic.

Usage

/chaos-test                  # full scan of staged changes and key integration points
/chaos-test <path>           # target a specific file or directory
/chaos-test --service <name> # focus on a named external service dependency

Behavior

Step 1 — Identify integration boundaries

# Find outbound HTTP calls, queue producers/consumers, DB calls, cache hits
grep -rn "fetch\|axios\|http\.\|requests\.\|redis\|pg\.\|mysql\|amqp\|kafka" \
  --include="*.ts" --include="*.py" --include="*.go" --include="*.js" \
  -l . | head -30

Step 2 — Check each boundary for resilience controls

For every integration point found, verify presence of:

ControlWhat to grep forRisk if absent
Timeouttimeout, AbortController, signalHangs under slow upstream
Retryretry, backoff, attemptSingle transient failure = hard failure
Circuit breakeropossum, cockatiel, breaker, circuitbreakerCascading failure under sustained outage
Fallback / degraded modefallback, default, catch returning a stubNo graceful degradation
Rate-limit handling429, RateLimitError, retry-afterThundering herd kills upstream
Bulkhead / concurrency capsemaphore, pLimit, asyncio.SemaphoreSingle slow dep starves thread pool

Step 3 — Score each boundary

For each integration point, assign a risk tier:

  • Critical — no timeout AND no retry AND no fallback
  • High — missing two of the three controls above
  • Medium — missing one control
  • Low — all controls present; note any configuration concerns (timeout too high, retry without jitter, etc.)

Step 4 — Report findings

Output a prioritized list:

CHAOS ANALYSIS — <path>

Critical (fix before next deploy)
  src/payments/stripe.ts:42   POST /charges — no timeout, no retry, no fallback
  src/auth/token.ts:88        Redis GET — no timeout; outage causes auth failure

High
  src/search/elastic.ts:17    ES query — no circuit breaker; slow queries block response

Medium
  src/email/sendgrid.ts:31    Retry present but no jitter (thundering herd risk)

Low
  src/cache/redis.ts:55       All controls present; timeout at 30s is high — consider 5s

Suggested experiment targets (fault to inject → expected behavior → gap if wrong):
  1. Kill Redis → auth should degrade to DB lookup → currently: hard 500
  2. Throttle Stripe to 2s → checkout should timeout at 1s → currently: no timeout set

Step 5 — Suggest quick wins

For each Critical/High finding, propose the minimal fix:

stripe.ts:42 — Add AbortSignal timeout (5s) and exponential-backoff retry (3 attempts, 100ms base, jitter):
  const res = await fetch(url, { signal: AbortSignal.timeout(5000) })

Edge Cases

  • No external dependencies: Report "No integration boundaries detected" and exit.
  • Monorepo: Scan from $ARGUMENTS path; skip test files unless --include-tests passed.
  • gRPC / GraphQL: Detect grpc, graphql-request, and apollo-client as integration points.
  • Already uses resilience library: Note which library is in use and check it is configured, not just imported.

Token Optimization

Expected range: 600–2,000 tokens (grep-driven discovery); 100–300 tokens (no integrations found, early exit)

Patterns used: Grep-before-Read (scan for integration points before reading any file), git diff scope (staged changes first), progressive disclosure (summary → details on request)

Early exit: If git diff --staged --name-only returns no files and no $ARGUMENTS path is given, report "No staged changes to analyze" and exit.

Caching: Caches file list from boundary scan in .claude/cache/chaos-test/boundaries.json (invalidated when package.json, go.mod, or requirements.txt changes).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.