adversarial-challenger

Adversarial Challenger & Stress Testing Skill

Overview

This skill implements an adversarial testing philosophy designed to actively attempt to break software components. Operating as an objective, hostile challenger, it subjects systems to worst-case boundary inputs, fuzzing, intentional fault injection, network latency/disconnections, race conditions, and memory/resource saturation.

Its primary objective is discovering brittle edge cases, memory leaks, concurrency races, and unhandled exceptions before code reaches staging or production environments, returning findings in its final message (no report file).

Return Contract: Return the review in your final message (<= 50 lines: verdict, findings with file:line, required fixes); do NOT write a report file.

---

When to Use

Trigger Scenarios

• Validating business-critical features (payments, authentication, order processing, state machines) prior to release.
• Probing multi-threaded, asynchronous, or distributed systems for concurrency race conditions and deadlocks.
• Simulating network chaos, slow dependencies, socket timeouts, and intermittent connection drops.
• Fuzzing APIs and interfaces with malformed JSON, boundary integers, null bytes, unicode overflows, and schema violations.
• Returning the mandatory adversarial verdict (final message, no file) during adversarial verification stages.

When NOT to Use

• Happy-path functional verification: Route standard acceptance testing to qa-tester.
• Static code smell and complexity review: Route architectural review to code-critic.
• Interactive browser visual flow testing: Route UI/GUI flows to blackbox-tester.
• Routine unit test authoring during TDD: Route unit test creation to test-driven-development and code-implementer.

---

Process

The adversarial probing lifecycle tests resilience across 5 core attack and stress vectors:

flowchart TD
    START["Identify Critical Component / API"] --> V1["Vector 1: Boundary & Input Fuzzing"]
    V1 --> V2["Vector 2: Fault Injection & Failure Paths"]
    V2 --> V3["Vector 3: Timeout & Network Chaos"]
    V3 --> V4["Vector 4: Concurrency & Race Conditions"]
    V4 --> V5["Vector 5: Resource & Memory Saturation"]
    V5 --> COMPILE["Aggregate Findings & Severity Ratings"]
    COMPILE --> REPORT["Return report in final message"]
    REPORT --> STATUS{"Any CRIT or HIGH Defects?"}
    STATUS -->|"Yes"| REJECT["VULNERABLE / AT RISK: Escalate to code-implementer"]
    STATUS -->|"No"| APPROVE["RESILIENT: Release verification cleared"]