Convert OpenAPI specs to Postman collections

Converts an OpenAPI 3.x or Swagger 2.0 spec (YAML or JSON) into a valid, import-ready Postman Collection v2.1 - distinct from building a collection from a plain-English description, which is a companion skill. Step 1 detects the spec version from its openapi: 3.x.x or swagger: "2.0" marker, converting whatever is present and noting missing sections if the input is truncated. Step 2 applies a fixed field mapping per spec version: for OpenAPI 3, info.title/info.description become the collection name/description, servers[0].url becomes the {{base_url}} variable, each paths.<path>.<method> becomes one request item named from its operationId or summary, parameters map to path/query/header fields, requestBody schema becomes a generated raw JSON body, responses become saved example responses, components.securitySchemes becomes collection-level auth, and tags become folders; for Swagger 2, host+basePath form {{base_url}}, consumes/produces map to Content-Type/Accept headers, and securityDefinitions map to collection auth. Step 3 generates a realistic example JSON body for every request with a body schema, inferring sensible values from property type and format (an email-format field becomes "user@example.com", a date-time field becomes an ISO timestamp) and resolving $ref schemas inline. Step 4 maps each OpenAPI security scheme to its Postman auth equivalent - http: bearer to Postman's bearer auth with a {{token}} variable, http: basic to basic auth with {{username}}/{{password}}, apiKey in header or query to the matching Postman apikey type, and oauth2 to Postman's oauth2 type with a note that manual token setup is still required - applying it at the collection level when every endpoint shares the scheme, overriding per-request otherwise. Step 5 builds the standard v2.1 collection structure (same schema as the plain-language collection generator), but always groups requests into folders by tags and attaches saved example responses built from the spec's documented response bodies. Step 6 extracts a companion environment file with base_url plus empty placeholders for any detected token/api_key/username/password variables and any servers[0].variables. Named edge cases get explicit handling: resolving $ref chains fully before mapping, using the primary schema for allOf/oneOf/anyOf bodies while noting alternatives, converting {param} path syntax to Postman's :param format in both the URL and its variable array, preferring application/json when multiple content types exist, and synthesizing a request name from method and path (GET /users/{id} becomes "Get User by ID") when no operationId exists. A quality checklist before output confirms every path produces a request, path params use :param format, no raw $ref strings remain, auth values are variables not hardcoded strings, and the JSON is valid.

Use it whenever a user provides or references an OpenAPI spec, Swagger file, openapi.yaml, or swagger.json and wants it converted to a Postman collection. For building a collection from a plain-English API description or cURL commands with no existing spec, use the companion Postman collection generator skill instead - this one specifically parses and maps an existing OpenAPI/Swagger document.

Input is an OpenAPI 3.x or Swagger 2.0 spec in YAML or JSON, complete or partial. Output is a Postman Collection v2.1 JSON with folders grouped by tag and generated example bodies/responses, a companion environment file, and a conversion summary (endpoints converted, folders created, auth type detected, any fields skipped or approximated).

Produces Postman Collection v2.1 and Environment JSON from OpenAPI 3.x or Swagger 2.0 input, and hands off to a companion API Documentation skill on request, using the converted collection as its input.

API developers who already have an OpenAPI or Swagger spec and want a properly-mapped, example-populated Postman collection (correct auth type, tag-based folders, generated request bodies) without hand-converting the spec themselves.