wicked-testing

Evidence-gated acceptance testing with three-agent separation of concerns. Writer designs test plans, Executor collects artifacts, Reviewer evaluates independently. Eliminates false positives from self-grading. Use when: "acceptance test", "verify it works", "did it pass", "run acceptance", "test this scenario", "acceptance criteria", "validate the feature", "/wicked-testing:acceptance"

Record a claim-backing artifact in the vault and attach a deterministic verifier. Use when capturing evidence that "tests pass", "build clean", a commit exists, or a file's contents back a claim — and when replacing stale evidence via supersede. Covers --run vs --artifact, verifier syntax, and contract pinning.

Repo-local structural validator for wicked-testing. Checks skill frontmatter (including the tiered worker-skill contract: tier + context: fork), plugin.json reference integrity, namespace alignment, cross-platform shell portability, and evidence schema self-consistency. Zero LLM cost. Run before publishing or after structural changes. Use when: validating wicked-testing's own skills/plugin.json, pre-publish sanity check, after adding new skills to this repo.

Accessibility specialist — axe-core + pa11y, WCAG 2.1 AA / 2.2 AA, keyboard-only flows, focus-ring detection, prefers-reduced-motion, color contrast ≥ 4.5:1. Writes axe/pa11y JSON to the evidence dir, appends a verdict row to DomainStore, and defaults to a CONDITIONAL verdict because automated tools only catch ~30% of WCAG violations. Use when: a11y audit, WCAG compliance, keyboard-only flows, screen reader verification, color contrast, focus management, "is this page accessible". <example> Context: Reviewer wants a WCAG 2.1 AA check on a new checkout flow. user: "Run an accessibility pass on https://staging.example.com/checkout." <commentary>Use a11y-test-engineer — it runs axe-core + pa11y, writes axe-report.json + pa11y-report.json to the run's evidence dir, records a verdict row, and flags that manual keyboard review is still required.</commentary> </example>

Follows structured wicked-testing test plans step-by-step, collecting evidence artifacts. Executes and captures only — does not judge or grade pass/fail. Writes evidence files to .wicked-testing/evidence/{run-id}/. Use when: acceptance test execution, evidence collection, test plan execution <example> Context: Test plan is ready and needs to be executed step by step. user: "Execute the acceptance test plan for the file upload feature." <commentary>Use acceptance-test-executor for mechanical step execution and evidence capture without judging results.</commentary> </example>

Evaluates evidence artifacts against test plan assertions independently. CRITICAL ISOLATION: Receives ONLY evidence file paths. Never sees execution context. Catches semantic bugs that self-grading misses. Use when: acceptance test review, evidence evaluation, test verdict <example> Context: Executor produced evidence and it needs independent evaluation. user: "Review the evidence from the file upload acceptance tests and render a verdict." <commentary>Use acceptance-test-reviewer for independent, unbiased verdict on test evidence.</commentary> </example>

Reads wicked-testing acceptance scenarios and produces structured, evidence-gated test plans. Transforms qualitative criteria into concrete, verifiable artifact requirements. Use when: acceptance testing, test plan generation, scenario verification design <example> Context: New feature scenario needs a structured test plan. user: "Write an acceptance test plan for the 'user can export data as CSV' scenario." <commentary>Use acceptance-test-writer to produce structured, evidence-gated test plans from scenarios.</commentary> </example>

Tier-2 specialist — testing LLM-backed features. Prompt-injection probes (direct / indirect / payload-smuggling / multi-turn), jailbreak library (DAN, grandma, token-smuggling, base64), refusal-rate regression, hallucination drift against a caller-provided golden set, output-drift monitors (JSON-schema, token length, citation fidelity). Use when: LLM feature under test, prompt-injection review, jailbreak sweep, refusal-rate check, hallucination regression, RAG citation audit, "does this AI feature still behave after the prompt change". NOT THIS WHEN: - Post-deploy LLM cost/latency monitoring — use `production-quality-engineer` - Classical model-accuracy metrics (precision/recall on labelled data) — use `data-quality-tester` - Security bugs in the surrounding app (authz, secrets) — use `security-test-engineer`; AI-specific attack surface stays here <example> Context: Reviewer wants to verify a support-bot didn't regress after a system-prompt change. user: "Run the prompt-injection + refusal-rate suite a

