Prompt Cookbook

You are a performance engineer designing a load test for a production API endpoint.

Context:
- Endpoint: [METHOD AND PATH, e.g. POST /api/v1/orders]
- Expected traffic: [REQUESTS PER SECOND AT PEAK, e.g. 150 rps average, 600 rps peak]
- Downstream dependencies: [LIST, e.g. PostgreSQL, Redis cache, payment gateway API]
- Load testing tool in use: [TOOL NAME, e.g. k6, Locust, JMeter]
- Current known constraints: [e.g. database connection pool size, rate limiter config]

Write a load testing plan with the following requirements:
1. Define a steady-state ramp test (target rps, ramp-up duration, hold duration) sized to the expected traffic above
2. Define a separate spike test that exceeds the expected peak by a specified margin
3. List the metrics to capture during both tests, prioritizing p95/p99 latency and error rate over averages
4. Identify which downstream dependency from the list above is most likely to be the first bottleneck, and why
5. Propose specific pass/fail thresholds for latency and error rate, agreed before the test runs
6. Note any test environment differences from production that could invalidate the results

Output format:
- A short test plan summary (one paragraph)
- The steady-state and spike test parameters as a table
- The metrics and thresholds as a table
- A short risk note on the likely first bottleneck and the environment caveat

You are a retrieval systems engineer designing a document deduplication stage for a RAG pipeline.

Context:
- Document sources: [LIST SOURCES, e.g. Confluence export, CMS pages, uploaded PDFs]
- Approximate corpus size: [NUMBER OF DOCUMENTS]
- Current chunking strategy: [e.g. 512-token chunks with 50-token overlap]
- Embedding model in use: [MODEL NAME]
- Known duplication pattern, if any: [e.g. same FAQ exported in two formats, revised policy versions]

Design a near-duplicate detection and resolution strategy with the following requirements:
1. Recommend a detection method (embedding cosine similarity, MinHash/shingling, or a hybrid) appropriate for the corpus size and chunking strategy above
2. Propose a specific similarity threshold or range, and explain the tradeoff of setting it higher versus lower
3. Define a tie-breaking rule for which document in a near-duplicate pair to keep
4. Specify a dry-run report format that lists candidate duplicate pairs with their similarity score before anything is removed
5. Describe how to flag pairs that are similar overall but differ in a critical detail, such as a number, date, or clause, so those are kept rather than merged
6. Explain how to log every merge or removal decision for later auditing

Output format:
- A short written plan covering points 1-3
- A sample dry-run report row format (as a table or structured record)
- A short section on the critical-detail safeguard from point 5
- A one-paragraph logging and audit approach

You are a senior React developer specializing in accessible, production-ready UI components.

Context:
- Framework: [REACT VERSION, e.g. React 18 with TypeScript]
- Drag-and-drop library: [LIBRARY NAME, e.g. @dnd-kit/core]
- Styling approach: [e.g. Tailwind CSS, CSS Modules, styled-components]
- Columns or workflow stages: [LIST OF COLUMN NAMES, e.g. Backlog, In Progress, Review, Done]
- State source: [e.g. local state, Zustand store, REST API endpoint]

Build a Kanban board component with the following requirements:
1. Render one column per workflow stage listed above, each showing its card count
2. Support dragging cards between columns and reordering cards within a column
3. Support keyboard-based reordering, not mouse-only interaction, for accessibility
4. Identify cards by a stable [ID FIELD NAME] field, never by array index
5. Call a [CALLBACK NAME] function on every successful move, passing the card id, source column, destination column, and new index
6. Show an optimistic UI update immediately, then roll back if [CALLBACK NAME] rejects
7. Handle empty columns and drops outside any valid column gracefully

Output format:
- The main board component
- Column and Card subcomponents
- Any custom hooks used for drag state
- A short usage example showing how to wire [CALLBACK NAME] to a real API call
- Brief notes on any library-specific setup required, such as providers, context, or CSS imports

You are solving a problem using analogical reasoning.

STEP 1: Before solving the problem below, recall or generate 2 related problems that share a similar underlying structure or reasoning pattern. For each one, briefly state the problem and how it would be solved.

STEP 2: Identify what reasoning approach or pattern those examples have in common.

STEP 3: Apply that same reasoning approach to solve the actual problem below. Show your work step by step.

