AI Prompt to Debug a Failing API Test Using Postman's MCP Server

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.

ROLE: You are a regular expression expert who writes precise, well-documented patterns.

CONTEXT:
I need a regular expression for this matching rule: [DESCRIBE WHAT THE PATTERN SHOULD MATCH IN PLAIN ENGLISH].
Target regex flavor/language: [E.G., JAVASCRIPT, PYTHON RE, PCRE, POSIX].

Strings that SHOULD match:
[LIST 3-5 EXAMPLE STRINGS]

Strings that should NOT match:
[LIST 3-5 EXAMPLE STRINGS]

TASK:
1. Write a regular expression that matches all the "should match" strings and rejects all the "should not match" strings.
2. Break down the pattern piece by piece, explaining what each group, anchor, and character class does.
3. Test the pattern mentally against every example I gave and confirm the result for each.
4. List any realistic edge cases my examples didn't cover that could still break this pattern, and note how the pattern handles them.

OUTPUT FORMAT:
- The regex pattern in a code block
- A numbered breakdown of each part of the pattern
- A table confirming match/no-match for each example string
- A short "Edge cases to watch for" list

ROLE
You are a senior software engineer producing an implementation plan from a project management ticket before any code is written.

CONTEXT
- Ticket source: Linear, accessed via the connected MCP server
- Ticket ID or URL: [TICKET_ID_OR_URL]
- Target repository or service: [REPO_OR_SERVICE_NAME]
- Relevant tech stack: [LANGUAGE_FRAMEWORK_STACK]

TASK
1. Read the ticket's title, description, comments, labels, and any linked parent or sub-issues from the connected Linear MCP server.
2. Summarize the current requirements in 3-5 sentences, noting anything that changed from the original description.
3. Propose an implementation approach: the files or modules likely affected, in order of change.
4. List edge cases and error conditions the implementation must handle.
5. List open questions that should be posted back to the ticket before work starts.

CONSTRAINTS
- Do not invent requirements that are not stated in the ticket or its comments.
- If acceptance criteria are missing or ambiguous, say so explicitly instead of assuming an answer.
- Keep the file/module list specific to what the ticket's labels and linked repo indicate; do not list unrelated parts of the codebase.
- Flag any blocking dependency on another open ticket.

OUTPUT FORMAT
## Ticket Summary
[3-5 sentence summary]

## Implementation Approach
- [Ordered list of files/modules and what changes in each]

## Edge Cases
- [List]

## Open Questions
- [List, or "None" if genuinely none]