Tier-1 orchestrator for producing tests. Writes scenario files, generates test code (unit / integration / E2E), creates fixtures and test data. The "make me tests" skill. Use when: "write tests", "generate test code", "author scenarios", "create a scenario file", "add fixtures", "test data setup", "automate this scenario", "/wicked-testing:authoring".

Chaos + resilience specialist — failure injection via Toxiproxy, tc, Chaos Mesh, or AWS FIS. Pre-registers a steady-state hypothesis, caps blast radius, writes a rollback plan, and records the experiment as a task + verdict in DomainStore. REFUSES to run against production targets unless the scenario's frontmatter carries `trust_level: production-authorized` AND a `change-ticket:` reference. Use when: resilience testing, chaos engineering, failure injection, game-day design, graceful-degradation verification, recovery drill, dependency-down simulation. <example> Context: Reviewer wants to prove the checkout service degrades gracefully when the payments API goes slow. user: "Run a chaos experiment: 800ms latency on the payments dependency, blast radius 10% of traffic, assert p95 stays under 2s." <commentary>Use chaos-test-engineer — it registers the hypothesis, wires Toxiproxy, writes a toxiproxy-timeline.json + metrics snapshots to the evidence dir, and records the experiment + rollback step in DomainStore.

Static code analysis for testability, quality, and maintainability. Reviews code structure, identifies test-coverage gaps, and flags risky areas. Use when: static analysis, code-quality metrics, testability assessment, maintainability review, coverage-gap identification. Runs on arbitrary source code, anytime — does not require a spec or an active build phase. NOT THIS WHEN: - Reviewing acceptance criteria for SMART+T (pre-code, no implementation yet) — use `requirements-quality-analyst` - Judging whether the implementation matches a spec (post-code divergence detection) — use `semantic-reviewer` - Rendering a full acceptance verdict (writer + reviewer + executor pipeline) — use `/wicked-testing:acceptance-testing`

Regulatory-control specialist — SOC 2 / HIPAA / GDPR / PCI-DSS evidence collection. Reads a `controls:` list from the scenario frontmatter, executes a deterministic evidence-gathering command per control, and emits an auditor-ready `control-evidence.md` + a control-coverage CSV matrix. Verdict tags each control as satisfied / unsatisfied / out-of-scope. Use when: SOC2 readiness run, HIPAA control mapping, GDPR Article-30 record-of-processing, PCI-DSS scope audit, "prove we have evidence for CC6.1", control-walk-through generation. <example> Context: An auditor asks for current evidence of SOC2 CC6.1 (logical access controls) and CC7.2 (change monitoring). user: "Run compliance check with controls: [SOC2-CC6.1, SOC2-CC7.2]. Produce auditor-ready evidence." <commentary>Use compliance-test-engineer — it executes the mapped evidence command per control, writes control-evidence.md + control- coverage-matrix.csv to evidence/, and records a verdict row with controls_satisfied[] populated.</commentary> </example>

API contract testing specialist. Designs and reviews consumer-driven contracts, Pact-style tests, OpenAPI contract verification, schema versioning, and breaking-change detection across service boundaries. Use when: API contract tests, CDC, Pact, OpenAPI verification, schema versioning, breaking-change detection, provider/consumer negotiation.

Find dark corners in legacy code — untested, unreferenced, or low-confidence paths. Prioritizes by risk using coverage + git history + call-graph. Use when: legacy code audit, coverage gap analysis, dark-code discovery, risk prioritization, test-debt assessment.

Data-quality specialist — schema drift, referential integrity, migration forward/rollback verification, great_expectations / dbt-test patterns. Use when: data quality checks, schema drift, migration testing, referential integrity, ETL validation, data contract enforcement.

Multi-service, multi-UI journey orchestration across environments. Coordinates a scenario that spans frontend + API + worker, manages environment, asserts end state. Use when: full-journey E2E, cross-service flows, multi-tab / multi-user coordination, Playwright / Cypress orchestration at scale.

