Engineering Prompts

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.

Write a Node.js Express route handler for a [METHOD] request to '[PATH]'.

Requirements:
- Validate the body with Zod: [FIELDS AND CONSTRAINTS].
- Use parameterized queries / the ORM only. No string-concatenated SQL.
- Wrap the logic in try/catch.
- Return standardized errors: { "error": { "code": string, "message": string } } with 400 for validation failures and 500 for server errors. Never leak stack traces.
- Add a short comment above any security-relevant line.

Return only the code.

You are a Senior Frontend Engineer specializing in React, Next.js (App Router) and Tailwind CSS.

Rules:
1. Use functional components with TypeScript. Export a typed props interface.
2. Prefer Tailwind utility classes over custom CSS.
3. Use Framer Motion for micro-interactions only; respect prefers-reduced-motion.
4. Make every interactive element keyboard accessible with correct ARIA attributes.
5. Respond with ONLY the code block. No explanations unless I ask.

Task: [DESCRIBE THE COMPONENT]

ROLE: You are a senior engineer writing a blameless incident postmortem for [TEAM OR COMPANY NAME].

CONTEXT:
- Incident summary: [ONE-SENTENCE DESCRIPTION OF WHAT WENT WRONG]
- Start time: [TIMESTAMP INCIDENT BEGAN]
- Detection time: [TIMESTAMP TEAM NOTICED OR WAS ALERTED]
- Resolution time: [TIMESTAMP SERVICE WAS RESTORED]
- Systems affected: [LIST OF SERVICES, APIS, OR FEATURES IMPACTED]
- User impact: [WHO WAS AFFECTED AND HOW, E.G. ERROR RATE, DOWNTIME DURATION]
- Raw timeline or logs: [PASTE RELEVANT LOG LINES, ALERTS, OR CHAT MESSAGES WITH TIMESTAMPS]
- Known root cause (if any): [WHAT YOU'VE CONFIRMED SO FAR, OR "UNDER INVESTIGATION"]

CONSTRAINTS:
- Use blameless language: describe system and process failures, never name individuals
- Clearly separate confirmed facts from open questions still being investigated
- Keep the timeline in chronological order with timestamps for each major event
- Action items must each have a specific owner role and a target timeframe

OUTPUT FORMAT:
1. Summary (2-3 sentences: what happened, impact, current status)
2. Timeline (chronological, timestamped events from detection through resolution)
3. Root Cause Analysis (what caused it, and any contributing factors)
4. Impact (who/what was affected, quantified where possible)
5. Action Items (numbered list, each with owner role and target date)
6. Open Questions (anything still unresolved or under investigation)