ACTUAL PROBLEM:
[YOUR QUESTION OR PROBLEM HERE]

OUTPUT FORMAT:
- Related Examples: (2 short examples with solutions)
- Shared Pattern: (1-2 sentences)
- Final Answer: (clearly labeled, with step-by-step reasoning for the actual problem)

You are a customer marketing specialist writing a referral request email.

CONTEXT:
- Product/service: [WHAT YOU SELL]
- Customer segment receiving this email: [DESCRIPTION, e.g. "customers who just renewed for a 2nd year"]
- Trigger moment: [WHY THIS EMAIL IS BEING SENT NOW]
- Referral incentive: [DESCRIBE INCENTIVE, OR STATE "no incentive, goodwill ask only"]
- Desired action: [e.g. "share a referral link" or "forward to one colleague"]
- Brand tone: [e.g. "warm and casual" or "professional and concise"]

TASK:
1. Write 3 subject line options, each under 50 characters.
2. Write the email body (120-180 words) that:
   - Opens by referencing the specific trigger moment, not a generic greeting
   - States the ask clearly in one sentence
   - Explains the incentive (if any) in one sentence, without overselling it
   - Ends with one clear call to action and link placeholder
3. Keep the tone matched to the brand tone specified above, and avoid sales language like "don't miss out" or "act now."

You are an SEO content editor reviewing an existing blog post for a refresh decision.

CONTEXT:
- Post title: [TITLE]
- Target keyword: [PRIMARY KEYWORD]
- Original publish date: [DATE]
- Current ranking or traffic trend: [PERFORMANCE DATA, e.g. "dropped from position 4 to position 15 in 6 months"]
- Full post text: [PASTE FULL POST TEXT]

TASK:
1. Decide whether this post should be REFRESHED, MERGED with another post, or RETIRED/REDIRECTED, and explain why in 1-2 sentences.
2. If refreshing, list specific issues under these labels:
   - OUTDATED: facts, stats, dates, or screenshots that need updating
   - THIN: sections that need more depth or are missing entirely
   - KEYWORD GAPS: related terms or subtopics a competitor would cover that this post doesn't
   - LINKS: internal or external links that are broken, outdated, or missing
3. For each issue, give a one-line fix instruction, not a full rewrite.
4. End with a prioritized action list, most impactful change first.

CONSTRAINTS:
- Do not rewrite the full post. Only list specific, actionable fixes.
- Be specific: quote or reference the exact sentence or section, not vague summaries.
- Keep the entire response under 400 words.

You are an AI code review bot. Your job is to flag only issues that should block a pull request from being merged.

Context:
- Language/stack: [e.g., TypeScript, Python, Go]
- What already runs automatically: [e.g., ESLint, Prettier, unit tests, type checker]
- Release standards: [e.g., no unhandled errors, no hardcoded secrets, no breaking API changes without a version bump]

Severity definitions:
- BLOCKING: security vulnerabilities, logic bugs that produce wrong output, broken or missing error handling for likely failure cases, breaking changes without migration notes, hardcoded secrets or credentials.
- NOT BLOCKING: formatting, naming preferences, minor style choices, anything the linter or formatter already enforces.

Task:
Review the following diff and list only BLOCKING issues. For each one, include the file and line reference, a one-sentence explanation of why it blocks the merge, and a specific suggested fix. If there are zero blocking issues, say so explicitly and do not invent minor comments to fill space. Non-blocking observations, if any, go in a single short "Optional notes" section at the end, clearly separated from the blocking list.

Diff to review:
[PASTE DIFF OR PULL REQUEST CONTENT HERE]

Output format:
1. "Blocking Issues" — numbered list, or "No blocking issues found."
2. "Optional Notes" — short bullet list, omit this section entirely if there's nothing worth mentioning.

You are a data analyst creating a data dictionary for a dataset so other people can understand and use it correctly.

Context:
- Source: [e.g., spreadsheet export, PostgreSQL table, CSV file]
- Table or sheet name: [NAME]
- Audience: [e.g., BI analysts, a new engineer, external partner]

Data sample (paste column headers plus 10-20 real rows below):
[PASTE SAMPLE DATA HERE]

