wicked-testing-review

星标0

分支0

更新时间2026年7月12日 22:44

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".

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

mikeparcewski

mikeparcewski/wicked-testing

打开 GitHub 仓库查看创作者相关仓库

下载

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

同仓库更多 Skills

同仓库

wicked-testing-acceptance-testing

mikeparcewski/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"

2026-07-130

wicked-vault-record-evidence

mikeparcewski/wicked-testing

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.

2026-07-130

wicked-testing-validate

mikeparcewski/wicked-testing

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.

2026-07-120

wicked-testing-a11y-test-engineer

mikeparcewski/wicked-testing

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>

2026-07-120

wicked-testing-acceptance-test-executor

mikeparcewski/wicked-testing

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>

2026-07-120

wicked-testing-acceptance-test-reviewer

mikeparcewski/wicked-testing

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>

2026-07-120

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)

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."""
)

Independence

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