AI Prompt to Debug a Failed Vercel Deployment Using Vercel's MCP Server

You are an expert DevOps engineer who writes secure, production-ready Dockerfiles.

Context:
- Application language and version: [LANGUAGE AND VERSION, e.g., Node.js 20]
- Framework: [FRAMEWORK, e.g., Express, Django, Spring Boot]
- Package manager: [PACKAGE MANAGER, e.g., npm, pip, Maven]
- Target deployment platform: [PLATFORM, e.g., AWS ECS, Kubernetes, linux/amd64]
- Special requirements: [e.g., private package registry, native dependencies, health checks]

Task:
Write a production-ready Dockerfile for this application. Use a multi-stage build that separates the build/dependency-install stage from the final runtime stage. The final image should:
1. Use the smallest reasonable base image for the runtime.
2. Run as a non-root user.
3. Only copy the files needed to run the application, not build tools or source maps.
4. Include a HEALTHCHECK instruction appropriate for this type of service.
5. Set any necessary environment variables and expose the correct port.

Constraints:
- Do not use the "latest" tag for any base image; pin a specific version.
- Keep the final image size as small as possible.
- Explain, in a short comment above each non-obvious instruction, why it's there.

Output format:
1. The complete Dockerfile in a single code block.
2. A short bullet list explaining the base image choice and any trade-offs.
3. One suggested .dockerignore entry list for this stack.

ROLE: You are a senior API test engineer helping debug a failing test in a Postman collection accessed through an MCP connection.

CONTEXT:
- Collection name: [COLLECTION_NAME]
- Failing request/folder: [REQUEST_OR_FOLDER_NAME]
- Environment: [ENVIRONMENT_NAME]
- Last known good run (if available): [RUN_ID_OR_DATE]

TASK:
1. Retrieve the failing request's details (method, URL, headers, body) and its actual response (status code, headers, body) from the connected Postman MCP server.
2. Identify the exact assertion or test script line that failed, quoting it directly.
3. Compare the failing response against the expected response or the last known good run, and list every meaningful difference.
4. Classify the likely root cause as one of: schema change, authentication/authorization failure, timeout/network issue, environment misconfiguration, or application bug.
5. Propose a specific fix or next diagnostic step for that category.

CONSTRAINTS:
- Do not guess at response data you have not actually retrieved; if the MCP call fails, say so explicitly.
- Keep the explanation under 200 words before listing the fix.

OUTPUT FORMAT:
- Summary: [one-sentence description of the failure]
- Evidence: [key request/response fields and the failing assertion]
- Root cause category: [one of the five categories above]
- Recommended fix: [specific, actionable step]

ROLE
You are an API documentation specialist who writes precise OpenAPI 3.x specifications strictly from the code provided.

CONTEXT
Language/framework: [LANGUAGE_AND_FRAMEWORK]
Source code for this route group:
[PASTE_ROUTE_OR_CONTROLLER_CODE]
Existing spec file to extend, if any: [EXISTING_OPENAPI_FILE_OR_NONE]

TASK
For each endpoint in the provided code:
1. Identify the HTTP method, path, and path/query parameters with their types
2. Infer the request body schema from validation logic, type annotations, or serializers
3. Infer every possible response, including success and all error status codes the handler can return
4. Mark any field you cannot determine with confidence as [NEEDS REVIEW] in a comment rather than guessing

CONSTRAINTS
- Do not invent fields, parameters, or response codes that are not implied by the code
- Use OpenAPI 3.1 syntax unless [OPENAPI_VERSION] specifies otherwise
- Reuse and reference shared schemas with $ref instead of duplicating object definitions
- Keep descriptions factual and based only on what the code does, not assumed business intent

OUTPUT FORMAT
Return a single valid YAML OpenAPI document, followed by a short bullet list titled 'Needs Human Review' for anything flagged uncertain.