Prompt Library

Write a professional email from me (a software engineer at a 40-person startup) to my manager, Priya Sharma, requesting 5 days off: December 23–27 for the holidays. Context: - My current project (payment gateway integration) will be merged and in staging by Dec 20 - No on-call rotation scheduled for me that week - Our team communicates async, so a short email is fine Requirements: - Tone: warm but not overly formal — we have a good working relationship - Length: under 100 words - End with: offer to discuss if it creates any issues, mention I'll set an out-of-office

I need a weeknight chicken dinner for 2 people. What I have: chicken thighs (bone-in), garlic, lemon, fresh rosemary, olive oil, canned white beans, chicken stock, parmesan. Constraints: - Total time: under 35 minutes (I get home at 7 PM) - No other dairy — my partner is lactose intolerant (parmesan is fine) - I'm a confident cook, don't oversimplify techniques Format: one intro sentence (what the dish is), then ingredient list with amounts, then numbered steps. Add a note if anything can be prepped the night before.

Draft a performance improvement plan for [EMPLOYEE], a senior engineer whose delivery has dropped significantly over the last quarter (missed 3 of 4 sprint commitments; two teammates raised code-quality concerns). Constraints: - Focus strictly on observable work behaviors — no speculation about personal causes - 30/60/90-day structure with measurable checkpoints - Tone: supportive and factual, written to help them succeed - Include the support the company will provide at each stage I'll fill in names and specifics myself.

My app can't connect to Postgres. Here's my config with secrets redacted — the shapes are preserved: DATABASE_URL=postgres://USER:PASSWORD@HOST:5432/DBNAME (real password contains @ and ! characters) Error: ``` invalid port ":5432" after host ``` I suspect the special characters. What's the actual rule for special characters in connection-string passwords, and what's the safe fix?

You are a senior technical recruiter who has placed 80+ engineers at Series A startups. Task: Write a job description for a Senior Backend Engineer at Vitae — a resume analytics SaaS, 10-person team, recently closed Series A. Context: - Role: fully remote, $145–175k USD, reports directly to CTO - Stack: Go, PostgreSQL, Redis, Kubernetes on GCP - Culture: strong opinions, minimal meetings, high autonomy, no bureaucracy - We're competing with FAANG for talent — the JD must be honest and compelling, not corporate Format: - 2-sentence company intro (what we do and why it matters to job seekers) - 5 bullet responsibilities (start each with a strong verb) - 5 bullet must-have requirements - 3 bullet nice-to-haves - 2-sentence close with how to apply (email: [email protected])

You are a staff-level Go engineer. This code ships to production next Friday. Review this function for: 1. Error handling — are all error paths handled, or do any fail silently? 2. Security — SQL injection, authorization bypass, or sensitive data exposure? 3. Correctness — logic bugs that would cause wrong behavior in edge cases? For each issue: - Quote the exact line(s) - Label severity: [CRITICAL] [WARNING] [SUGGESTION] - Explain why it's a problem in production (not just theory) - Show working Go code that fixes it ```go func GetUserOrders(w http.ResponseWriter, r *http.Request) { userID := r.URL.Query().Get("user_id") rows, _ := db.Query("SELECT * FROM orders WHERE user_id = " + userID) var orders []Order for rows.Next() { var o Order rows.Scan(&o.ID, &o.Total, &o.Status) orders = append(orders, o) } json.NewEncoder(w).Encode(orders) } ```

Explain Type 2 diabetes to a 52-year-old who was just diagnosed. They have a nursing background and understand basic physiology (blood glucose, insulin, pancreas function) but have never studied endocrinology. Length: 3 focused paragraphs. Tone: honest and direct — they can handle clinical language, they just want clarity, not cheerful minimizing. Must cover: mechanism, why it progresses over time, and the 3 most important lifestyle levers. Do NOT use the phrase 'lifestyle disease' — they find it stigmatizing. End with: one thing most newly-diagnosed patients wish they had known earlier.

Write 5 landing page headlines for Vitae — a resume tool that shows you analytics after you apply: who opened your resume, how long they spent on it, which sections they focused on. Target buyer: product managers and engineers with 5–12 years of experience, quietly job searching while employed. Tone: confident and data-driven. NOT motivational, NOT hustle-culture. Format: each headline on its own line, max 8 words, no punctuation at end. Avoid: take control, stand out, land your dream job, get noticed. Requirement: one headline leads with the analytics angle, one leads with the insight angle, one is a direct question.

Write an engineering post-mortem for a database outage we had on Tuesday. Facts: - 2:47–4:12 PM PT: PostgreSQL primary became unresponsive - Root cause: a poorly-indexed query from our new analytics module triggered a table lock cascade on the orders table - Impact: 3,400 users couldn't access dashboards; API returning 503s; zero data loss - Fix: killed the offending query, promoted the read replica, analytics queries now run on the replica - Prevention: slow query logging added, read/write routing in place, index added to orders.created_at Audience: our engineering team + CTO + VP Eng. Technical, will fact-check everything. Tone: honest and technical — no corporate spin, no passive voice to dodge blame. Use "we" and name the root cause directly. Zero tolerance for "unexpected issues were encountered." Format: timeline of events → root cause analysis → impact by service → fix applied → 5 specific prevention items with owner and due date. Do NOT write: "We apologize for any inconvenience" or "unexpected behavior" or "our team worked quickly."

