Orchestrator

Skill jovd83/restassured-skill/orchestrator

Rest Assured skill pack for designing, implementing, documenting, and reporting API tests in Java and CI workflows.

Install

npx -y skills add jovd83/restassured-skill --skill orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when Codex receives a generic Rest Assured or service-testing request and must route the work into planning, implementation, documentation, execution, CI, virtualization, or test-management flows.

SKILL.md

4.7 KB, 937 tokens by cl100k_base, as published. Nobody here has run it

Rest Assured Orchestrator

1. Clarify the Goal

Ask for the primary goal if the user request is ambiguous.
Classify the request into one of these buckets:
1. Bootstrap a test module.
2. Analyze requirements.
3. Analyze OpenAPI or Swagger contracts.
4. Analyze WSDL or SOAP contracts.
5. Generate or review coverage.
6. Implement or fix tests.
7. Stub or virtualize downstream services.
8. Configure CI.
9. Document tests, traceability, quality, or failures.
10. Regenerate a bundled reporting set.
11. Transform, map, or report results to a test-management tool.

2. Route

Use ../bootstrap/SKILL.md for missing setup.
Use ../analysis/requirements/SKILL.md for stories, epics, and acceptance criteria.
Use ../analysis/contracts/SKILL.md for REST contracts.
Use ../analysis/contracts-soap/SKILL.md for SOAP contracts.
Use ../coverage_plan/generation/SKILL.md for scenario generation.
Use ../coverage_plan/review/SKILL.md for explicit approval.
Use ../core/SKILL.md for implementation and defect fixing.
Use ../virtualization/SKILL.md for WireMock and fault injection.
Use ../ci/SKILL.md for pipeline work.
Use ../documentation/report-bundle/SKILL.md when the goal is to refresh the reporting set as one operation.
Use ../documentation/*/SKILL.md for documentation and diagnosis that is not test-case formatting.
Dispatch render_test_artifact through skill-dispatcher for test-case formatting and export artifacts. Use C:\projects\skills\test-artifact-export-skill\SKILL.md only as a compatibility fallback.
Use ../mappers or ../reporters for external execution tools.
When routing into test-case documentation, treat docs/tests/<feature>/ as the canonical home for scenario-level docs and treat docs/testing/ as index and reporting space.

3. Enforce the Sequence

Require approved requirements before generating a coverage plan.
Require an approved coverage plan before large-scale test implementation when the scenarios are AI-defined.
Skip approval only when the user already supplied the test cases or explicitly asked for direct implementation.
When the user asks for narrative documentation but not a format, choose TDD, BDD, plain text, or mixed mode explicitly before writing files.

4. Read When Needed

Read routing-matrix.md for trigger phrases and routing shortcuts.

5. Examples

Input: Help me test this payments service. Output: Ask whether the goal is setup, planning, implementation, CI, documentation, or reporting.
Input: Create scenarios from this OpenAPI and then implement them. Output: Route to contracts analysis, coverage generation, review, then core.
Input: Rebuild the coverage and quality reports for this API module. Output: Route to ../documentation/report-bundle/SKILL.md.
Input: Check whether the narrative docs still match the API tests. Output: Route to ../documentation/documentation-sync/SKILL.md.
Input: Document these approved payment scenarios, but keep each scenario separate. Output: Route to dispatcher intent render_test_artifact and store the canonical files under docs/tests/payments/.

6. Troubleshooting

Problem: The user mixes setup and implementation. Fix: Complete bootstrap first, then move into core.
Problem: The user asks for implementation without requirements or contracts. Fix: Proceed only if the requested tests are already enumerated or narrow enough to infer safely.
Problem: Documentation requests default to one oversized markdown file. Fix: Split TDD and plain-text docs into one scenario file per behavior and use feature files only where BDD grouping adds value.
Problem: The target exporter skill changes or is temporarily unavailable. Fix: Go through skill-dispatcher first and treat the direct exporter path as fallback only.

Gives 0 of the 12 instructions most test skills give in 937 tokens

Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-06

close the browser when donein 55 of 964, across 12 files
wait for network idle statein 51 of 964, across 6 files
launch chromium in headless modein 49 of 964, across 6 files
use descriptive selectors for elementsin 49 of 964, across 6 files
run provided scripts with help flag firstin 49 of 964, across 6 files
add appropriate explicit waitsin 48 of 964, across 5 files
use bundled scripts as black boxesin 46 of 964, across 3 files
do not read script source codein 46 of 964, across 3 files
use sync playwright for scriptsin 46 of 964, across 3 files
inspect dom before executing actionsin 46 of 964, across 3 files
run the full test suitein 36 of 964, across 34 files
write the failing test firstin 25 of 964, across 18 files

Said here and by no other author read

ask for the primary goal if ambiguous
classify the request into one bucket
route each bucket to its skill
dispatch render_test_artifact for formatting
use docs/tests/feature/ for scenario docs
use docs/testing/ for index and reporting

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.