contract-and-openapi
The contract is the deliverable. Express it as an **OpenAPI 3.1** document so it is human-readable *and* machine-checkable. This reference covers how to structure that document and what `scripts/lint-openapi.mjs` enforces.
$ npx -y skills add vanara-agents/skills --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
The contract is the deliverable. Express it as an **OpenAPI 3.1** document so it is human-readable *and* machine-checkable. This reference covers how to structure that document and what `scripts/lint-openapi.mjs` enforces.
Agent definition
contract-and-openapi.mdContract & OpenAPI
The contract is the deliverable. Express it as an **OpenAPI 3.1** document so it is human-readable *and* machine-checkable. This reference covers how to structure that document and what `scripts/lint-openapi.mjs` enforces.
Why OpenAPI
- It is the lingua franca: tooling generates client SDKs, mock servers, request validators, and docs
from it.
- It forces you to be explicit about every status code and schema — the things designers skip.
- It is diffable, so a reviewer can see exactly what a change adds or removes.
Minimum viable document
Every OpenAPI doc must have these top-level fields, or downstream tooling rejects it:
openapi: 3.1.0 # the spec version — required
info:
title: Orders API # required
version: "1.0.0" # required — the API version, not the spec version
paths: {} # required — the endpoints (may start empty but must exist)
components:
schemas: {} # reusable schemas referenced via $ref`scripts/lint-openapi.mjs` checks exactly these load-bearing fields on a doc supplied as **JSON** (no YAML parser dependency): `openapi` is present, `info.title` and `info.version` are non-empty strings, `paths` is an object, and every operation's responses carry at least a schema or description. Run it with `--selftest` to see it pass a valid doc and fail an invalid one.
Structure for reuse with `$ref`
Define each schema once under `components/schemas` and reference it. Define the **error envelope and common error responses once** and `$ref` them from every operation — this is how you guarantee the "one error shape everywhere" rule mechanically rather than by discipline.
components:
responses:
Error:
description: Standard error envelope
content:
application/json:
schema: { $ref: "#/components/schemas/ErrorEnvelope" }
schemas:
Order:
type: object
properties:
id: { type: string }
status: { type: string, enum: [open, paid, refunded] }
ErrorEnvelope:
type: object
properties:
data: { nullable: true }
error:
type: object
properties:
code: { type: string }
message: { type: string }
details: { type: array, items: { type: object } }
requestId: { type: string }What to specify per operation
For every operation:
- `summary` — one line.
- `parameters` — path, query (incl. `limit`/`cursor` for lists), and headers (`Idempotency-Key`).
- `requestBody` — schema for write operations, `required: true` where applicable.
- `responses` — **every** status code, success and failure, each with a schema or `$ref`.
- Auth via `security` referencing a `securityScheme`.
Checklist before emitting
- [ ] Top-level required fields present (`openapi`, `info.title`, `info.version`, `paths`).
- [ ] Shared schemas and error responses defined once and `$ref`-ed.
- [ ] Every operation documents both success and error responses.
- [ ] List operations declare `limit` + `cursor` (or `offset`) parameters.
- [ ] The doc passes `node scripts/lint-openapi.mjs <doc.json>`.
Read more
Contract & OpenAPI
The contract is the deliverable. Express it as an **OpenAPI 3.1** document so it is human-readable *and* machine-checkable. This reference covers how to structure that document and what `scripts/lint-openapi.mjs` enforces.
Why OpenAPI
- It is the lingua franca: tooling generates client SDKs, mock servers, request validators, and docs
from it.
- It forces you to be explicit about every status code and schema — the things designers skip.
- It is diffable, so a reviewer can see exactly what a change adds or removes.
Minimum viable document
Every OpenAPI doc must have these top-level fields, or downstream tooling rejects it:
openapi: 3.1.0 # the spec version — required
info:
title: Orders API # required
version: "1.0.0" # required — the API version, not the spec version
paths: {} # required — the endpoints (may start empty but must exist)
components:
schemas: {} # reusable schemas referenced via $ref`scripts/lint-openapi.mjs` checks exactly these load-bearing fields on a doc supplied as **JSON** (no YAML parser dependency): `openapi` is present, `info.title` and `info.version` are non-empty strings, `paths` is an object, and every operation's responses carry at least a schema or description. Run it with `--selftest` to see it pass a valid doc and fail an invalid one.
Structure for reuse with `$ref`
Define each schema once under `components/schemas` and reference it. Define the **error envelope and common error responses once** and `$ref` them from every operation — this is how you guarantee the "one error shape everywhere" rule mechanically rather than by discipline.
components:
responses:
Error:
description: Standard error envelope
content:
application/json:
schema: { $ref: "#/components/schemas/ErrorEnvelope" }
schemas:
Order:
type: object
properties:
id: { type: string }
status: { type: string, enum: [open, paid, refunded] }
ErrorEnvelope:
type: object
properties:
data: { nullable: true }
error:
type: object
properties:
code: { type: string }
message: { type: string }
details: { type: array, items: { type: object } }
requestId: { type: string }What to specify per operation
For every operation:
- `summary` — one line.
- `parameters` — path, query (incl. `limit`/`cursor` for lists), and headers (`Idempotency-Key`).
- `requestBody` — schema for write operations, `required: true` where applicable.
- `responses` — **every** status code, success and failure, each with a schema or `$ref`.
- Auth via `security` referencing a `securityScheme`.
Checklist before emitting
- [ ] Top-level required fields present (`openapi`, `info.title`, `info.version`, `paths`).
- [ ] Shared schemas and error responses defined once and `$ref`-ed.
- [ ] Every operation documents both success and error responses.
- [ ] List operations declare `limit` + `cursor` (or `offset`) parameters.
- [ ] The doc passes `node scripts/lint-openapi.mjs <doc.json>`.
🐒 Free agents, skills & packs for Claude Code One subscription. An army of Claude Code agents. 30 production-grade agents, skills, and packs for Claude Code — free, Apache-2.0, install with one command.
Repo: vanara-agents/skills
Other agents on vanara-agents-skills.
- AGENT
Use when designing a new HTTP/GraphQL API or changing an existing one — modeling resources, defining endpoint contracts, choosing status codes, pagination, filtering, error envelopes, versioning, and idempotency. Produces a reviewable API contract plus an OpenAPI snippet, not
Open agent - review-notes
This shows how the api-designer agent reviews a flawed draft. Findings are severity-ranked so the implementer fixes the contract-breakers first. Severity legend: **CRITICAL** (breaks clients / data risk), **HIGH** (real bug or inconsistency), **MEDIUM** (maintainability),
Open agent - design-checklist
Run through this before declaring an API contract done. It is ordered the way you should *design*: resources first, cross-cutting rules last. Every box is a place real APIs go wrong in production.
Open agent - versioning-and-evolution
APIs are forever once published: a consumer you've never met may depend on any field you expose. Design so you can **add without breaking**, and version explicitly when you must break.
Open agent - pr-comment-template
Copy-paste templates for leaving review comments. Keep each comment to one finding: an anchor, the problem, and the fix.
Open agent - sample-review-output
A complete review of a hypothetical PR, in the standard format. Use this as the model for tone, structure, and the anchor → problem → fix pattern.
Open agent