Tier-1 orchestrator for running tests and capturing evidence. Executes scenarios, invokes framework runners, collects artifacts, and writes the run + verdict to the ledger. Use when: "run the test", "execute this scenario", "run the suite", "acceptance test this", "capture evidence", "prove it works", "/wicked-testing:execution".

Session-based, unscripted exploratory testing — the agent acts like a human tester. Charter-driven session, note-taking, bug hunting across UI and API. Use when: exploratory testing, unscripted session, charter-based bug hunting, heuristic-driven testing, fresh-eyes pass.

Flake detection + root-cause specialist. Queries DomainStore for historical verdicts per scenario_id, computes flake rate over a rolling 14d window, reproduces locally with repeat runs, and classifies the cause under a fixed taxonomy (timing / order-dep / env / resource / external-dep). Never proposes "add retry" as a fix. Quarantine is a last resort with a deadline. Use when: flaky tests, retry noise, quarantine review, intermittent failures, test-order dependencies, "this test passes locally but fails in CI". <example> Context: A scenario has mixed verdicts this week — some PASS, some FAIL, no code change. user: "The login-with-bad-creds scenario has flipped verdicts 4 times this sprint. Is it flaky?" <commentary>Use flaky-test-hunter — it queries verdicts for that scenario over 14d, computes the flake rate, reproduces with repeat runs, writes a flake-report.json, and records a root-cause task in DomainStore.</commentary> </example>

Property-based and fuzz testing — Hypothesis (Python), fast-check (TS), AFL/libFuzzer for native code. Finds inputs example tests never consider. Use when: property testing, fuzzing, adversarial input, parser / state machine verification.

Infrastructure-as-Code specialist — terraform validate/plan, checkov, tflint, tfsec, Rego/OPA (opa eval / conftest), Kyverno (kyverno-cli test), CloudFormation Guard (cfn-guard validate), Helm + kubeconform. Captures plan output as evidence, treats "plan-not-clean" as a verdict signal, and records policy conformance per-rule so reviewers can trace which control rejected which resource. Use when: terraform plan drift, k8s policy conformance, helm chart lint, "does this PR violate the SOC2/CIS baseline", IaC static analysis. <example> Context: A Terraform PR changes an RDS module; reviewer wants drift + policy signal before approval. user: "Run IaC checks on modules/rds — terraform plan, checkov, tflint. Flag any plan-not-clean output as a regression." <commentary>Use iac-test-engineer — it runs terraform validate/plan, checkov, and tflint; writes plan.bin + plan.json + policy reports to evidence/, classifies plan cleanliness, and records a verdict with the exact failing rule ids.</commentary> </example>

Turns a production incident into a deterministic scenario file that reproduces it. Takes an incident-report markdown OR direct fields (stack trace, endpoint URL, HTTP method, request body), extracts the minimal reproducer, writes `scenarios/<incident-id>.md` with `linked_to_incident:` frontmatter, emits `wicked.scenario.authored` with `source: incident`, and queues a review task under `assignee_skill: incident-to-scenario-synthesizer:review` so a human confirms before the scenario is marked active. Use when: postmortem follow-up, "write a regression test for INC-123", prod incident → scenario backport, error-class-to-test synthesis. <example> Context: Postmortem for INC-4829 (checkout 500 on coupon reuse) needs a regression scenario so the fix can be verified and future breaks caught. user: "Synthesize a scenario from docs/postmortems/INC-4829.md." <commentary>Use incident-to-scenario-synthesizer — it reads the postmortem, extracts stack + request + endpoint, writes scenarios/ INC-4829.md with status: pendi

Tier-1 orchestrator for reading the ledger. Stats, reports, flake detection, coverage gaps, historical queries. Never writes — only reads. Use when: "has this passed recently", "flake rate", "show me the last N runs", "coverage gaps", "generate a report", "stats", "exploratory session", "/wicked-testing:insight".

Real-service integration testing — distinct from contract testing. Spins up dependencies (DB, queue, cache) and asserts cross-component wiring. No mocks. Use when: multi-service wiring, database + app tests, queue + consumer tests, ephemeral environments, testcontainers, docker compose for tests.

Load + performance testing — k6, locust, hey. SLO validation, P95/P99 assertions, memory/CPU profile review. Use when: load tests, perf regression, SLO validation, capacity planning, throughput ceiling, response-time distribution.

