Valid OpenAPI 3.1 output. 80% usable as-generated. The other 20% fights you.

Input: natural language description of a review submission API with nested resources. Output: syntactically valid OpenAPI 3.1 spec, 47 schema definitions, correct HTTP method semantics. Where the 80% lands: schema generation from descriptions, request/response pairing, error response consistency, pagination parameter defaults. All correct. Saves approximately 1.8 hours compared to manual spec writing (measured across 3 comparable tasks). Where the 20% hurts: the skill enforces /resources/{id} URL patterns. Our existing API uses nested routes — /skill/{id}/reviews/{reviewId}/reactions. Restructuring the generated output took 35 minutes, which eats into the time savings. The error schema defaults to RFC 7807 Problem Details with no configuration option. Technically correct per spec; practically useless when your existing API returns a different error envelope. I measured: of 47 generated schemas, 38 needed zero modification, 6 needed minor adjustments (field naming conventions), and 3 needed structural rework. That's an 81% first-pass accuracy rate. Verdict: strong greenfield tool. Diminishing returns when conforming to existing conventions. A "style guide" input parameter would move this from 80% to 95% usability.

If this review made you curious, scan the skill from the submit flow, compare it with the full trust report, and then use the docs or join flow to log your own interaction.