AI Prompt to Triage and Prioritize Engineering Issues Using Linear's MCP Server

ROLE: You are a senior engineer writing a technical design document for team review.

CONTEXT:
- Feature or change: [WHAT IS BEING BUILT OR CHANGED]
- Problem it solves: [THE CONCRETE PROBLEM OR PAIN POINT]
- Current system constraints: [EXISTING ARCHITECTURE, TEAM SIZE, DEADLINE, OR OTHER LIMITS]
- Proposed approach: [HIGH-LEVEL DESCRIPTION OF THE SOLUTION]
- Known alternatives considered: [ANY OTHER APPROACHES ALREADY DISCUSSED, IF ANY]

CONSTRAINTS:
- Do not invent specific performance numbers, benchmarks, or capacity figures that were not provided
- Include at least one alternative approach and explain why it was not chosen
- Flag any open questions or risks explicitly rather than glossing over them
- Keep the document scannable: short paragraphs, no filler language

OUTPUT FORMAT:
1. Problem statement (what's broken or missing today)
2. Proposed solution (the approach, at a level engineers outside the immediate team can follow)
3. Alternatives considered (at least one, with reasons it was rejected)
4. Risks and open questions
5. Rollback plan (what happens if this needs to be reverted)

Write the design document now using only the information provided above.

Role: You are a backend engineer designing a resilient API error-handling and retry strategy.

Context:
- API being called: [API_NAME_OR_DESCRIPTION]
- Language/framework: [LANGUAGE_OR_FRAMEWORK]
- Known behavior: [RATE_LIMITS_TIMEOUTS_ERROR_CODES]
- Call pattern: [SINGLE_REQUEST_OR_BATCH_OR_HIGH_VOLUME]
- Idempotency: [IS_THE_OPERATION_SAFE_TO_RETRY]

Task:
1. Classify likely failure modes for this API call into retryable and non-retryable categories.
2. Recommend a specific retry strategy (backoff type, max attempts, max total wait, jitter) for the retryable category.
3. Recommend how non-retryable errors should be handled (fail fast, surface to caller, alert).
4. Note where a circuit breaker or rate limit guard would help if call volume is high.
5. Provide implementation code in [LANGUAGE_OR_FRAMEWORK] that applies this strategy to the described call.

Constraints:
- Do not retry non-retryable errors.
- Include logging at each retry attempt and final failure.
- Keep the retry logic isolated so it can be reused across multiple API calls.

Output format:
- A short table of failure modes (error type, retryable: yes/no, handling)
- The recommended retry parameters
- The implementation code in a fenced code block

ROLE: You are a senior site reliability engineer writing a rollback plan for a production deployment.

CONTEXT:
- Service or system being deployed: [SERVICE NAME]
- What the deployment changes: [CODE CHANGES, CONFIG CHANGES, DATABASE MIGRATIONS, ETC.]
- Deployment method: [CI/CD PIPELINE, MANUAL DEPLOY, FEATURE FLAG ROLLOUT]
- Dependent services or consumers affected: [LIST DEPENDENT SERVICES]

TASK:
Write a rollback plan for this deployment that includes:
1. The specific monitoring signals or alerts that indicate a rollback is needed
2. Step-by-step rollback instructions in execution order, each with an owner
3. Any step that is irreversible or partially irreversible, flagged separately
4. A verification step to confirm the rollback succeeded
5. An estimated time to complete the rollback

CONSTRAINTS:
- Assume the person executing the rollback may not be the person who wrote the plan
- Do not assume manual database fixes are safe without naming the exact commands or scripts
- Keep each step to one action

OUTPUT FORMAT:
A numbered list of rollback steps, followed by a short "Irreversible Actions" section and a "Verification" section.