i18n / localization testing — pluralization, RTL, date/currency formatting, missing strings, pseudolocalization. Use when: i18n audit, RTL layout, pluralization rules, locale-specific formatting, translation coverage, pseudolocalization.

Mutation-testing specialist — Stryker (JS/TS), Mutmut (Python), Pitest (Java), go-mutesting (Go). Runs a scoped mutation pass, parses the kill report, and writes a kill-rate summary + top surviving mutants with triage priority to the evidence dir. Records a verdict row that distinguishes "weak tests" (coverage present, assertions absent) from "missing tests" (no coverage). Explicitly warns that 100% kill rate may indicate redundant tests. Use when: mutation testing, test-effectiveness audit, "coverage is 90% but does the suite catch anything", kill-rate review, surviving-mutant triage. <example> Context: Reviewer wants to know if the pricing module's tests actually catch regressions. user: "Run mutation testing on src/pricing and report kill rate + top surviving mutants." <commentary>Use mutation-test-engineer — it picks Stryker based on the detected stack, scopes the run to src/pricing, writes stryker-report.json + kill-summary.md to evidence/, and records a verdict.</commentary> </example>

Assert that logs, metrics, and traces emit correctly. Verify structured log fields, OpenTelemetry span presence, metric cardinality. Use when: observability testing, log assertions, metric assertions, trace verification, OTel span coverage, cardinality audit.

Tier-1 orchestrator for test planning. Covers test strategy, risk, testability review, and requirements quality. Dispatches specialist agents based on what the target needs. Use when: "what should I test", "test strategy", "test plan", "risk matrix", "is this testable", "are these requirements testable", "coverage strategy", "shift-left testing", "/wicked-testing:plan".

Monitor production quality post-deploy. Track SLO targets, error budgets, performance regressions, and canary analysis. Define rollback criteria. Use when: post-deploy, production quality, SLO, error rate, canary, rollback criteria, performance regression.

Tier-2 specialist — aggregates ledger verdicts, open flakes, risk register, coverage delta, and prod SLO state into a single release-gate verdict: GO / CONDITIONAL / NO-GO with the specific blockers named. The "should we ship" question gets a crisp answer instead of five dashboards. Not a pipeline step — an aggregator. Use when: release readiness, ship decision, release gate, GO/NO-GO, "is this safe to ship", release sign-off, crew phase "cutover", PR ready-to-merge assessment when rigor matters. <example> Context: A release candidate is tagged; the team wants a single answer. user: "Are we ready to ship v2.4.0? Release window is tomorrow AM." <commentary>Use release-readiness-engineer — it queried the ledger for the last 7d of verdicts, cross-referenced open flakes, checked the risk register against the release SHA, compared coverage against the previous release, and returned CONDITIONAL: ship once two P1 flakes in the auth suite are quarantined.</commentary> </example>

Evaluate acceptance-criteria quality at the clarify phase. Check whether ACs are specific, measurable, testable. Flag ambiguous scope and missing edge cases. Use when: clarify-phase AC review, requirements-quality gate, SMART checks. Runs at the clarify gate — after ACs are drafted, before design begins. Pre-code only; no implementation is expected to exist yet. NOT THIS WHEN: - Post-implementation: checking whether code actually satisfies the ACs (spec-vs-code divergence) — use `semantic-reviewer` - Reviewing code structure, complexity, or testability signals — use `code-analyzer` - Rendering a full acceptance verdict against a running implementation — use `/wicked-testing:acceptance-testing`

Tier-1 orchestrator for judgment. Renders independent verdicts on captured evidence, checks spec-to-code alignment, audits test quality, and reviews code for testability signals. Use when: "review this", "judge the evidence", "verdict", "does the code match the spec", "is this test suite any good", "code review for testability", "/wicked-testing:review".

Identify failure modes, assess security/reliability/operational risks, and produce a risk matrix with mitigations. Use when: risk identification, failure-mode analysis, technical-risk review, mitigation planning before build.

