wicked-testing-review

name	wicked-testing-review
description	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".
argument-hint	[run-id | path] [--spec <path>] [--focus semantic|quality|testability]

wicked-testing:review

Reviewing is its own discipline. This skill is the place where verdicts are rendered — not inside the executor, not as a side effect of running.

Usage

/wicked-testing:review [run-id | path] [--spec <path>] [--focus <area>]

Arguments map onto the dispatch table below:

• run-id — review a specific recorded run: acceptance-test-reviewer over the run's evidence manifest
• path — review a source tree or test directory
• --spec <path> — supplies the acceptance criteria / spec document
• --focus semantic — spec-to-code alignment: semantic-reviewer Gap Report
• --focus quality — test quality audit: code-analyzer + the test-code-quality Tier-2 specialist
• --focus testability — code testability review: code-analyzer static review

When to use

• A run just finished and needs an independent verdict
• Post-implementation: does the code actually match the spec?
• The test suite itself needs a quality pass
• A code review needs a testability-focused perspective

How it dispatches

Input	Dispatch
A run's evidence manifest	wicked-testing:acceptance-test-reviewer
Spec + implementation (post-code divergence)	wicked-testing:semantic-reviewer
Test suite path	wicked-testing:code-analyzer + Tier-2
Production metrics, post-deploy	wicked-testing:production-quality-engineer

Dispatch block (executable)

Every id in the tables above is a forked worker skill (context: fork) — invoke it with the Skill tool so it runs in an isolated context. For the reviewer this is isolation-critical: the forked context is what guarantees it never sees the executor's history.

Skill(
  skill="wicked-testing:acceptance-test-reviewer",
  args="""Review the evidence manifest at the path below and render an
independent verdict.

## Evidence Directory
.wicked-testing/evidence/{RUN_ID}/

## Scenario Path
{path — read it yourself}

## Instructions
1. Read the scenario file.
2. Read the test plan from the evidence dir.
3. Read evidence files in the evidence dir (step-N.json, artifacts, optional
   context.md). Do NOT use any other context — you never saw the execution.
4. For each assertion, evaluate evidence → verdict (PASS / FAIL / INCONCLUSIVE).
5. If context.md is present, treat it as pre-vetted cold knowledge. If it
   contains a prior verdict, run_id, historical counts, or executor
   reasoning, flag as CONTEXT_CONTAMINATION and return INCONCLUSIVE.

Return the verdict, reasoning per assertion, and next actions.
DO NOT reference executor conversation context beyond the files above."""
)

For a spec-vs-code divergence review, swap the skill id to wicked-testing:semantic-reviewer and pass the spec path + implementation path. For a standalone test-suite quality review (no run, just the source), dispatch code-analyzer + the relevant Tier-2 specialist from the table below.

Independence

Reviewers work from evidence and spec, not from the executor's story. acceptance-test-reviewer is isolated (Read-only tools, context: fork forked invocation, scrubbed context.md via lib/context-md-validator.mjs) to keep its verdict honest. Do not pre-narrate what it should find.

Tier-2 specialists this skill routes to

For domain-specific reviews, dispatch the specialist. Each returns a verdict or a list of findings the skill folds into the review output:

Trigger	Specialist
"Is this test suite effective?" (mutation kill rate)	wicked-testing:mutation-test-engineer
"Did this suite exercise WCAG surfaces?"	wicked-testing:a11y-test-engineer
Translated-copy review (pseudoloc, RTL, pluralization)	wicked-testing:localization-test-engineer
Observability-assertion review (logs / traces / PII)	wicked-testing:observability-test-engineer
Flake detection for a scenario's history	wicked-testing:flaky-test-hunter
Untested-path audit	wicked-testing:coverage-archaeologist
"Does this meet contract?" (Pact / OpenAPI)	wicked-testing:contract-testing-engineer
Audit test-suite quality (smells, dead tests)	wicked-testing:test-code-quality-auditor
Audit snapshot hygiene (stale, over-broad, dead)	wicked-testing:snapshot-hygiene-auditor
Release gate — GO / CONDITIONAL / NO-GO	wicked-testing:release-readiness-engineer
Compliance evidence review (SOC2 / HIPAA / GDPR)	wicked-testing:compliance-test-engineer

Verdict semantics

• PASS — evidence + spec agree, tests exercise what was changed
• FAIL — assertion unsatisfied, evidence contradicts, or spec-code divergence
• N-A — reviewable item doesn't apply (must be justified)
• SKIP — applicable but deferred (ticket required)
• CONDITIONAL — approve with listed fixes before ship
• INCONCLUSIVE — evidence missing OR context contaminated

Output

• Verdict + reason
• Evidence citations (file paths, line numbers, AC IDs)
• Next actions: specific, assignable, bounded

Emits wicked.test.verdict.created on the bus when present.

References

• docs/INTEGRATION.md
• docs/EVIDENCE.md
• skills/acceptance-test-reviewer/SKILL.md, skills/semantic-reviewer/SKILL.md, skills/code-analyzer/SKILL.md, skills/production-quality-engineer/SKILL.md