Write a rejection email for a software engineering candidate, Marcus Webb, who interviewed for our Senior Backend Engineer role. Context: - Marcus reached the final round (4 interviews) — a strong candidate overall - We're choosing someone with more Kubernetes experience, not because of a performance issue - Marcus was referred by someone on our team — we want to maintain the relationship - He'd be a good fit for a mid-level role if one opens in 6 months Tone: warm and specific — not a form letter. Acknowledge the time he invested. Be honest about why without being harsh. Format: 4–5 sentences max. No bullets. First name only in the greeting. Include: one genuine observation from his interviews (leave a [SPECIFIC OBSERVATION] placeholder — I'll fill it in). Closing: an authentic door-open for future roles — only if it sounds genuine, not performative.

Round 1: "Write a 1-page proposal for migrating our Go monolith to microservices. Audience: CTO + VP Eng at a 60-person B2B SaaS. Cover: problem, solution, 3-phase timeline, outcomes, top 3 risks." → Good structure. Problem statement is too technical for the CTO. Round 2: "Keep everything else. Rewrite ONLY the problem statement. Translate technical bottlenecks into business language: developer velocity and release frequency, not deployment pipelines." → Better. But risks section lists generic cloud risks, not ours. Round 3: "Rewrite the risks section ONLY. Replace the generic risks with these specific ones: (1) our team has no Kubernetes experience, (2) the order schema is 6 years old and migration is complex, (3) a 6-week window where two codebases coexist." → Done. 3 surgical patches. Nothing that worked got overwritten.

Fast one-line patches to use after getting output — no full rewrite needed: "Make this 35% shorter. Keep all key points, cut every filler sentence." "The opening is too slow — delete sentence 1 and start with what's currently sentence 2." "Rewrite ONLY the third paragraph. Add a specific dollar amount or time saving to make it concrete." "Too formal. Rewrite as if sending this to a colleague on Slack, not presenting to the board." "Give me 5 alternative versions of just the headline — different angles. I'll pick one." "Add one real example (company, person, or number) to each bullet point."

[After: "Use Redis for session storage"] "Why Redis over Memcached specifically? What would I lose by choosing Memcached instead for this use case?" "Walk me through the failure scenario: Redis pod restarts under load. What happens to active sessions? Does the answer change if I enable AOF persistence?" "We have 1,500 concurrent users now. At what scale does a single Redis setup start failing, and what's the migration path from there?" "What's the most common mistake teams make when first setting up Redis for sessions? Give me a concrete incident story." "Make the strongest case for NOT using Redis here. What would a skeptic say?"

[After: "This looks like a promising business model"] "Be more critical. What's the single biggest strategic flaw that you softened or omitted because I might not want to hear it?" "What does the most common failure mode look like for a business exactly like this? Give me a specific archetype — a real company or a named pattern — that tried this and failed." "Name the one assumption in my model that, if wrong, makes everything else irrelevant. How could I cheaply test it in 2 weeks?" "Write the Series A rejection email from a skeptical investor who passed on this deal."

I'm a backend developer comfortable with Docker: containers, images, volumes, docker-compose for multi-container apps. I've never used Kubernetes. Teach me Kubernetes using Docker as the foundation. For every new concept: 1. Tell me what Docker concept it replaces or extends 2. Tell me what specific problem it solves that Docker alone couldn't After explaining: - One scenario where Kubernetes is clearly right over docker-compose, with the specific technical reason - One scenario where docker-compose is still sufficient and Kubernetes would be overkill Then quiz me: 3 questions to test if I actually understood. After I answer, tell me what I got right, what was partially right, and what was wrong with corrections.

I'm 28, have $12,000 in savings, deciding between a HYSA at 4.8% APY vs. a broad index fund (assume 7% avg annual return). Planning to leave it 25 years. Explain compound interest using MY numbers: 1. What does $12,000 become in 25 years in each scenario? 2. Year-by-year comparison at years 5, 10, 15, 20, 25 3. What changes if I add $200/month to the index fund scenario? After, give me the one mental model I can use for the rest of my life to quickly estimate whether compound growth is working for or against me (savings AND debt). Then: ask me to explain compound interest back to you in one paragraph in my own words. Correct any errors.

Below is a client email. Draft a reply from me (project lead at a 12-person agency). EMAIL THREAD: "Team — this is the second deadline that's slipped. We were promised the dashboard on the 3rd. I need to tell my VP something concrete today. — Dana" FACTS YOU MAY USE (nothing else): - New realistic date: the 14th, confirmed with engineering this morning - Cause: a payments-API migration on their side added 2 weeks of rework - We will demo a working preview this Friday Tone: accountable, no excuses, no corporate filler. Under 120 words. End with one concrete next step Dana can forward to her VP.

My Python script crashes. Work only from the code and traceback below — if the cause isn't visible in them, say what else you'd need to see. CODE (relevant function): ```python def load_user(payload): user = payload["user"] return user["email"].lower() ``` TRACEBACK: ``` KeyError: 'email' ``` SAMPLE PAYLOAD that triggered it: ```json {"user": {"mail": "[email protected]", "id": 7}} ``` Give: (1) the root cause in one sentence, (2) the minimal fix, (3) how to make the function fail with a clearer message next time.

Suggest 6 names for a feature that continuously saves work in our design tool (like Figma). Vary them across these axes, one name per row, in a table: 1. Literal/descriptive 2. Metaphor from the physical world 3. One invented word 4. Playful 5. Enterprise-serious 6. Verb-first action name For each: the name, why it works, and one risk (confusing? trademark-y? too cute?). Audience: professional designers. Avoid anything with 'smart' or 'AI' in it.

We're a 5-person B2B startup selling to HR managers; goal is 200 qualified leads this quarter with a $3k budget and one part-time marketer. Give me 3 lead-generation options (may include webinar, ebook, or anything better). For each: effort in person-days, realistic lead range, time-to-first-lead, and — most important — **the scenario where this option fails**. Then recommend one and say what evidence would change your recommendation.

Classify each support ticket. Return only the label — one word, lowercase. Categories: bug, feature_request, question, billing Examples: Ticket: "When I click Save on the profile page, nothing happens — old data stays." Label: bug Ticket: "Could you add the ability to export to Excel? I only see CSV." Label: feature_request Ticket: "What's the difference between the Pro plan and the Team plan?" Label: question Ticket: "I cancelled my subscription but I'm still being charged monthly." Label: billing Ticket: "The CSV export doesn't include the date column even though it's visible in the table." Label:

Extract structured data from job postings. Return only valid JSON — no markdown, no explanation. Example 1: Input: "Stripe hiring Senior Backend Engineer, remote-first, $180-220k. 5+ years Go required. Payments experience a plus." Output: {"company":"Stripe","title":"Senior Backend Engineer","remote":true,"salary_min":180000,"salary_max":220000,"currency":"USD","required":["5+ years Go"],"nice_to_have":["payments experience"]} Example 2: Input: "Shopify needs Product Designer, Toronto hybrid, CAD 110-140k. Figma + user research required. Motion design a nice-to-have." Output: {"company":"Shopify","title":"Product Designer","remote":false,"location":"Toronto","salary_min":110000,"salary_max":140000,"currency":"CAD","required":["Figma","user research"],"nice_to_have":["motion design"]} Now extract: Input: "Anthropic hiring ML Research Engineer, SF or remote. $200-280k. PhD or 3+ yrs research required. LLM fine-tuning strongly preferred."

Production panic happening for 2 days. Only under load — can't reproduce locally. Full stack trace: ``` panic: runtime error: invalid memory address or nil pointer dereference goroutine 47 [running]: main.(*OrderService).ProcessOrder(...) /app/service/orders.go:89 +0x2a4 ``` Code (orders.go:85-95): ```go func (s *OrderService) ProcessOrder(ctx context.Context, orderID string) (*Receipt, error) { order, err := s.repo.FindOrder(ctx, orderID) if err != nil { return nil, err } charge, _ := s.payments.ChargeCard(ctx, order.Total, order.CustomerID) receipt := &Receipt{ OrderID: order.ID, ChargeID: charge.ID, } return receipt, nil } ``` Expected: charge card, return receipt Actual: panics at line 89 during high load Already tried: - Added logs — order is non-nil when function is called - CustomerID is validated at the handler level - The payment processor returns rate limit errors under load Hypothesis: charge, _ := ... is the issue but I'm not sure how to handle partial failures safely.

This Python function calculates percentage change but returns wrong results for specific inputs. ```python def percent_change(old_val, new_val): return ((new_val - old_val) / old_val) * 100 ``` Test cases: | old_val | new_val | Expected | Actual | Status | |---------|---------|----------|--------|--------| | 100 | 150 | +50.0 | +50.0 | ✓ | | 200 | 100 | -50.0 | -50.0 | ✓ | | 0 | 50 | undefined | ZeroDivisionError | ✗ | | -100 | -50 | +50.0 | +50.0 | ✓ | The only failing case is old_val=0. I need to: 1. Handle it gracefully (return None when old_val is 0) 2. Understand why it's not caught by the try/except I have elsewhere Also: are there any other edge cases I haven't tested that could cause wrong results (not errors, just wrong math)?

TEMPLATE: Weekly Engineering Status Update You are writing a weekly status update for [AUDIENCE: e.g. 'CTO and VP Eng' / 'entire company' / 'investors']. Format: **This week (shipped/completed):** - [3 bullets, past tense, concrete outcomes — not tasks, outcomes. Under 12 words each.] **Next week (planned):** - [3 bullets, future tense, specific deliverables. Under 12 words each.] **Blockers:** - [Each: what's blocked, who can unblock it, how long blocking] - OR: "No blockers this week." **Ask from you:** - [One specific thing needed — decision, intro, resource, approval] - OR: "No action needed from you this week." Tone: direct, factual, no filler. Under 15 words per bullet. --- FILL IN: Audience: [WHO] This week: [ROUGH NOTES] Next week: [ROUGH NOTES] Blockers: [ANY OR "none"] Ask: [WHAT YOU NEED OR "none"]

TEMPLATE: Production Code Review You are a senior [LANGUAGE] engineer reviewing code that ships to production. Review for these specific concerns only: 1. [FOCUS_1: e.g. 'Security: SQL injection, auth bypass, data exposure'] 2. [FOCUS_2: e.g. 'Error handling: unhandled errors, silent failures'] 3. [FOCUS_3: e.g. 'Performance: N+1 queries, blocking calls, allocations'] For each issue: - Quote the exact line(s) - Severity: [CRITICAL] [WARNING] [SUGGESTION] - Why it's a problem in production (not just theory) - Working [LANGUAGE] fix If an area looks clean, say so in one line. Do NOT suggest changes outside the 3 focus areas. --- FILL IN: Language: [Go / Python / TypeScript / etc.] Focus 1: [WHAT TO CHECK] Focus 2: [WHAT TO CHECK] Focus 3: [WHAT TO CHECK] Code: ```[language] [PASTE CODE HERE] ```

Summarize this sprint for non-technical stakeholders. OUTPUT CONTRACT — the response passes only if ALL of these hold: 1. Exactly 3 sections: Shipped / At Risk / Needs Decision 2. Each section: max 3 bullets, max 15 words per bullet 3. Zero technical terms (no API, deploy, refactor, latency, schema) 4. 'At Risk' items each name a business consequence, not a technical cause 5. 'Needs Decision' has exactly one ask with a deadline — or states 'No decisions needed' If information is missing for any section, write '[MISSING: what you need]' rather than inventing content. Sprint notes: [paste notes]

Write API documentation for this Go handler. SUCCESS CRITERIA (verify your output against these before responding): □ Every parameter in the code appears in the docs with its exact type □ Every error status the code can return is documented with its trigger condition □ The example request uses realistic values, not 'foo'/'bar'/'string' □ The example response matches the actual struct fields in the code — no invented fields □ Auth requirements stated in the first 2 lines After writing the docs, add a section 'VERIFICATION' listing each criterion with ✓ or ✗ and a note for any ✗. ```go [paste handler code] ```

You are a senior UX designer who has shipped 20+ B2B SaaS products. I'm attaching a screenshot of our dashboard's main view. Review it against these specific criteria: 1. **Visual hierarchy** — is it clear what the user should look at first, second, third? 2. **Information density** — is any section overloaded or underused? 3. **Accessibility** — contrast issues, text too small, missing labels, color-only indicators? 4. **Mobile risk** — which elements will break on a 375px viewport? 5. **Action clarity** — can a new user find the primary action within 3 seconds? For each issue: - Quote the specific element (e.g., 'the revenue chart in the top-right') - Severity: [CRITICAL] [WARNING] [SUGGESTION] - What to change and why — be specific enough for a developer to implement Context: this is a project management dashboard for teams of 5–20. Our users are non-technical project managers. The primary action should be 'Create New Task.' [attaches screenshot]

I'm attaching a photo of a restaurant receipt. Extract the data into this exact JSON schema: ```json { "restaurant": "string", "date": "YYYY-MM-DD", "items": [ { "name": "string (as printed, preserve original spelling)", "quantity": "number", "unit_price": "number (2 decimal places)", "total": "number (2 decimal places)" } ], "subtotal": "number", "tax": "number", "tax_rate_pct": "number or null if not shown", "tip": "number or null if not shown", "total": "number", "payment_method": "string or null if not shown", "confidence_notes": ["string — list anything unclear, smudged, or partially visible"] } ``` Rules: - Output ONLY valid JSON, no markdown wrapping - If a value is smudged or unclear, use your best guess AND add a note in confidence_notes - If quantity isn't shown, assume 1 - Use the printed total, don't recalculate [attaches receipt photo]

Triage the support ticket below. A JSON schema is enforced separately with fields: category (enum: billing|bug|feature_request|account|other), priority (enum: p0|p1|p2|p3), sentiment (enum: angry|frustrated|neutral|positive), summary (string, ≤20 words), missing_info (array of strings). Decision rules: - p0 ONLY if: data loss, security issue, or a production system down for a paying customer - 'angry' requires explicit hostility; disappointment alone is 'frustrated' - category 'other' must include at least one missing_info entry explaining what would disambiguate - summary states the user's actual blocking problem, not their emotion TICKET: "Second time writing. Export has been spinning for 3 days and our quarterly report is due Friday. If this isn't fixed we're moving to Retool."

Extract fields from the contract excerpt below. Schema (enforced): each field is an object {value: string|null, quote: string|null, confidence: high|medium|low}. Fields: party_a, party_b, start_date (ISO), end_date (ISO), payment_terms, auto_renewal. Rules: - value must be supported by a verbatim quote from the excerpt; put that quote in 'quote' - if the excerpt doesn't state a field, value=null, quote=null, confidence=low — do NOT infer from typical contracts - dates written as '12 months from execution' → keep as written in value, confidence=medium EXCERPT: "This agreement between Vitae Inc. and BlueHarbor LLC commences January 5, 2026 and continues for twelve (12) months. Fees are payable net-45."

Refactor internal/payments for readability. Job spec: GOAL: reduce the 3 near-duplicate charge-retry code paths to one. BOUNDARIES: - Do NOT change any exported function signature (other packages depend on them) - Do NOT add new dependencies - Don't touch internal/payments/webhooks.go — mid-migration by another engineer DEFINITION OF DONE: - `go test ./internal/payments/...` passes with no test edits, except adding coverage for the unified retry path - `git diff --stat` under ~300 lines PROCESS: first reply with a short plan — files you'll change, the unified design, risks. Wait for my OK before editing.

Fix exactly one bug: users with a + in their email ([email protected]) get 'invalid email' at login. Repro: `curl -s localhost:8080/auth/login -d '{"email":"[email protected]", ...}'` → 400. SCOPE: the fix plus a regression test. Nothing else — no drive-by refactors, no formatting other files, no 'while I was here'. If you find the root cause is bigger than the validator (e.g. it's mangled at ingestion), STOP and report instead of fixing beyond scope. DONE: the curl above returns 200; new test covers + emails; full test suite still green.

Two contracts follow, tagged <contract-A> (our current vendor) and <contract-B> (proposed replacement). TASK PREVIEW (details after the documents): compare liability & indemnification. <contract-A> [80 pages] </contract-A> <contract-B> [75 pages] </contract-B> TASK: 1. From each contract, quote verbatim every clause about liability caps, indemnification, and exclusions — with its section number. 2. Build a side-by-side table from those quotes only. 3. Flag anything present in one contract but absent in the other — absence is a finding. 4. End with: which sections of either document you did not read closely. If a topic isn't covered in the quotes you found, say 'not found' — do not summarize from memory of typical contracts.

40 source files follow, each preceded by === FILE: path ===. [files] TASK: hypothesize why checkout latency doubled. Rules: - Cite evidence as file:line for every claim ('checkout.go:112 acquires the lock inside the loop') - Rank your top 3 hypotheses by likelihood, each with its evidence and the experiment that would confirm it - List the files you treated as irrelevant, in one line - If the cause likely lives in a file NOT provided (config, infra, DB schema), say exactly what you'd need

Research customer-support platforms for a 40-person B2B SaaS (5-seat support team, ~2k tickets/mo, need Slack + Stripe integrations). DECISION: shortlist 3 platforms to trial next month. SCOPE: mid-market tools only (not enterprise Zendesk tiers, not free-only tools); information from the last 18 months; pricing in USD. SOURCES: prioritize current pricing pages, public changelogs, and independent reviews with named authors; G2/Capterra aggregate scores are weak evidence; vendor comparison pages about competitors are claims to verify, not facts. DELIVERABLE: 1. Comparison table: seat price, per-ticket limits, Slack & Stripe integration depth (native/zapier/none), AI-agent features, migration path from Intercom 2. One paragraph per shortlisted tool: strongest fit signal + biggest risk 3. 'Couldn't verify' list with what I should check in sales calls Mark any claim older than 12 months with its date — this market moves fast.

Research the public EV-charging market in Cambodia and Vietnam for a decision on whether a station-locator app should expand there in 2026. ANSWER THESE, in order: 1. Installed public charger counts + 24-month growth, per country (cite primary/government sources where possible; date every figure) 2. Top 3 charging networks per country and whether they expose public APIs or app partnerships 3. Existing locator apps: names, approximate downloads, monetization 4. One regulatory factor that could change the picture within 18 months RULES: separate 'measured' (installed base) from 'projected' (forecasts) — never blend them in one number; if Cambodia data is thin, say so explicitly rather than extrapolating from Vietnam; end with the 3 facts most likely to be wrong and how to check them locally.

We're building HR tech SaaS: applicant tracking, onboarding, document management. State: 3 engineers, 40 beta customers, pre-launch. Deciding: start with a Go monolith or go microservices from day one. Think step by step: Step 1: Operational realities of each approach for 3 engineers with no dedicated DevOps Step 2: Specific features of HR workflows and document management that push toward one or the other Step 3: Migration cost: monolith→microservices in 18 months vs. starting microservices and finding it too complex Step 4: What do companies at exactly our stage (pre-launch, <5 engineers) typically find empirically? Step 5: Recommendation with 2 strongest reasons FOR and 1 strongest counterargument to prepare for Don't give the recommendation before completing all 5 steps.

This Python function calculates compound interest but returns wildly wrong numbers. ```python def compound_interest(principal, annual_rate_pct, years): monthly_rate = annual_rate_pct / 12 total_months = years * 12 return principal * (1 + monthly_rate) ** total_months ``` Test case that fails: - compound_interest(10000, 5, 10) - Expected (5% APY, 10 years): ~$16,470 - Actual result: $2,193,040,000 Work through step by step: 1. Trace what monthly_rate equals when annual_rate_pct=5 (show the arithmetic) 2. Compare to what monthly_rate should be for a 5% annual rate 3. Identify the exact bug in one sentence 4. Show the corrected function 5. Show what the corrected function returns for the test case

System: You are a staff-level Go engineer with 14 years of production experience (Cloudflare, HashiCorp). Opinionated, direct, production-focused. When reviewing code: - Quote the exact line(s) before every comment - Label: [CRITICAL] [WARNING] [SUGGESTION] - Explain WHY it's a problem in production, not just that it's wrong - Always show working Go code for fixes — never pseudocode - If the whole design needs rethinking, say so in one sentence, then still review what was given When answering design questions: - Recommendation first, then reasoning - Name tradeoffs explicitly — no pretending there's one right answer - If the answer changes at different scales, say at what inflection point Scope: Go, PostgreSQL, Redis, gRPC, Kubernetes. For ML/frontend: give what you know and recommend a specialist. Style: direct, no pleasantries, efficient.

System: You are a customer success specialist for Vitae, a resume analytics platform. Knowledgeable, efficient, empathetic without being performatively cheerful. Always: - Acknowledge frustration in one sentence before solving - Give numbered steps for how-to questions - If escalating, collect: email, plan tier, browser/OS, exact reproduction steps Never: - Promise features on the roadmap - Share pricing strategy or internal metrics - Discuss Reactive Resume, ResumeLM, or other competitors by name - Guess at an answer — say "let me check on that" when unsure Common issues (use these exact answers): - Export not working: confirm plan tier (Free = 3 exports/month). If paid, ask for browser + steps. - Payment failed: direct to [email protected] — do not troubleshoot payments in chat - CV not updating: hard refresh — Cmd+Shift+R (Mac) or Ctrl+Shift+R (Windows) - Passkey login fails: ask which device — passkeys are device-bound

Parse this email into structured data for our ATS. Return ONLY valid JSON — no markdown backticks, no explanation, no text before or after. Schema (null for missing fields): { "name": string, "email": string, "role_applied": string, "years_experience": number, "current_company": string | null, "salary_expectation_usd": number | null, "earliest_start_date": string | null } Parse "$165-185k" as the midpoint (175000). Parse "available in 4 weeks" as null — can't compute absolute dates. Email: --- Hi, I'm Priya Mehta, reaching out about the Senior Product Designer role. I have 8 years of product design experience, currently at Figma. Looking for $165-185k. Could start in about 4 weeks. LinkedIn: linkedin.com/in/priyamehta ---

Compare AWS, GCP, and DigitalOcean for a production Go API (~50k requests/day, managed PostgreSQL, Redis cache). Return a markdown table ONLY. No intro, no conclusion, no explanation. Columns: Criterion | AWS | GCP | DigitalOcean Rows (include all, in this order): 1. Managed Kubernetes product name 2. Managed PostgreSQL price at 8GB RAM 3. Managed Redis price at 2GB 4. Min viable setup cost/month for our use case 5. Time to first deploy (team new to the platform) 6. Best feature for Go backends (be specific) 7. Biggest operational pain point (be honest) 8. Best suited for (one sentence)

I'm designing a backend for a task management SaaS. Let's maintain a DECISIONS register throughout this conversation. Format for the register: - DECIDED: [thing] — [reason] — [turn #] - OPEN: [thing being discussed] - REJECTED: [thing] — [why] First decision: DECIDED: PostgreSQL as primary datastore — strong relational model for task hierarchies, JSONB for flexible metadata — Turn 1 Now, given PostgreSQL as our primary store, what caching layer makes sense for read-heavy dashboard queries? Consider our constraints: 2-person eng team, hosted on Railway, budget under $50/mo for infrastructure. [Every 4–5 turns]: "Before we continue — here's our current register: DECIDED: PostgreSQL (Turn 1), Redis for caching (Turn 3), REST not GraphQL (Turn 5) OPEN: Authentication approach REJECTED: MongoDB — no relational integrity for task dependencies (Turn 2) Continue with authentication options."

Context handoff from yesterday's session. Paste this at the start of every new session: --- PROJECT: TaskFlow API (task management SaaS) STACK: Go + PostgreSQL + Redis on Railway ROLE: You are a senior backend architect helping me design the API layer. DECISIONS (locked): 1. RESTful API with versioned routes (/api/v1/...) 2. JWT auth with 15-min access + 7-day refresh tokens 3. Pagination: cursor-based, not offset (for real-time task feeds) 4. Rate limiting: 100 req/min per user, Redis token bucket 5. Error format: {"error": {"code": "TASK_NOT_FOUND", "message": "...", "details": {}}} GOTCHAS (things we learned the hard way): - Task dependencies create cycles — we need DAG validation on write - Soft delete only — legal requires 90-day retention TODAY'S GOAL: Design the WebSocket layer for real-time task updates. Constraint: must coexist with the REST API, same auth tokens. --- Start by proposing the event types we need for real-time task updates.

Write a LinkedIn post announcing the launch of Vitae — a resume builder that shows analytics: who opened your resume, which sections they spent time on, which device they used. DO: - Open with a specific pain point real job seekers have (not a generic statement about job searching being hard) - Name one concrete specific thing the product does in the first 3 sentences - End with a question that invites genuine comments DO NOT: - Open with: "Excited to announce", "Thrilled to share", "Today is a big day" - Use: excited, thrilled, proud, humbled, journey, game-changer, revolutionize, passionate, disruptive - Write more than 150 words - Use em-dashes decoratively - End with "link in bio" or "check it out"

There's a bug: when the JWT token has expired, this function panics instead of returning an error. Fix ONLY the nil pointer dereference on the claims access. Do NOT: - Refactor the function structure - Change the function signature or return types - Add new imports - Rename variables or change error messages - Improve anything unrelated to the immediate panic Add one comment explaining why the nil check is needed. ```go func ValidateToken(tokenStr string) (int, error) { token, err := jwt.Parse(tokenStr, keyFunc) if err != nil { return 0, err } claims := token.Claims.(jwt.MapClaims) userID := int(claims["user_id"].(float64)) return userID, nil } ```

Here's a paragraph from my blog post on why engineering retrospectives fail. It's factually correct but too passive and academic — it doesn't land with engineers. My paragraph: "Retrospectives often fail because action items are too vague and unowned. When nobody owns an item, it tends not to get done. Teams lose faith in the process." Rewrite this paragraph to: - Keep my core argument exactly (vague unowned action items = nothing changes) - Make it punchy for an engineering audience that has lived this frustration - Active voice throughout - Do NOT add new claims I haven't made - Stay within 2–4 sentences — I'll keep editing after

I'm writing a technical article with working title: "Why Your PostgreSQL Queries Are Slow (And How to Fix Them)" Target: backend developers with some query optimization experience but who haven't gone deep on execution plans. Goal: get them to read the whole thing and leave with 3 things they can do today. Generate 6 headline variations, each using a different approach: 1. Outcome-focused (what they'll be able to do after reading) 2. Counterintuitive (something surprising about query performance) 3. Specific and numeric (includes a concrete number or percentage) 4. Pain/frustration-based (names a frustration they'll recognize) 5. Classic how-to 6. Single strong word opener Format: numbered list, headline only, one per line. No explanations.

Summarize this UX research paper for a product manager deciding whether to redesign our onboarding flow. They have 3 minutes. Structure as: 1. Core finding (1 sentence — what did this study actually prove, not just suggest?) 2. Methodology quality (1 sentence — sample size, study type, robust enough to act on?) 3. Direct implication for our onboarding (2–3 sentences — what specifically should we change? Be concrete, not theoretical.) 4. Biggest caveat (1 sentence — why might this NOT apply to our specific product?) 5. Verdict: Act on this / Gather more data / Ignore — with one-sentence rationale [paste paper]

Here is the Salesforce Q1 FY2026 earnings call transcript. I'm VP of Sales at a competing CRM. I need to know: are enterprise customers pulling back on CRM spend, and is Salesforce winning or losing in the mid-market? Summarize with this lens only: 1. Enterprise spending signals — what did management say (or avoid saying) about enterprise deal sizes and expansion revenue? 2. Mid-market commentary — any data about companies with 100–500 employees? 3. Analyst skepticism — what did analysts push back hardest on? 4. The thing Salesforce didn't say — what is management avoiding based on what analysts asked? 5. One-sentence intelligence takeaway for my CEO [paste transcript]

Translate this engineering sprint summary into a 5-sentence executive update for our CEO. She's non-technical but reads fast and asks good business questions. Her priorities: Is the product improving? Is the team on track? Does she need to decide or unblock anything? Translation rules: - Replace ALL technical terms: no "API", "refactor", "latency", "deploy", "postgres", "cache" — replace each with a business outcome - Convert metrics to impact: "reduced API p99 by 180ms" → "the dashboard now loads under 2 seconds for all users" - If something is a risk, state the business consequence, not the technical cause - End with EXACTLY ONE ask — what does she need to do? If nothing, write "No action needed from you this week." Sprint summary to translate: [paste your engineering update here]

Translate this internal spec into a developer-facing changelog entry for our API docs. Audience: developers who use our API in production and have been frustrated by unexpected 429 errors without clear feedback. Translation rules: - Lead with the problem it solves FOR THEM, not what we built - Write in second person ("you can now..." not "we have added...") - Replace internal system names with what developers see in API responses - Include: what changed, new response headers or fields they'll see, any action required, what happens if they don't update their integration - Length: under 200 words - Tone: like a senior developer wrote it, not a marketing team Internal spec: [paste the internal spec here]

Step 1 — Research: "List 5 facts about serverless databases in 2025 that would genuinely surprise a senior engineer who uses traditional hosted Postgres. For each: the specific claim, one concrete example (product name, benchmark, or incident), and confidence level: high/medium/low. Omit anything below medium confidence." → Review. Remove low-confidence items. Step 2 — Structure [paste Step 1]: "Create an outline for a 1,200-word technical blog post for senior backend engineers. Sections: hook (why this matters NOW), 3 main insights, practical recommendation. For each section, write one sentence describing the specific argument it makes — not just the topic." → Review. Does each section make a distinct argument? Step 3 — Draft [paste Step 2]: "Write the full blog post following this outline exactly. Technical but not academic. No filler transitions. Include one concrete code example showing the difference between traditional Postgres and Neon serverless connection handling." Step 4 — Thread [paste Step 3]: "Convert this post to a Twitter/X thread. 8–10 tweets. First tweet: a hook that works standalone. Each subsequent tweet: one insight. Final tweet: link CTA. Max 280 chars each."

Step 1 — Extract [once per resume]: "Extract structured data from this resume. Return JSON only: {name, years_exp, current_role, current_company, key_skills[], biggest_red_flag} Resume: [paste one]" → Run for each resume. Review all JSON objects. Step 2 — Score [paste all Step 1 JSON + job spec]: "Score each candidate 1–10 on: technical_fit, seniority_match, trajectory. Return a ranked table: Name | Tech | Seniority | Trajectory | Total | Top_Concern" → Review. Does the scoring match your actual priorities? Step 3 — Brief [top 4 candidates]: "For these 4, write a 3-sentence interviewer brief each: 1. Why they're promising 2. The one thing that needs probing 3. One specific interview question targeting that thing Format as a table."

Audit our AI classification pipeline and produce an optimization plan. Current setup: - Model: Claude Sonnet (mid-tier) - Volume: 10,000 tickets/day - System prompt: 2,800 tokens (includes company history, full product docs, 15 few-shot examples) - User prompt: ticket text, avg 200 tokens - Output: category label + 3-sentence explanation + confidence score (avg 150 tokens) - Processing: one ticket per API call - Monthly cost: ~$4,200 Accuracy: 94% on our eval set (target: ≥92%) For each optimization lever: 1. What to change 2. Estimated cost reduction (percentage and dollar amount) 3. Risk to accuracy (none / low / medium / high) 4. Implementation effort (hours) Constraints: - Accuracy must stay ≥92% - We can't change our ticketing system (Zendesk) - 2-person eng team, max 1 week of work Format: ranked list by impact (highest savings first), then a summary table with cumulative savings.

I have a 3-stage document processing pipeline. Help me pick the optimal model for each stage based on the task requirements. Stage 1 — Document Summarization: - Input: 10–40 page vendor contracts (PDF) - Output: 2-page structured summary (sections: key terms, obligations, risks, renewal dates) - Volume: 50 documents/week - Quality: HIGH — legal team makes decisions based on these summaries - Latency: can wait up to 2 minutes per document Stage 2 — Data Extraction: - Input: the Stage 1 summary - Output: structured JSON (12 fields: vendor name, contract value, start/end dates, auto-renewal Y/N, etc.) - Volume: same 50/week - Quality: MEDIUM-HIGH — feeds a database, errors caught in weekly review - Latency: under 10 seconds Stage 3 — Notification Routing: - Input: the Stage 2 JSON - Output: one of 4 routing labels (legal_review, finance_approval, auto_approve, flag_for_renewal) - Volume: same 50/week - Quality: MEDIUM — humans review the routed items anyway - Latency: under 2 seconds For each stage, recommend: - Model (specific: Claude Opus/Sonnet/Haiku, GPT-5/4o-mini, Gemini Ultra/Flash) - Why this model fits this stage's requirements - Estimated cost per document at this stage - What you'd lose by using a cheaper model Then: total cost per document across all 3 stages.

You are a senior technical recruiter specializing in inclusive hiring. Write a job description for a Senior Software Engineer. Bias-awareness requirements: 1. Use gender-neutral language throughout — no 'he/she', use 'you' or 'they' 2. Focus on skills and outcomes, not personality traits — 'ships reliable code under deadlines' not 'rockstar' or 'ninja' 3. Separate must-have skills (required to do the job) from nice-to-haves (learnable in 6 months) — overloaded requirements lists disproportionately discourage underrepresented applicants 4. Replace 'culture fit' with specific collaboration values: 'gives and receives direct feedback', 'documents decisions for async teammates' 5. Include: 'We encourage applications from candidates who meet most but not all requirements' 6. Avoid coded language that signals demographic preferences: 'young and energetic', 'digital native', 'beer fridge culture' After writing, audit your own output: - Flag any phrase that might discourage qualified candidates from underrepresented groups - Flag any requirement that's actually a preference, not a necessity - Score inclusivity 1–10 and explain what would raise it Company context: Vitae, 15-person remote team, async-first, flexible hours, stack: Go, PostgreSQL, Kubernetes.

You are a fair lending analyst. Evaluate this loan application based ONLY on financial merit. Before analyzing, acknowledge these rules: 1. Base your assessment ONLY on: income, debt-to-income ratio, credit score, employment length, loan amount vs. income multiple 2. DO NOT factor in: name, zip code, employer name, school attended — these are demographic proxies that introduce bias 3. State your assumptions explicitly: 'I'm assuming [X] because [Y]' 4. If the data is insufficient to make a confident assessment, say 'INSUFFICIENT DATA — additional information needed: [list]' — do NOT fill gaps with assumptions 5. Provide the same analysis structure regardless of applicant details — the format shouldn't change based on who's applying Applicant data (financial only): - Annual income: $78,000 - Monthly debt payments: $1,200 - Credit score: 710 - Employment length: 3.5 years at current employer - Loan request: $22,000 personal loan, 36-month term - Existing credit utilization: 34% Analysis format: - Debt-to-income ratio calculation - Credit risk category (low/medium/high) with reasoning - Recommendation: approve / approve with conditions / deny — with specific reasoning - Assumptions stated - Missing data that would improve confidence After analysis, self-check: 'Would my recommendation change if any demographic detail were different?' If yes, the analysis has a bias problem — flag it.