01
Register the marketplace
A marketplace is just a Git repo with a .claude-plugin/marketplace.json manifest. Claude Code clones it and reads the plugins it declares.
$claude plugin marketplace add lucciii33/OliviaIA-skillsClaude Code plugin · olivia-tools v1.0.0
Your API docs in. A regression suite that finds real bugs out.
Two Claude Code skills that read your API documentation, build a high-coverage Postman collection, run it for real, and hand you bug tickets with minimal repros. Not one request per endpoint — the kind of coverage that fails loudly when someone changes behavior.
$claude plugin marketplace add lucciii33/OliviaIA-skills$claude plugin install olivia-tools@olivia-skils2 skills3 deliverables per runPostman v2.1 + Newman
Install
Three commands, and it is part of your workflow.
Plugins come from marketplaces, so registering the source and installing the plugin are two separate steps. After that you call the skills like any other slash command.
02
Install the plugin
The syntax is plugin@marketplace. Add --scope project to commit it into your repo's .claude/settings.json so the whole team gets it.
$claude plugin install olivia-tools@olivia-skils03
Call it with your API docs on hand
Point Claude at your spec — an OpenAPI file, a Markdown doc, a Postman export, or an Olivia-generated doc page. That is the only input it needs.
$/olivia-tools:apiRepository access. The marketplace clones lucciii33/OliviaIA-skills. While that repo is private, only accounts with access can install — make it public, or invite the people who need it.
What you get
Two skills, designed to chain.
Calling /olivia-tools:api runs the whole pipeline — it hands off to the bugs skill as its final step. Call the bugs skill on its own only when the run already happened.
/olivia-tools:apiBuild, run, and label the regression suite
Reads your API docs end to end, writes down every endpoint, method, param, enum and documented error shape, then turns that inventory into a runnable Postman collection and executes it with Newman.
- One folder per endpoint, saved under APITest/olivia/
- Every validation is its own pm.test() — never bundled assertions
- Runs through Newman and reports real pass/fail counts
- Labels findings BUG or DOCS-MISMATCH only after a real run
/olivia-tools:bugsTurn confirmed failures into tickets
Takes the confirmed findings and produces two things: a minimal repro collection and a Markdown ticket file a developer can act on without ever opening Postman.
- Minimal repros — only the headers, params and fields that trigger the bug
- Assertions written against correct behavior, so they pass once it is fixed
- Fixed ticket structure: Summary, Steps, Happening, Should Happen, Evidence, Impact
- Ordered by impact — data exposure and access control first
How a run goes
Docs in, tickets out — five stages.
Inventory
Reads the docs completely before writing anything. Every endpoint, param, enum, nullable field and error shape becomes a coverage matrix.
Scaffold
Builds the collection skeleton under APITest/olivia/, one folder per endpoint, with collection-level helper scripts already wired up.
Run
Executes through Newman. Credentials live only in a private temporary environment and the persisted report comes out redacted.
Label
Marks BUG for wrong API behavior and DOCS-MISMATCH for implementation that drifted from the docs — only for behavior observed in the run.
Report
Hands off to the bugs skill, which writes the repro collection and the ticket file, then closes with a coverage and gaps summary.
Coverage floor
Every applicable line, on every endpoint.
This is the checklist the api skill works through per endpoint — not a menu it picks from.
Happy paths
The baseline, plus one per meaningful parameter combination.
Missing fields
One request per required field omitted, and one per required param omitted.
Invalid input
Wrong type, invalid enum, and out-of-range value for every field.
Auth
No auth, malformed auth, expired token, and wrong-tenant token.
Boundaries
Lengths, limits, page sizes, offsets, dates and ID formats — at the boundary, one below, one above.
Filters & pagination
Sorting, paging, empty result sets, and unknown IDs.
Schema conformance
Full response-shape checks, plus cross-field consistency.
Bug hunters
Mass assignment, param abuse, unicode and oversized strings, number coercion, malformed bodies, IDOR, double-delete.
The bar, stated plainly: if your docs describe 8 endpoints, expect on the order of 15 to 30 requests per endpoint — not 8 requests total. A short or shallow collection is treated as a failed deliverable.
Why this is different
Anyone can generate requests. Finding bugs is the hard part.
The coverage floor is a promise, not a suggestion
Most generators give you one request per endpoint and call it a test suite. This one treats a shallow collection as a failed deliverable: if your docs describe 8 endpoints, expect 15 to 30 requests per endpoint, not 8 in total.
Adversarial requests are the point
Happy paths only prove the endpoint matches its docs. The bug-hunter section is what actually surfaces defects — mass assignment, IDOR, coercion — and the skill budgets real time for it instead of padding the count with 200s.
It catches what existence checks miss
Every 2xx test asserts there are no undocumented fields in the payload, because an added field can leak data or break consumers. Lengths are asserted explicitly too — array lengths against pagination metadata, string lengths against documented maximums — so silent truncation cannot slip through.
Nothing is reported unless it was observed
Findings get labelled only after the behavior shows up in an actual run. Nothing inferred from the docs and nothing guessed from the code enters the tickets; unverified observations go in the summary as “needs verification” instead.
Bug reports double as acceptance tests
Repro assertions are written against the correct behavior, so they fail while the bug exists and pass the moment it is fixed. Your bug report is the regression test for the fix — no extra work.
Tickets a human actually wants to read
Short sentences, plain words, no speculation about root cause, 150 to 250 words each. The same broken behavior across five endpoints is one ticket listing five endpoints, not five near-identical tickets.
What lands in your repo
APITest/olivia/<area>.postman_collection.jsonFull regression collection
APITest/olivia/<area>-bugs.postman_collection.jsonMinimal repros for confirmed bugs
APITest/olivia/<area>-tickets.mdOne actionable ticket per finding
Plus a written summary: what was covered, what was run, pass and fail counts, and any data or coverage gap it could not close.
Safety rails, built in
The skills run real requests against real systems with real credentials, so the boundaries are explicit:
- Asks permission before reading any .env file, and never asks you to paste a secret into chat.
- Never sources a dotenv file as shell code, and never invents IDs — they are discovered through safe list requests.
- Refuses to run against a production-looking URL without explicit confirmation.
- Asks before installing anything, including Newman itself.
- Credentials are injected into a temporary environment and stripped from the saved report.
Questions
Before you install.
Do I have to call the bugs skill separately?
No. The api skill hands off to it as its final step, so a single call gives you the collection, the run results, the repro collection and the ticket file. Call /olivia-tools:bugs on its own when you already ran the suite in an earlier session and only want the write-up.
What if the run finds nothing?
Then there is no ticket file. The bugs skill only accepts findings confirmed in a real run, so a clean suite gives you the collection plus a summary — which is exactly the outcome you want.
Does it work for APIs outside the Olivia suite?
Yes. The workflow is written around Olivia endpoints, but nothing in the coverage matrix or the script standards is Olivia-specific. Any documented HTTP API works.
Which Claude Code version do I need?
Any version with plugin support. Run claude plugin list to confirm the plugin is installed and enabled; if /plugin is unavailable in your environment, the claude plugin CLI does the same job.
How do I get updates?
Run claude plugin marketplace update olivia-skils. The marketplace tracks the remote repo, so changes have to be pushed before an update picks them up.
Works alongside the rest of Olivia
Point it at your docs and see what breaks.
Generate the docs in Olivia, then let the skills turn them into a regression suite that catches the next silent behavior change.