Qe Chaos Resilience
- 32 installs
- 433 repo stars
- Updated August 4, 2026
- proffesor-for-testing/agentic-qe
qe chaos resilience is a Claude Code skill for ai & agent building.
About
qe chaos resilience is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.
- qe chaos resilience
- AI & Agent Building
- AI-coding skill
Qe Chaos Resilience by the numbers
- 32 all-time installs (skills.sh)
- Ranked #9,101 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/proffesor-for-testing/agentic-qe --skill qe-chaos-resilienceAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 32 |
|---|---|
| repo stars | ★ 433 |
| Last updated | August 4, 2026 |
| Repository | proffesor-for-testing/agentic-qe ↗ |
How do I helps with ai & agent building tasks.?
Helps with ai & agent building tasks.
Who is it for?
Best when you're working on ai & agent building and need structured help with qe chaos resilience.
Skip if: Teams with no ai & agent building needs, or anyone wanting a generic chat assistant without this specific workflow.
When should I use this skill?
When you need to helps with ai & agent building tasks., or when qe chaos resilience is a claude code skill for ai & agent building.
What you get
Structured output aligned to qe chaos resilience: qe chaos resilience, AI & Agent Building.
Files
QE Chaos Resilience
Purpose
Guide the use of v3's chaos engineering capabilities including controlled fault injection, load/stress testing, resilience validation, and disaster recovery testing.
Activation
- When testing system resilience
- When performing chaos experiments
- When load/stress testing
- When validating disaster recovery
- When testing circuit breakers
Quick Start
# Run chaos experiment
aqe chaos run --experiment network-latency --target api-service
# Load test
aqe chaos load --scenario peak-traffic --duration 30m
# Stress test to breaking point
aqe chaos stress --endpoint /api/users --max-users 10000
# Test circuit breaker
aqe chaos circuit-breaker --service payment-serviceAgent Workflow
// Chaos experiment
Task("Run chaos experiment", `
Execute controlled chaos on api-service:
- Inject 500ms network latency
- Monitor service health metrics
- Verify circuit breaker activation
- Measure recovery time
- Document findings
`, "qe-chaos-engineer")
// Load testing
Task("Performance load test", `
Run load test simulating Black Friday traffic:
- Ramp up to 10,000 concurrent users
- Maintain load for 30 minutes
- Monitor response times and error rates
- Identify bottlenecks
- Compare against SLAs
`, "qe-load-tester")Chaos Experiments
1. Fault Injection
await chaosEngineer.injectFault({
target: 'api-service',
fault: {
type: 'latency',
parameters: {
delay: '500ms',
jitter: '100ms',
percentage: 50
}
},
duration: '5m',
monitoring: {
metrics: ['response_time', 'error_rate', 'throughput'],
alerts: true
},
rollback: {
automatic: true,
trigger: 'error_rate > 10%'
}
});2. Load Testing
await loadTester.execute({
scenario: 'peak-traffic',
profile: {
rampUp: '5m',
steadyState: '30m',
rampDown: '5m'
},
users: {
initial: 100,
target: 5000,
pattern: 'linear'
},
assertions: {
p95_latency: '<500ms',
error_rate: '<1%',
throughput: '>1000rps'
}
});3. Stress Testing
await loadTester.stressTest({
endpoint: '/api/checkout',
strategy: 'step-increase',
steps: [100, 500, 1000, 2000, 5000],
stepDuration: '5m',
findBreakingPoint: true,
monitoring: {
resourceUtilization: true,
databaseConnections: true,
memoryUsage: true
}
});4. Resilience Validation
await resilienceTester.validate({
scenarios: [
'database-failover',
'cache-failure',
'external-service-timeout',
'pod-termination'
],
expectations: {
gracefulDegradation: true,
automaticRecovery: true,
dataIntegrity: true,
recoveryTime: '<30s'
}
});Fault Types
| Fault | Description | Use Case |
|---|---|---|
| Latency | Add network delay | Test timeouts |
| Packet Loss | Drop network packets | Test retry logic |
| CPU Stress | Consume CPU | Test resource limits |
| Memory Pressure | Consume memory | Test OOM handling |
| Disk Full | Fill disk space | Test disk errors |
| Process Kill | Terminate process | Test recovery |
Chaos Report
interface ChaosReport {
experiment: {
name: string;
target: string;
fault: FaultConfig;
duration: number;
};
results: {
hypothesis: string;
validated: boolean;
metrics: {
before: MetricSnapshot;
during: MetricSnapshot;
after: MetricSnapshot;
};
events: ChaosEvent[];
recovery: {
detected: boolean;
time: number;
automatic: boolean;
};
};
findings: {
severity: 'critical' | 'high' | 'medium' | 'low';
description: string;
recommendation: string;
}[];
artifacts: {
logs: string;
metrics: string;
traces: string;
};
}Safety Controls
safety:
blast_radius:
max_affected_pods: 1
max_affected_percentage: 10
abort_conditions:
- error_rate > 50%
- p99_latency > 10s
- service_unavailable
excluded_environments:
- production-critical
required_approvals:
production: 2
staging: 0SLA Validation
await resilienceTester.validateSLA({
slas: {
availability: 99.9,
p95_latency: 500,
error_rate: 0.1
},
period: '30d',
report: {
breaches: true,
trends: true,
projections: true
}
});Coordination
Primary Agents: qe-chaos-engineer, qe-load-tester, qe-resilience-tester Coordinator: qe-chaos-coordinator Related Skills: qe-performance, security-testing
# =============================================================================
# AQE Skill Evaluation Test Suite: QE Chaos Resilience v1.0.0
# =============================================================================
#
# Comprehensive evaluation suite for the qe-chaos-resilience skill.
# Tests fault injection, load testing, stress testing, resilience validation,
# circuit breaker testing, and SLA validation capabilities.
#
# Schema: .claude/skills/.validation/schemas/skill-eval.schema.json
# Validator: .claude/skills/qe-chaos-resilience/scripts/validate-config.json
#
# Coverage:
# - Fault Injection (latency, packet loss, CPU stress, memory pressure)
# - Load Testing (ramp-up profiles, sustained load, bottleneck detection)
# - Stress Testing (step-increase, breaking point detection)
# - Resilience Validation (graceful degradation, automatic recovery)
# - Circuit Breaker Testing
# - SLA Validation and monitoring
#
# =============================================================================
skill: qe-chaos-resilience
version: 1.0.0
description: >
Comprehensive evaluation suite for the qe-chaos-resilience skill.
Tests chaos engineering capabilities including controlled fault injection,
load/stress testing, resilience validation, disaster recovery testing,
and SLA compliance verification.
# =============================================================================
# Multi-Model Configuration
# =============================================================================
models_to_test:
- claude-opus-4-8 # Capability ceiling (high-stakes skill)
- claude-sonnet-4-6 # Primary (high accuracy expected)
- claude-haiku-4-5 # Fast model (minimum quality floor)
# =============================================================================
# MCP Integration Configuration
# =============================================================================
mcp_integration:
enabled: true
namespace: skill-validation
query_patterns: true
track_outcomes: true
store_patterns: true
share_learning: true
update_quality_gate: true
target_agents:
- qe-learning-coordinator
- qe-queen-coordinator
- qe-chaos-engineer
- qe-load-tester
# =============================================================================
# ReasoningBank Learning Configuration
# =============================================================================
learning:
store_success_patterns: true
store_failure_patterns: true
pattern_ttl_days: 90
min_confidence_to_store: 0.7
cross_model_comparison: true
# =============================================================================
# Result Format Configuration
# =============================================================================
result_format:
json_output: true
markdown_report: true
include_raw_output: false
include_timing: true
include_token_usage: true
# =============================================================================
# Environment Setup
# =============================================================================
setup:
required_tools:
- jq
environment_variables:
CHAOS_SAFETY_MODE: "true"
LOAD_TEST_TIMEOUT: "60000"
fixtures: []
# =============================================================================
# TEST CASES
# =============================================================================
test_cases:
# ---------------------------------------------------------------------------
# CATEGORY: Fault Injection
# ---------------------------------------------------------------------------
- id: tc001_latency_fault_injection
description: "Detect and validate latency fault injection configuration"
category: fault_injection
priority: critical
input:
prompt: |
Design a chaos experiment to inject 500ms network latency with 100ms jitter
affecting 50% of requests to the api-service for 5 minutes. Include monitoring
setup for response times, error rates, and circuit breaker activation.
context:
service: api-service
fault_type: latency
target_duration_ms: 300000
expected_output:
must_contain:
- "latency"
- "500ms"
- "monitoring"
- "circuit breaker"
- "recovery"
must_not_contain:
- "error"
- "unable to"
severity_classification: critical
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.8
reasoning_quality_min: 0.7
- id: tc002_packet_loss_stress_test
description: "Validate packet loss fault injection with retry logic testing"
category: fault_injection
priority: high
input:
prompt: |
Create a chaos scenario to drop 10% of network packets on a payment service.
Design test cases to verify retry logic, idempotency, and graceful degradation.
What metrics would you monitor?
context:
service: payment-service
fault_type: packet_loss
criticality: high
expected_output:
must_contain:
- "packet loss"
- "retry"
- "idempotent"
- "degradation"
- "metrics"
must_match_regex:
- "monitoring|metrics"
severity_classification: high
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Load Testing
# -----------------------------------------------------------------------
- id: tc003_load_test_ramp_profile
description: "Plan load testing with realistic ramp-up and sustain phases"
category: load_testing
priority: critical
input:
prompt: |
Design a load test for an e-commerce API expecting Black Friday traffic.
Target: ramp to 10,000 concurrent users over 5 minutes, sustain for 30 minutes,
then graceful ramp-down. What assertions would you set? How would you identify
bottlenecks?
context:
scenario: peak_traffic
target_users: 10000
duration_minutes: 40
expected_output:
must_contain:
- "ramp"
- "10000"
- "assertions"
- "bottleneck"
- "baseline"
must_not_contain:
- "fail"
- "error"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
reasoning_quality_min: 0.75
- id: tc004_stress_test_breaking_point
description: "Stress test to find breaking point of checkout endpoint"
category: load_testing
priority: high
input:
prompt: |
Design a stress test for /api/checkout using step-increase strategy:
Start with 100 users, increase by 500 every 5 minutes until failure.
Monitor CPU, memory, database connections, response times.
How do you detect the breaking point?
context:
endpoint: /api/checkout
strategy: step_increase
resource_monitoring: true
expected_output:
must_contain:
- "step-increase"
- "breaking point"
- "CPU"
- "memory"
- "database"
- "response"
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Resilience Validation
# ---------------------------------------------------------------------------
- id: tc005_resilience_validation_scenarios
description: "Validate resilience across multiple failure scenarios"
category: resilience
priority: critical
input:
prompt: |
Define a comprehensive resilience test suite covering:
1. Database failover recovery
2. Cache layer failure with graceful degradation
3. External service timeout handling
4. Pod/container termination recovery
For each scenario, what would success look like? What metrics prove resilience?
context:
scope: multi_service
include_disaster_recovery: true
expected_output:
must_contain:
- "database"
- "cache"
- "external service"
- "recovery"
- "graceful"
- "metrics"
must_not_contain:
- "unable"
- "cannot test"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
- id: tc006_circuit_breaker_validation
description: "Test circuit breaker activation and recovery patterns"
category: resilience
priority: high
input:
prompt: |
Design a test to validate circuit breaker behavior:
- Trigger failure conditions to open the circuit
- Monitor half-open state transitions
- Verify fallback behavior during outage
- Test recovery to closed state
What failures would trigger the circuit breaker?
context:
pattern: circuit_breaker
failure_threshold: 50
expected_output:
must_contain:
- "circuit breaker"
- "open"
- "half-open"
- "fallback"
- "recovery"
- "failure threshold"
severity_classification: high
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: SLA Validation
# ---------------------------------------------------------------------------
- id: tc007_sla_compliance_check
description: "Validate service meets SLA targets during chaos"
category: sla_validation
priority: critical
input:
prompt: |
After running a chaos experiment with 100ms latency injection, validate:
- Availability: 99.9% (should remain > 99.9%)
- P95 Latency: must stay < 500ms
- Error Rate: must stay < 0.1%
- Throughput: must handle > 1000 rps
How would you measure and report SLA compliance?
context:
availability_sla: 99.9
p95_latency_ms: 500
error_rate_max: 0.1
throughput_min_rps: 1000
expected_output:
must_contain:
- "SLA"
- "99.9"
- "latency"
- "error rate"
- "throughput"
- "compliance"
must_not_contain:
- "breach"
- "violation"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
# ---------------------------------------------------------------------------
# CATEGORY: Chaos Report Analysis
# ---------------------------------------------------------------------------
- id: tc008_chaos_report_generation
description: "Generate comprehensive chaos experiment report"
category: reporting
priority: high
input:
prompt: |
After a chaos experiment, generate a report including:
- Hypothesis (what we expected to happen)
- Validation result (did it happen?)
- Metrics before/during/after
- Recovery detection and time
- Findings with severity and recommendations
- Artifacts (logs, metrics, traces)
context:
experiment: network_latency_injection
duration_minutes: 5
expected_output:
must_contain:
- "hypothesis"
- "metrics"
- "recovery"
- "findings"
- "recommendation"
- "artifacts"
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Negative Tests
# ---------------------------------------------------------------------------
- id: tc009_safety_guardrails
description: "Verify safety controls prevent dangerous chaos experiments"
category: safety
priority: critical
input:
prompt: |
What safety guardrails should prevent:
1. Blast radius > 10% of production
2. Error rate spikes > 50%
3. Service unavailability
4. Running on production-critical systems
How would you abort an experiment that violates safety thresholds?
context:
environment: production
safety_critical: true
expected_output:
must_contain:
- "safety"
- "guard"
- "abort"
- "threshold"
- "blast radius"
must_not_contain:
- "unsafe"
- "dangerous"
finding_count:
max: 2
validation:
schema_check: true
allow_partial: true
# =============================================================================
# SUCCESS CRITERIA
# =============================================================================
success_criteria:
pass_rate: 0.8
critical_pass_rate: 1.0
avg_reasoning_quality: 0.75
max_execution_time_ms: 300000
cross_model_variance: 0.15
# =============================================================================
# METADATA
# =============================================================================
metadata:
author: "qe-chaos-engineer"
created: "2026-02-02"
last_updated: "2026-02-02"
coverage_target: >
Fault injection (latency, packet loss, CPU/memory stress), load testing
(ramp profiles, sustained load, bottleneck detection), stress testing,
resilience validation, circuit breaker patterns, SLA compliance, and
chaos report generation with safety guardrails.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://agentic-qe.dev/schemas/skills/qe-chaos-resilience/output.json",
"title": "QE Chaos Resilience Skill Output Schema",
"description": "Schema for qe-chaos-resilience skill output with chaos experiments, failure scenarios, and recovery metrics.",
"type": "object",
"required": ["skillName", "version", "timestamp", "status", "trustTier", "output"],
"properties": {
"skillName": {
"type": "string",
"const": "qe-chaos-resilience"
},
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+(-[a-zA-Z0-9]+)?$"
},
"timestamp": {
"type": "string"
},
"status": {
"type": "string",
"enum": ["success", "partial", "failed", "skipped"]
},
"trustTier": {
"type": "integer",
"const": 3
},
"output": {
"type": "object",
"required": ["summary", "experiments", "resilienceScore"],
"properties": {
"summary": {
"type": "string",
"minLength": 50,
"maxLength": 2000,
"description": "Human-readable summary of chaos resilience assessment"
},
"experiments": {
"type": "array",
"items": {
"$ref": "#/$defs/chaosExperiment"
},
"minItems": 1,
"maxItems": 100,
"description": "List of chaos experiments executed"
},
"failureScenarios": {
"type": "array",
"items": {
"$ref": "#/$defs/failureScenario"
},
"maxItems": 50,
"description": "Identified failure scenarios and their impact"
},
"recoveryMetrics": {
"$ref": "#/$defs/recoveryMetrics",
"description": "System recovery metrics and SLA compliance"
},
"resilienceScore": {
"$ref": "#/$defs/resilienceScore",
"description": "Overall resilience score"
},
"weaknesses": {
"type": "array",
"items": {
"$ref": "#/$defs/weakness"
},
"maxItems": 50
},
"recommendations": {
"type": "array",
"items": {
"$ref": "#/$defs/recommendation"
},
"maxItems": 50
},
"metrics": {
"$ref": "#/$defs/chaosMetrics"
},
"categories": {
"type": "object",
"additionalProperties": {
"$ref": "#/$defs/categoryScore"
}
}
}
},
"metadata": {
"type": "object",
"properties": {
"executionTimeMs": { "type": "integer", "minimum": 0 },
"toolsUsed": { "type": "array", "items": { "type": "string" } },
"agentId": { "type": "string" },
"environment": { "type": "string", "enum": ["development", "staging", "production", "ci"] }
}
},
"validation": {
"type": "object",
"properties": {
"schemaValid": { "type": "boolean" },
"contentValid": { "type": "boolean" },
"confidence": { "type": "number", "minimum": 0, "maximum": 1 }
}
},
"learning": {
"type": "object",
"properties": {
"patternsDetected": { "type": "array", "items": { "type": "string" } },
"reward": { "type": "number", "minimum": 0, "maximum": 1 }
}
}
},
"$defs": {
"chaosExperiment": {
"type": "object",
"required": ["id", "name", "type", "result"],
"properties": {
"id": {
"type": "string",
"pattern": "^CHAOS-\\d{3,6}$"
},
"name": {
"type": "string",
"minLength": 5,
"maxLength": 200
},
"type": {
"type": "string",
"enum": ["network", "resource", "state", "application", "infrastructure", "byzantine"]
},
"subType": {
"type": "string",
"enum": ["latency", "packet-loss", "partition", "cpu-stress", "memory-exhaust", "disk-fill", "pod-terminate", "node-drain", "zone-failure", "exception-inject", "spike-load"]
},
"target": {
"type": "object",
"properties": {
"type": { "type": "string" },
"name": { "type": "string" },
"namespace": { "type": "string" }
}
},
"result": {
"type": "string",
"enum": ["passed", "failed", "partial", "expected-fail"]
},
"duration": { "type": "integer", "minimum": 0 },
"recoveryTime": {
"type": "object",
"properties": {
"actual": { "type": "integer", "minimum": 0 },
"sla": { "type": "integer", "minimum": 0 },
"withinSla": { "type": "boolean" }
}
},
"steadyStateHypothesis": {
"type": "object",
"properties": {
"metrics": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": { "type": "string" },
"operator": { "type": "string" },
"threshold": {},
"actual": {},
"passed": { "type": "boolean" }
}
}
}
}
},
"blastRadius": {
"type": "object",
"properties": {
"scope": { "type": "string", "enum": ["single-instance", "single-service", "multi-service", "zone", "cluster"] },
"emergencyStop": { "type": "boolean" }
}
}
}
},
"failureScenario": {
"type": "object",
"required": ["id", "name", "severity"],
"properties": {
"id": {
"type": "string",
"pattern": "^FAIL-\\d{3,6}$"
},
"name": {
"type": "string",
"minLength": 5,
"maxLength": 200
},
"severity": {
"type": "string",
"enum": ["critical", "high", "medium", "low"]
},
"likelihood": {
"type": "string",
"enum": ["rare", "unlikely", "possible", "likely", "certain"]
},
"impact": {
"type": "string",
"maxLength": 1000
},
"mitigation": {
"type": "string",
"maxLength": 2000
},
"triggeredBy": {
"type": "array",
"items": { "type": "string", "pattern": "^CHAOS-\\d{3,6}$" }
}
}
},
"recoveryMetrics": {
"type": "object",
"properties": {
"mttr": {
"type": "integer",
"minimum": 0,
"description": "Mean Time To Recovery in milliseconds"
},
"mtbf": {
"type": "integer",
"minimum": 0,
"description": "Mean Time Between Failures in milliseconds"
},
"rto": {
"type": "integer",
"minimum": 0,
"description": "Recovery Time Objective in milliseconds"
},
"rpo": {
"type": "integer",
"minimum": 0,
"description": "Recovery Point Objective in milliseconds"
},
"availability": {
"type": "number",
"minimum": 0,
"maximum": 100,
"description": "Availability percentage during chaos"
},
"slaCompliance": {
"type": "boolean",
"description": "Whether SLA was maintained during chaos"
},
"autoRecoveryRate": {
"type": "number",
"minimum": 0,
"maximum": 100,
"description": "Percentage of failures with auto-recovery"
}
}
},
"resilienceScore": {
"type": "object",
"required": ["value", "max"],
"properties": {
"value": { "type": "number", "minimum": 0, "maximum": 100 },
"max": { "type": "number", "const": 100 },
"grade": { "type": "string", "pattern": "^[A-F][+-]?$" },
"trend": { "type": "string", "enum": ["improving", "stable", "declining", "unknown"] },
"riskLevel": { "type": "string", "enum": ["critical", "high", "medium", "low", "minimal"] }
}
},
"weakness": {
"type": "object",
"required": ["id", "title", "severity"],
"properties": {
"id": { "type": "string", "pattern": "^WEAK-\\d{3,6}$" },
"title": { "type": "string", "minLength": 10, "maxLength": 200 },
"description": { "type": "string", "maxLength": 2000 },
"severity": { "type": "string", "enum": ["critical", "high", "medium", "low"] },
"category": { "type": "string" },
"remediation": { "type": "string", "maxLength": 2000 }
}
},
"recommendation": {
"type": "object",
"required": ["id", "title", "priority"],
"properties": {
"id": { "type": "string", "pattern": "^REC-\\d{3,6}$" },
"title": { "type": "string", "maxLength": 200 },
"description": { "type": "string", "maxLength": 2000 },
"priority": { "type": "string", "enum": ["critical", "high", "medium", "low"] },
"effort": { "type": "string", "enum": ["trivial", "low", "medium", "high", "major"] }
}
},
"chaosMetrics": {
"type": "object",
"properties": {
"totalExperiments": { "type": "integer", "minimum": 0 },
"passedExperiments": { "type": "integer", "minimum": 0 },
"failedExperiments": { "type": "integer", "minimum": 0 },
"weaknessesFound": { "type": "integer", "minimum": 0 },
"averageRecoveryTime": { "type": "integer", "minimum": 0 },
"totalDurationMs": { "type": "integer", "minimum": 0 }
}
},
"categoryScore": {
"type": "object",
"required": ["score"],
"properties": {
"score": { "type": "number", "minimum": 0, "maximum": 100 },
"grade": { "type": "string", "pattern": "^[A-F][+-]?$" },
"experimentCount": { "type": "integer", "minimum": 0 }
}
}
}
}
{
"skillName": "qe-chaos-resilience",
"skillVersion": "1.0.0",
"requiredTools": [
"jq"
],
"optionalTools": [
"chaos",
"litmus",
"kubectl",
"python3"
],
"schemaPath": "schemas/output.json",
"requiredFields": [
"skillName",
"status",
"output",
"output.summary",
"output.experiments",
"output.resilienceScore"
],
"requiredNonEmptyFields": [
"output.summary"
],
"mustContainTerms": [
"chaos",
"resilience",
"experiment"
],
"mustNotContainTerms": [
"TODO",
"FIXME",
"placeholder"
],
"enumValidations": {
".status": [
"success",
"partial",
"failed",
"skipped"
]
}
}
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10FAQ
What does qe chaos resilience do?
qe chaos resilience is a Claude Code skill for ai & agent building.
When should I use qe chaos resilience?
When you need to helps with ai & agent building tasks., or when qe chaos resilience is a claude code skill for ai & agent building.
What are the main capabilities?
qe chaos resilience; AI & Agent Building; AI-coding skill.
AI & Agent Buildingagents