Review an OpenAPI specification
Reviews an OpenAPI document before publication and reports what blocks it, grouped by severity.
- What it does?
- Reviews an OpenAPI document before publication and reports what blocks it, grouped by severity.
- Name
- review-an-openapi-specification
- Organisation
- DAC
- Visibility
- Public
- Author
- rajivgandhi.c+pa@digitalapi.ai
- Updated
- Wed, 23 Sep 2026 - 22:48
- Inputs
- 0
Review an OpenAPI specification
Use this when someone asks you to review, critique or sanity-check an OpenAPI document before it is published to the marketplace.
Steps
- Read the whole document before commenting on any part of it. A path that looks wrong in isolation is often correct given a shared parameter or a security scheme declared elsewhere.
- Check that every operation has a summary, an operationId, and at least one documented response other than 200. Consumers generate clients from these.
- Check that error responses reference a shared schema rather than restating an ad hoc object per operation.
- Flag any endpoint that accepts a free-form object with no schema, and any that returns one.
- Check security: every operation either inherits the global security scheme
or declares its own. An operation with
security: []is public, and that is almost never intended. - Report findings grouped by severity, and say plainly which ones block publication and which are improvements.
What not to do
Do not rewrite the specification. Report what is wrong and why it matters to the person who will consume the API, and leave the authoring to its owner.
Raw markdown (SKILL.md)
# Review an OpenAPI specification Use this when someone asks you to review, critique or sanity-check an OpenAPI document before it is published to the marketplace. ## Steps 1. Read the whole document before commenting on any part of it. A path that looks wrong in isolation is often correct given a shared parameter or a security scheme declared elsewhere. 2. Check that every operation has a summary, an operationId, and at least one documented response other than 200. Consumers generate clients from these. 3. Check that error responses reference a shared schema rather than restating an ad hoc object per operation. 4. Flag any endpoint that accepts a free-form object with no schema, and any that returns one. 5. Check security: every operation either inherits the global security scheme or declares its own. An operation with `security: []` is public, and that is almost never intended. 6. Report findings grouped by severity, and say plainly which ones block publication and which are improvements. ## What not to do Do not rewrite the specification. Report what is wrong and why it matters to the person who will consume the API, and leave the authoring to its owner.
This skill declares no inputs. It works from whatever the conversation already contains.
--- name: review-an-openapi-specification description: 'Reviews an OpenAPI document before publication and reports what blocks it, grouped by severity.' --- # Review an OpenAPI specification Use this when someone asks you to review, critique or sanity-check an OpenAPI document before it is published to the marketplace. ## Steps 1. Read the whole document before commenting on any part of it. A path that looks wrong in isolation is often correct given a shared parameter or a security scheme declared elsewhere. 2. Check that every operation has a summary, an operationId, and at least one documented response other than 200. Consumers generate clients from these. 3. Check that error responses reference a shared schema rather than restating an ad hoc object per operation. 4. Flag any endpoint that accepts a free-form object with no schema, and any that returns one. 5. Check security: every operation either inherits the global security scheme or declares its own. An operation with `security: []` is public, and that is almost never intended. 6. Report findings grouped by severity, and say plainly which ones block publication and which are improvements. ## What not to do Do not rewrite the specification. Report what is wrong and why it matters to the person who will consume the API, and leave the authoring to its owner.
Try this skill in the playground
Run it against the portal's model with your own sample inputs and see what it answers, before you add it to an agent.