Runs wicked-testing scenario files end-to-end. Reads scenario markdown, executes steps via Bash, and writes evidence JSON to .wicked-testing/evidence/{run-id}/. Handles bash commands and CLI tool invocations. Use when: scenario execution, test runner execution, step-by-step execution <example> Context: Running a test scenario to validate behavior. user: "Execute the login-positive scenario to validate the workflow end-to-end." <commentary>Use scenario-executor for full-capability scenario testing including bash execution.</commentary> </example>

Tier-2 specialist — application security testing. SAST orchestration (semgrep, CodeQL), DAST (ZAP, nuclei), secrets scanning (gitleaks, trufflehog, detect-secrets), authz/authn attack patterns (IDOR, role escalation, JWT validation, session fixation, CSRF), OWASP ASVS/WSTG alignment. Use when: security review, SAST scan, DAST scan, OWASP check, JWT/auth testing, secrets-in-repo scan, IDOR check, role escalation test, "is this endpoint secure", vulnerability assessment. NOT THIS WHEN: - Post-deploy production-security monitoring — use `production-quality-engineer` - Compliance-control evidence mapping (SOC2/HIPAA/GDPR) — use `compliance-test-engineer` - Threat-modeling design documents — use `testability-reviewer` - Secrets scanning in CI (GitGuardian, etc.) — keep that in CI; this agent runs the testable layer <example> Context: Reviewer wants a security pass on a new billing endpoint. user: "Run a security audit on https://staging.example.com/api/billing. Check for IDOR, JWT issues, and scan the repo for

Verify spec-to-code alignment after implementation. Extracts numbered acceptance criteria (AC-*, FR-*, REQ-*) from clarify artifacts and produces a Gap Report per item: aligned / divergent / missing. Use when: post-implementation verification, "does the code actually implement what we specified", divergence detection, review-phase gate. Requires both a spec and implementation to exist. NOT THIS WHEN: - Evaluating AC quality itself (SMART+T) before any code is written — use `requirements-quality-analyst` - General code-quality, complexity, or testability review without a spec — use `code-analyzer` - Rendering a full acceptance verdict (writer + reviewer + executor 3-agent pipeline) — use `/wicked-testing:acceptance-testing`

Tier-1 user-invokable entry point for per-project initialization. Initializes wicked-testing for the current project — detects available test CLI tools, creates `.wicked-testing/config.json`, and registers a project record in the DomainStore. Use when: "set up wicked-testing", "initialize testing for this project", "ERR_NO_CONFIG", "/wicked-testing:setup".

Snapshot-rot detector. Scans `__snapshots__/`, `*.snap`, `*.golden`, `cassettes/`, and `.syrupy` directories for four classes of rot: stale (>90d old AND still referenced), over-broad (full-DOM / full-JSON where a narrower assertion would do), rubber-stamped (baseline regenerated in the same commit that introduced the behavior change), and dead (file referenced by no active test). Outputs a ranked remediation list and defaults to a CONDITIONAL verdict with a top-N to re-review. Use when: snapshot audit, "our snap files are out of control", CI snapshot-update cleanup, reviewer fatigue triage, test-double rot check. <example> Context: The team has 3000+ snapshot files; most updates are rubber- stamped "accept new". user: "Audit our __snapshots__ and *.golden dirs — find dead ones and flag the ones that look rubber-stamped." <commentary>Use snapshot-hygiene-auditor — it walks the snapshot dirs, cross-references test files for referenced snapshots, inspects git log for rubber-stamp patterns, and writes snapshot

Generate test code and configure test automation infrastructure. Creates unit, integration, and end-to-end tests. Configures test runners, CI pipelines, coverage, and fixtures. Use when: test generation, automated tests, test code, test infrastructure, CI testing, coverage configuration. Generalist — detects framework and writes tests at any layer. NOT THIS WHEN: - Authoring UI / component-level tests (React/Vue/Svelte component rendering, props, events) — use `wicked-testing:ui-component-test-engineer` - Authoring cross-module integration tests (DB, message bus, service-to-service contracts) — use `wicked-testing:integration-test-engineer` - Orchestrating browser-driven end-to-end flows (Playwright/Cypress user journeys, multi-page scenarios) — use `wicked-testing:e2e-orchestrator` - Producing the scenarios themselves (not the code) — use `test-strategist` or `test-designer`