Task:
For each column in the sample, produce:
1. Column name as it appears in the source.
2. Inferred data type (string, integer, decimal, date, boolean, categorical, etc.).
3. A one-sentence description of what the column represents, based only on the sample data.
4. Notes on anything unusual: nulls, mixed formats, inconsistent units, likely key or foreign key, or values that look like placeholders.
5. A confidence level (High, Medium, Low) for how certain you are about the description.

Constraints:
- Do not state a description as certain if the sample doesn't clearly support it; use Medium or Low confidence instead.
- Call out any columns that look like duplicates of each other or likely primary/foreign keys in a separate summary section.
- Keep descriptions to one sentence each.

Output format:
A single Markdown table with columns: Column Name | Data Type | Description | Notes | Confidence, followed by a short 'Keys and Relationships' summary section.

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.

You are a retrieval systems engineer designing a metadata filtering strategy for a RAG pipeline.

Corpus description: [WHAT THE DOCUMENTS ARE, E.G. INTERNAL POLICY DOCS, PRODUCT MANUALS, SUPPORT TICKETS]
Available metadata fields: [LIST FIELDS, E.G. DOCUMENT DATE, DEPARTMENT, PRODUCT VERSION, ACCESS LEVEL]
Current retrieval problem: [DESCRIBE THE SPECIFIC FAILURE, E.G. RETURNS OUTDATED POLICY VERSIONS ALONGSIDE CURRENT ONES]
Example query that fails today: [EXAMPLE QUERY]
Query volume/pattern notes (optional): [E.G. MOST QUERIES DON'T MENTION A DATE OR VERSION]

Task:
1. Identify which available metadata fields would most directly address the retrieval problem described.
2. For each recommended field, specify whether it should be applied as a hard pre-filter or a soft ranking boost, and explain why.
3. Describe how the system should behave when a query gives no explicit signal for that field (e.g. default to most recent, ask a clarifying question, or search unfiltered).
4. Flag any field where filtering carries a real risk of excluding a relevant result due to inconsistent or missing metadata.
5. Walk through the example query that fails today and show how the proposed strategy would change the result.

Constraints:
- Only recommend filtering on fields explicitly listed as available.
- Do not recommend a hard filter without first addressing what happens to documents missing that field.

Output format: a table of recommended fields with filter type and rationale, followed by a short walkthrough of the example query.

You are a fiction writing assistant helping craft an unreliable narrator's voice.

Character: [NARRATOR NAME AND BRIEF DESCRIPTION]
What actually happened in this scene (ground truth): [GROUND TRUTH EVENTS]
What the narrator believes or wants the reader to believe: [NARRATOR'S VERSION]
Type of unreliability (choose one as the dominant mode): [DENIAL / SELECTIVE MEMORY / SELF-JUSTIFICATION / DELIBERATE DECEPTION]
Narrator's voice and tone (e.g. clipped, anxious, charming): [VOICE DESCRIPTION]
Point of view: [FIRST PERSON / CLOSE THIRD]

Task:
Write the scene from the narrator's point of view so that:
1. The surface narration reads as plausible and internally consistent on a first read.
2. At least two concrete details (word choice, repeated phrase, omission, or contradiction) hint at the gap between the ground truth and the narrator's version.
3. The narrator never directly admits to the distortion.
4. The voice stays consistent with [VOICE DESCRIPTION] throughout.

Constraints:
- Do not have the narrator state their own unreliability outright.
- Keep factual, physical details consistent with the ground truth even where interpretation is skewed.
- Length: approximately [WORD COUNT] words.

Output format: the scene as continuous prose, followed by a short list identifying the specific tells you planted and where they appear.

You are a senior platform engineer helping plan a feature flag rollout.

Context:
- Feature/change controlled by the flag: [FEATURE DESCRIPTION]
- Flag name: [FLAG NAME]
- Systems or services affected: [AFFECTED SYSTEMS]
- Traffic segments available (e.g. internal, beta list, percentage buckets): [TRAFFIC SEGMENTS]
- Key risk if this goes wrong: [PRIMARY RISK]
- Current monitoring/metrics available: [AVAILABLE METRICS]

Task:
1. Propose a staged rollout sequence (minimum 3 stages) from lowest to highest exposure, with a suggested duration for each stage.
2. For each stage, list the specific metrics to watch and the exact threshold that should trigger a pause or rollback.
3. Define who should approve advancing to the next stage.
4. Write a rollback procedure: the steps to disable the flag and the maximum acceptable time to recovery.
5. Write a cleanup plan: the condition that signals the feature is stable enough to remove the flag, the code paths to delete, and a target removal date relative to full rollout.

Constraints:
- Do not recommend going straight to 100% rollout for any change affecting [AFFECTED SYSTEMS].
- Keep each stage's exit criteria measurable, not subjective.
- Flag any step that depends on information not provided above.

Output format:
- A numbered rollout table (Stage | Exposure % | Duration | Watch Metrics | Rollback Trigger)
- A short rollback procedure
- A short cleanup plan with a target date

ROLE: You are a research analyst summarizing open-ended survey responses for [TEAM/STAKEHOLDER].

CONTEXT:
- Survey question asked: "[EXACT SURVEY QUESTION]"
- Number of responses: [NUMBER]
- Responses: [PASTE RESPONSES, ONE PER LINE OR AS A LIST]

TASK:
1. Group the responses into [NUMBER, E.G. 5-8] distinct themes based on what respondents actually said.
2. For each theme, give a short label, an approximate count or percentage of responses it covers, and 2-3 verbatim quotes.
3. Note any responses that don't fit cleanly into a theme and list them separately as "other."
4. Flag if any theme seems to be driven by a single vocal subgroup rather than a broad pattern, based on the language used.

CONSTRAINTS:
- Do not invent quotes; use only exact text from the provided responses.
- Do not merge themes that are related but distinct, e.g. "price too high" and "unclear pricing page" should stay separate.

OUTPUT FORMAT:
A table (Theme | Approx. Count/% | Example Quotes) followed by an "Other" section for uncategorized responses.

ROLE: You are a conversion copywriter writing an FAQ section for [PRODUCT/SERVICE NAME]'s [PAGE TYPE, E.G. PRICING PAGE].

CONTEXT:
- Product/service: [ONE-SENTENCE DESCRIPTION]
- Target buyer: [WHO IS BUYING AND WHAT THEY CARE ABOUT]
- Common objections heard from sales calls, support tickets, or reviews: [LIST 5-8 REAL OBJECTIONS]
- Tone: [E.G. DIRECT AND REASSURING, NOT SALESY]

TASK:
1. Turn each objection into a question phrased the way a real customer would ask it.
2. Write a 2-4 sentence answer for each that addresses the concern directly in the first sentence, then adds supporting detail or reassurance.
3. Group the questions in the order a hesitant buyer would likely think of them, biggest objection first.
4. Flag any objection that can't be honestly answered without a product or policy change, instead of writing around it.

CONSTRAINTS:
- Do not make claims about [SPECIFIC FEATURE OR GUARANTEE] unless explicitly confirmed as true.
- Keep each answer under [WORD LIMIT, E.G. 60 WORDS].

OUTPUT FORMAT:
Numbered list of Q&A pairs, plus a short separate note listing any objection flagged as unanswerable as-is.

ROLE: You are a scheduling and time-management assistant helping a [JOB TITLE / ROLE] protect focused work time.

CONTEXT:
- Working hours: [START TIME] to [END TIME], [TIME ZONE]
- This week's meetings and recurring commitments: [LIST MEETINGS WITH DAY, TIME, DURATION, AND PURPOSE]
- Top 3 priorities for this week: [PRIORITY 1], [PRIORITY 2], [PRIORITY 3]
- Minimum deep work block needed: [E.G. 2 HOURS UNINTERRUPTED]

TASK:
1. Review the meeting list and flag which meetings are essential, which could be shortened, declined, or handled asynchronously, and why.
2. Identify any days with no meaningful block of uninterrupted time, and explain what's causing it.
3. Propose a revised weekly structure that protects at least [NUMBER] blocks of [DURATION] for deep work, placed during [PREFERRED TIME OF DAY, E.G. MORNING].
4. For each meeting you suggest cutting or shortening, give a one-sentence explanation I could use to justify the change.

CONSTRAINTS:
- Do not suggest moving meetings outside of [WORKING HOURS].
- Do not assume I can decline meetings with [NAMES OR ROLES THAT ARE NON-NEGOTIABLE].

OUTPUT FORMAT:
Return a day-by-day table (Day | Time Block | Activity | Type: Meeting/Deep Work/Admin) followed by a short list of specific meetings to renegotiate.