wicked-testing-plan

Estrelas0

Forks0

Atualizado12 de julho de 2026 às 22:44

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

mikeparcewski

mikeparcewski/wicked-testing

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

Mais deste repositório

mesmo repositório

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-plan
description	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".
argument-hint	[target] [--project <name>] [--json]

wicked-testing:plan

One skill for everything before tests get written. Figures out what to test, what can go wrong, and whether the design lets you test at all.

Usage

/wicked-testing:plan [target] [--project <name>] [--json]

target — file path, directory, or feature description (optional; defaults to current dir)
--project <name> — associate strategy with this project
--json — emit JSON envelope

Preflight: check config

Verify .wicked-testing/config.json exists. If not:

Config not found. Run wicked-testing:setup first.
Code: ERR_NO_CONFIG

When to use

Before the build phase of a feature
When a PR's scope is unclear and you need to know what to test
When acceptance criteria were just drafted (requirements-quality gate)
When a design doc is ready but no code exists yet (testability gate)

How it dispatches

Read the target first, then route:

Target	Dispatch
Acceptance criteria / clarify doc	`wicked-testing:requirements-quality-analyst`
Design doc / architecture sketch	`wicked-testing:testability-reviewer`
Feature description / user story	`wicked-testing:test-strategist`
Known-risky change (security, data, perf)	`wicked-testing:risk-assessor`
"Test everything" / broad review	All four in parallel; merge findings

When multiple apply, dispatch in parallel. Merge results in the reply — no unrelated raw outputs dumped in.

Never dispatch test-strategist directly — always enter planning through this skill so the 4-way router above (strategist / risk / testability / AC-quality) runs. Calling test-strategist directly bypasses the router (wave-6 audit fix #63).

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:

Skill(
  skill="wicked-testing:test-strategist",
  args="""Generate a comprehensive test strategy for the target below.

## Target
{file path, directory, or feature description}

## Instructions
1. Classify the change type (UI, API, both, data, config).
2. Analyze the surface area (public APIs, functions, endpoints).
3. Generate positive + negative scenario pairs for every feature.
4. Identify risk areas and confidence level.
5. Flag any specification gaps discovered.

**MANDATORY**: Every scenario must have BOTH positive AND negative counterpart.
Return findings in the standard test-strategist format."""
)

Swap the skill id to the matching worker from the table above. For the "test everything" path, dispatch all four in parallel (one Skill(...) call per worker in the same turn) and merge the returned findings.

Tier-2 specialists this skill may pull in

For domain-specific planning signals, dispatch a specialist and fold its output into the strategy document. These don't render verdicts — they add risk+scenario coverage where the generalist agents would miss signal:

Trigger (anything in the target that matches)	Specialist
React/Vue/Svelte component under test	`wicked-testing:ui-component-test-engineer`
API / service boundary (REST, gRPC, GraphQL)	`wicked-testing:integration-test-engineer`
Database migration or schema change	`wicked-testing:data-quality-tester`
Performance-sensitive path (heavy compute, I/O)	`wicked-testing:load-performance-engineer`
Multi-step user journey	`wicked-testing:e2e-orchestrator`
UI with visual regressions risk (CSS, theming)	`wicked-testing:visual-regression-engineer`
User-facing surface (WCAG 2.1 AA relevance)	`wicked-testing:a11y-test-engineer`
Parser / serializer / round-trip / invariants	`wicked-testing:fuzz-property-engineer`
Translated / RTL / pluralization-sensitive copy	`wicked-testing:localization-test-engineer`
Service with logs / metrics / traces / PII-in-signals	`wicked-testing:observability-test-engineer`
Test-suite effectiveness evaluation (kill rate)	`wicked-testing:mutation-test-engineer`
Failure-mode / resilience planning	`wicked-testing:chaos-test-engineer`
Application-security scope (SAST/DAST/authz)	`wicked-testing:security-test-engineer`
LLM / AI feature in the codebase	`wicked-testing:ai-feature-test-engineer`
Terraform / helm / k8s / IaC / policy-as-code	`wicked-testing:iac-test-engineer`
Regulated industry (SOC2 / HIPAA / GDPR / PCI)	`wicked-testing:compliance-test-engineer`
Test suite with snapshots (jest / syrupy / cassettes)	`wicked-testing:snapshot-hygiene-auditor`
Test-suite quality itself (smells, dead tests)	`wicked-testing:test-code-quality-auditor`
Prod incident -> regression scenario synthesis	`wicked-testing:incident-to-scenario-synthesizer`

Tier-2 names are internal — see docs/NAMESPACE.md. Consumers (wicked-garden) depend only on Tier-1 names.

Strategy record

The strategy is written to DomainStore by the dispatched agent via store.create('strategies', {...}), which also fires wicked.test.strategy.generated on the bus when present.

Output

A test strategy: scenarios (positive + negative), risk matrix, testability verdict, AC quality verdict
Concrete next actions: which scenarios to author next, which ACs to rewrite, which design changes unblock testing
A pointer to the ledger where this plan is recorded

Emits wicked.test.strategy.generated on the bus when present.

With --json — emit the JSON envelope (python3-with-python-fallback, cross-platform):

python3 -c "import json,sys; sys.stdout.write(json.dumps({'ok': True, 'data': {'strategy_id': '...', 'scenario_count': N, 'project': '...'}, 'meta': {'command': 'wicked-testing:plan', 'duration_ms': 0, 'schema_version': 1, 'store_mode': '...'}}))" 2>/dev/null || python -c "import json,sys; sys.stdout.write(json.dumps({'ok': True, 'data': {'strategy_id': '...', 'scenario_count': N, 'project': '...'}, 'meta': {'command': 'wicked-testing:plan', 'duration_ms': 0, 'schema_version': 1, 'store_mode': '...'}}))"

References

docs/INTEGRATION.md
docs/NAMESPACE.md
skills/test-strategist/SKILL.md, skills/risk-assessor/SKILL.md, skills/testability-reviewer/SKILL.md, skills/requirements-quality-analyst/SKILL.md