agentsclimarketplace

Generation

Skill jovd83/restassured-skill/coverage_plan/generation

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 generation

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 needs to generate a Rest Assured API test coverage plan from approved requirements, OpenAPI or Swagger contracts, WSDL analysis, and explicit scope constraints.

SKILL.md

4.0 KB, as published. Nobody here has run it

Generate Coverage Plan

1. Confirm Inputs

  1. Require approved requirements, approved contract analysis, or both.
  2. List the in-scope features, endpoints, roles, and environments.
  3. List the excluded scope explicitly.
  4. Capture any explicit priority order for OpenAPI tags, business domains, or endpoint groups before ordering the matrix.

2. Build The Scenario Matrix

  1. Create happy-path scenarios.
  2. Create validation scenarios for required fields, formats, ranges, enums, and body shape.
  3. Create authentication and authorization scenarios.
  4. Create negative and error-response scenarios.
  5. Create workflow and state-transition scenarios.
  6. Create integration or virtualization scenarios when dependencies matter.
  7. Create a dedicated contract-mismatch section whenever a live environment already exists or historical drift is known.
  8. When the contract uses tags, group the scenario matrix by tag unless the user asked for a different grouping.
  9. Order tag groups by explicit user priority first, then by business criticality, then by contract breadth.

3. Add Traceability

  1. Map each scenario to its requirement ID, contract path, or WSDL operation.
  2. Keep one row per scenario.
  3. Mark the intended execution type, for example smoke, regression, contract, or integration.
  4. Mark mismatch rows explicitly as Contract mismatch instead of hiding them inside generic negative coverage.
  5. Keep the tag or domain group visible in each row when tag-based prioritization is active.

4. Output

  1. Output a human-readable matrix.
  2. Start from coverage-matrix-template.md when the user has not specified a different format.
  3. Keep the columns stable so later sync and reporting work can reuse the matrix.
  4. Hand the matrix to dispatcher intent review_api_test_coverage_plan for explicit approval.
  5. If mismatch scenarios exist, send the approved mismatch rows to ../../documentation/contract-mismatches/SKILL.md.

If dispatcher routing is unavailable, use ../review/SKILL.md for approval.

5. Examples

  1. Input: Generate coverage for Orders from AUTH-US02 and openapi/orders.yaml. Output: A matrix that merges story coverage with contract-derived validations and errors.
  2. Input: Generate coverage for the live Petstore API and capture known drift from OpenAPI. Output: A matrix with separate happy-path, negative, and contract-mismatch rows.
  3. Input: Generate coverage for the billing API, but prioritize the Payments and Refunds tags first. Output: A matrix grouped by tag with Payments and Refunds ordered ahead of the remaining tag groups.

6. Troubleshooting

  1. Problem: The contract contains endpoints outside the user scope. Fix: Exclude them explicitly instead of silently dropping them.
  2. Problem: The live API already behaves differently from the contract. Fix: Add dedicated Contract mismatch rows and keep them traceable to both the contract path and the observed runtime evidence.
  3. Problem: The contract has many tags and the matrix becomes noisy. Fix: Keep only in-scope tags, order them explicitly, and group rows under the surviving tag headings.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.