Best PromptsOpenAPI Spec From Code
Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.
Handler code, routes, and models: """ [PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE] """ Generate an OpenAPI 3.1 specification from the code above. API name, version, and base URL: [DETAILS] Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced] Consumers of this API: [INTERNAL / PARTNERS / PUBLIC, which affects how much description each field needs] Requirements: - One entry per route actually present in the code. Do not add routes that "should" exist. - Request bodies and parameters typed from the real validation schemas, including which fields are required, formats, enums, and min and max constraints. Where validation is implicit rather than declared, mark the field with a description saying so. - Response schemas for every status code the handler can actually return, including the error paths. Error responses are the half that specs usually omit and clients most need. - Auth requirements per operation, matching where the middleware actually applies rather than where it is documented to apply. - operationId, summary, and description per operation. The description says what the operation does and any non-obvious side effect. - Realistic examples for each request and response, built from the field types, with no real or realistic-looking personal data. - Components for shared schemas rather than repeating inline definitions. Then report separately: 1. **Gaps**: anything you could not determine from the code (rate limits, pagination behavior, idempotency, deprecation) marked as [UNKNOWN] in the spec rather than filled in with a plausible default. 2. **Inconsistencies** found across the code: routes with different error shapes, inconsistent naming, mixed pagination styles, or auth applied unevenly. These are the findings worth acting on before publishing the spec. Rules: derive everything from the code. Never document a parameter, status code, or behavior the code does not implement, since a spec that describes intentions is worse than no spec: clients build against it.
How to use
The inconsistency report is often more valuable than the spec. Generating a spec from real handlers forces every route into one shape and immediately surfaces the endpoints that return a different error envelope or paginate differently, which nobody notices while reading code one file at a time. Validate the output with a linter before publishing, and keep the [UNKNOWN] markers in until someone answers them rather than filling them with sensible-looking defaults.
More coding prompts
Write the commit message for this change. Diff: """ [PASTE THE STAGED DIFF] """ Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"] Convention: [Conventional Commits / this repo's existing style, pasted below / plain] Recent commits from this repo, to match style: """ [PASTE 5-10 RECENT COMMIT SUBJECT LIN
Commit Message
Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.
Help me recover from a git mistake without making it worse. What I was trying to do: [THE GOAL] What I ran: [THE EXACT COMMANDS, IN ORDER] What happened instead: [THE OUTPUT OR THE STATE NOW] Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled] Uncommitted work I cannot lose: [WHAT AND WHERE, o
Undo a Git Mistake
Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.
Infrastructure code to review: """ [PASTE THE TERRAFORM, CLOUDFORMATION, PULUMI, OR KUBERNETES MANIFESTS. INCLUDE THE PLAN OUTPUT IF YOU HAVE IT.] """ Review the infrastructure code above as the person who will be paged when it breaks. Environment: [PROD / STAGING / DEV] and what runs on it: [WORKLOAD] What this change is meant to do: [
Infrastructure as Code Review
Review Terraform, CloudFormation, or Kubernetes manifests for blast radius, security defaults, state risk, and what the plan will really do.