brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
postman-openapi-converterConvert OpenAPI 3.x or Swagger 2.0 specs (YAML or JSON) into complete, import-ready Postman Collection v2.1 JSON files. Use this skill whenever the user provides or references an OpenAPI spec, Swagger file, openapi.yaml, swagger.json, or uses phrases like "convert my OpenAPI spec", "import swagger to Postman", "turn this spec into a collection", or "generat…
Independent GitHub snapshot · Automated classification · Original documentation governs
name: postman-openapi-converter
description: >
Convert OpenAPI 3.x or Swagger 2.0 specs (YAML or JSON) into complete, import-ready
Postman Collection v2.1 JSON files. Use this skill whenever the user provides or
references an OpenAPI spec, Swagger file, openapi.yaml, swagger.json, or uses phrases
like "convert my OpenAPI spec", "import swagger to Postman", "turn this spec into a
collection", or "generate Postman requests from my API spec". Also triggers when the
user pastes YAML or JSON that begins with openapi:, swagger:, or contains paths:
with HTTP method keys. Always prefer this skill over the general collection generator
when the input is a structured spec file.
languages:
Converts OpenAPI 3.x or Swagger 2.0 specs into a valid Postman Collection v2.1.
Identify the spec version from the input:
openapi: 3.x.x → OpenAPI 3swagger: "2.0" → Swagger 2If the input is truncated or partial, convert what's available and note missing sections.
| OpenAPI field | Postman mapping |
|---|---|
info.title | Collection name |
info.description | Collection description |
servers[0].url | {{base_url}} variable |
paths.<path>.<method> | One request item per operation |
operationId or summary | Request name |
parameters (path/query/header) | URL path variables, query params, headers |
requestBody.content.application/json.schema | Body (raw JSON), generate example from schema |
responses | Saved example responses |
components.securitySchemes | Collection-level auth |
tags | Folder grouping |
| Swagger field | Postman mapping |
|---|---|
host + basePath | {{base_url}} |
paths.<path>.<method> | Request item |
parameters | Query/path/header/body params |
consumes / produces | Content-Type / Accept headers |
securityDefinitions | Collection auth |
tags | Folders |
For each request with a requestBody or body parameter, generate a realistic example JSON body from the schema:
"email" format → "user@example.com", "date-time" → "2024-01-15T10:30:00Z")$ref schemas, resolve them inlineMap security schemes to Postman auth:
| OpenAPI scheme | Postman auth type |
|---|---|
http: bearer | bearer with {{token}} |
http: basic | basic with {{username}} / {{password}} |
apiKey: header | apikey header with {{api_key}} |
apiKey: query | apikey query param |
oauth2 | oauth2 (note: requires manual token setup) |
Apply auth at collection level if all endpoints share the same scheme. Override at request level for exceptions.
Use the standard v2.1 structure (same schema as postman-collection-generator skill).
Key differences for spec-converted collections:
tags into foldersdescription field on each request from operationId + summary + descriptionresponses are defined in the spec"response": [
{
"name": "200 OK",
"status": "OK",
"code": 200,
"header": [{ "key": "Content-Type", "value": "application/json" }],
"body": "{ \"id\": 1, \"name\": \"example\" }",
"originalRequest": { <copy of the request> }
}
]
Extract all variables into a companion environment:
base_url from servers[0].url or host + basePathtoken, api_key, username, password as empty placeholdersservers[0].variablescollection.json — Full Postman Collection v2.1environment.json — Matching environment file$ref chains: Resolve all $ref pointers inline before mappingallOf / oneOf / anyOf: Use the first/primary schema for body generation; note alternatives in description{param} to :param in URL path AND add to variable array in url objectapplication/json; note others in request descriptionMETHOD /path (e.g., GET /users/{id} → Get User by ID)paths entry produces at least one request:param format in Postman URL$ref resolved — no raw $ref strings in output{{variables}}, never hardcodedOnce the API design output is delivered, ask the user:
"Would you like me to generate API documentation for this design? (yes/no)"
If the user says yes:
If the user says no: