50 Production Prompts

You are a product analyst. I'm researching {{COMPETITOR_NAME}} vs. my product {{MY_PRODUCT}}.

Pull from public sources (landing page, docs, G2/Trustpilot reviews, recent changelog mentions). Build a feature gap matrix with three columns: Feature, {{COMPETITOR_NAME}} behavior, {{MY_PRODUCT}} behavior. Then write a 3-sentence positioning angle based on the gaps.

Focus on features that affect daily workflows for {{TARGET_PERSONA}}.

Stress-test this market size claim: "{{MARKET_CLAIM}}"

Walk me through a bottom-up check using public proxies (industry reports, job posting volume, SaaS revenue benchmarks, analyst estimates). Show your work at each step. Flag where you're estimating vs. where you have a hard number. Close with: does the claim hold, overstate, or understate, and by roughly what factor?

I'm going to paste raw user research notes below. Your job:
1. Extract the top 5 friction points mentioned most frequently (quote the exact user language, don't paraphrase).
2. Identify 2-3 "hidden" problems users described but didn't name directly.
3. Note any contradictions across respondents.
4. Suggest the one product change that would address the most friction points simultaneously.

Raw notes:
{{RESEARCH_NOTES}}

Extract the practical signal from this research paper. I don't need the methodology detail.

Give me:
- The core finding in one sentence, plain English
- 3 specific numbers or effect sizes that matter
- What this changes about how a practitioner should behave
- One thing the paper explicitly does NOT prove (common misreads)

Paper abstract/text:
{{PAPER_TEXT}}

I need to choose between these options for {{USE_CASE}}: {{OPTION_A}}, {{OPTION_B}}, {{OPTION_C}}.

Evaluate each across these criteria: maturity/stability, community support, licensing cost, operational overhead, and fit for {{CONSTRAINT}} (e.g., "must run on-prem", "team is junior", "must handle 10K rps").

Score each 1-5 per criterion. Show the scores in a table, then give a one-paragraph recommendation that accounts for the specific constraint.

{{COMPETITOR_NAME}} just shipped {{PRODUCT_OR_FEATURE}}. I have 20 minutes before a call.

Give me:
1. What they actually built (strip the marketing language)
2. Who this hurts most in the market
3. What it signals about their roadmap direction
4. The fastest counter-move available to us (tactical, this week)
5. Whether this changes our positioning or is noise

Source: {{SOURCE_URL_OR_ANNOUNCEMENT_TEXT}}

Convert this feature description into a phased implementation plan.

Feature: {{FEATURE_DESCRIPTION}}
Stack: {{TECH_STACK}}
Constraints: {{CONSTRAINTS (e.g., "no new dependencies", "must be backward compatible", "ship in 3 days")}}

Output:
- Phase 1: what to build first (the smallest working version)
- Phase 2: what to add once phase 1 is stable
- Data model changes required (table/schema level)
- API changes required (endpoints, request/response shape)
- 3 edge cases to handle in phase 1, not deferred
- Acceptance criteria (how we know it's done)

Scaffold a {{COMPONENT_TYPE}} for {{PURPOSE}}.
Language/framework: {{STACK}}
It must: {{REQUIREMENTS_LIST}}
It must not: {{ANTI_REQUIREMENTS (e.g., "no ORM", "no global state", "no third-party auth")}}

Output the file tree first, then the contents of each file. Add a one-line comment at the top of each file explaining its role. Use real variable and function names, not placeholders.

Review this API design for correctness, consistency, and forward compatibility.

API spec:
{{API_SPEC_OR_OPENAPI_SNIPPET}}

Check for:
1. REST anti-patterns (verbs in URLs, wrong HTTP methods, missing status codes)
2. Naming inconsistencies across endpoints
3. Missing fields that callers will predictably need (think: pagination, timestamps, error envelopes)
4. Breaking change risks if we add features later
5. Security issues in the design (not implementation) -- auth, rate limiting, data exposure

Flag each issue as: MUST FIX, SHOULD FIX, or CONSIDER.

Design a database schema for {{DOMAIN_DESCRIPTION}}.

Requirements:
- {{REQUIREMENT_1}}
- {{REQUIREMENT_2}}
- {{REQUIREMENT_3}}

Output: table definitions with column names, types, nullability, and foreign keys. Then flag:
- Any N+1 query traps in this design
- Any columns that should be indexed from day one
- One denormalization you'd consider if read performance matters more than write consistency

Write a database migration for this change:

Current state: {{CURRENT_SCHEMA_OR_DESCRIPTION}}
Target state: {{TARGET_SCHEMA_OR_DESCRIPTION}}
Database: {{DATABASE_TYPE_AND_VERSION}}

Write:
1. The `up` migration (with transaction wrapping)
2. The `down` migration (true rollback, not a stub)
3. A one-line comment on any step that could lock the table in production
4. Whether this migration is safe to run on live traffic or requires a maintenance window

Generate a code review checklist for this PR description:

{{PR_TITLE_AND_DESCRIPTION}}
Tech stack: {{STACK}}

The checklist should be specific to the risk surface of THIS change. Skip generic items like "does it have tests" -- assume standard practices are already in place. Focus on: edge cases specific to this feature, security considerations relevant to this code path, performance implications of the approach chosen, and rollback/degradation path if this code breaks in production.

I need to refactor {{MODULE_OR_FILE_NAME}}. Here is the current code:

{{CODE}}

Before writing any new code:
1. Identify the 3 highest-risk changes (things most likely to break callers)
2. List all external dependencies this module has (imported modules, env vars, DB tables)
3. List all callers you'd need to update if the interface changes
4. Propose the refactor in phases so each phase leaves the code in a working state
5. What tests must exist before the first change lands?

I'm going to describe a plan. Your job is to argue against it -- not to be balanced, but to find the strongest possible case that this plan fails.

Plan: {{PLAN_DESCRIPTION}}

Find:
1. The single most likely reason this fails within 90 days
2. The assumption that sounds obvious but is probably wrong
3. A competitor or market condition that could invalidate the strategy
4. The resource requirement we're probably underestimating
5. What a smart skeptic would say at the board meeting

Do not soften the critique with "on the other hand." Just the adversarial case.

Threat-model this feature before it ships:

Feature description: {{FEATURE_DESCRIPTION}}
Data it handles: {{DATA_TYPES (e.g., "email, payment intent IDs, OAuth tokens")}}
External systems it touches: {{EXTERNAL_SYSTEMS}}

For each threat: name it, rate likelihood (low/medium/high), rate impact (low/medium/high), and give the specific mitigation. Use the STRIDE framework (Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege).

Read this proposal and list every unstated assumption baked into it. Don't evaluate whether the proposal is good or bad -- just surface what it takes for granted.

Proposal: {{PROPOSAL_TEXT}}

Format: numbered list. For each assumption, note whether it's testable before committing, and if so, how.

It is {{FUTURE_DATE}}. The project {{PROJECT_NAME}} has failed. Not partially -- fully. It's over.

Write a post-mortem from that future vantage point. What went wrong? Work backward from failure to the decisions made now that caused it. Be specific about what the warning signs were and when they appeared.

Project context: {{PROJECT_DESCRIPTION}}

End with: the one decision made in the first 30 days that, if made differently, would have changed the outcome.

Analyze this argument for logical and empirical weaknesses:

Argument: {{ARGUMENT_TEXT}}

Check for:
- Correlation presented as causation
- Cherry-picked timeframe or sample
- Missing base rate
- Survivorship bias
- Unfalsifiable claim
- Conflation of two different populations or metrics

For each flaw found: name it, quote the specific line where it appears, and explain what evidence would actually be needed to make the claim valid.

Review this code for security vulnerabilities. Focus only on real issues, not hypotheticals.

Code:
{{CODE}}

For each issue found:
- Line number (if applicable)
- Vulnerability class (OWASP category)
- Severity: Critical / High / Medium / Low
- Exact exploit path (how an attacker triggers it)
- Specific fix (not "sanitize inputs" -- show the actual code change)

Write a monthly investor update from these raw notes. Tone: direct, confident, no spin. Show the real numbers even when they're bad -- frame them with context, not excuses.

Raw notes: {{RAW_NOTES}}

Structure:
- One-line summary (the thing they need to know first)
- Metrics (MRR, churn, burn, runway -- whatever is in the notes)
- 3 things that went well this month
- 1 thing that didn't (honest)
- What we're focused on next 30 days
- What we need from you (specific ask, or "nothing this month")

Help me prepare for a difficult conversation.

Context: {{SITUATION_DESCRIPTION}}
The other person likely believes: {{THEIR_LIKELY_FRAMING}}
My goal for this conversation: {{DESIRED_OUTCOME}}
What I want to avoid: {{THINGS_TO_NOT_DO_OR_SAY}}

Give me:
1. The opening line (specific words, not a concept)
2. The most important thing to say that I'll probably skip because it's uncomfortable
3. The question that opens dialogue rather than closes it
4. How to handle it if they get defensive
5. How I close the conversation regardless of how it goes

Turn this raw activity log into a clean status update for {{AUDIENCE (e.g., "exec team", "client stakeholder", "board")}}.

Raw log:
{{RAW_LOG}}

Keep it to 150 words max. Use plain language. Lead with status (on track / at risk / blocked), then what's done, what's next, and any decision needed from the reader. No bullet soup -- write it in short paragraphs.

Write a launch announcement for {{PRODUCT_OR_FEATURE}}.

Audience: {{TARGET_AUDIENCE}}
Distribution: {{CHANNEL (e.g., "email list", "Product Hunt", "LinkedIn")}}
The single most important outcome the user gets: {{CORE_VALUE}}
What we are NOT claiming (keep it grounded): {{WHAT_TO_AVOID_OVERSTATING}}

Write the announcement lead (first 2 sentences) and a 3-sentence body. No hyperbole. No "excited to announce." The lead should describe what it does, not how we feel about shipping it.

Write an executive summary of this document for an audience that has 3 minutes and will make a decision based on what they read.

Document:
{{DOCUMENT_TEXT}}

Structure:
- Context (1 sentence: why this document exists)
- Findings (3 bullets: the things that matter)
- Recommendation (1 specific action with owner and timeline)
- What happens if we don't act (1 sentence)

Cut anything that doesn't inform the decision. Under 200 words.

Write a PR/FAQ for this proposed initiative.

Initiative: {{INITIATIVE_DESCRIPTION}}

Press release section: write the announcement as if the initiative succeeded and you're announcing it one year from now. 2 paragraphs. Specific about the outcome.

FAQ section: write the 5 hardest questions a skeptic would ask, then answer them honestly. Don't soften the answers. If you don't know the answer, say so explicitly.

Convert these messy notes into structured OKRs for {{TIME_PERIOD (e.g., "Q3 2026")}}.

Notes:
{{RAW_NOTES}}

Rules for this output:
- 2-3 objectives max (if the notes imply more, flag the ones to cut)
- 3 key results per objective, each measurable with a number
- Key results describe outcomes, not activities (not "run 5 experiments" -- "increase conversion rate from X% to Y%")
- Flag any goal in the notes that is NOT a good key result and explain why

Triage my week. Here is everything on my plate:

{{TASK_LIST_OR_BRAIN_DUMP}}

Context: my primary goal this week is {{WEEKLY_GOAL}}. My biggest constraint is {{CONSTRAINT (e.g., "only 20 hours available", "waiting on external decision by Wednesday")}}.

Output:
- Top 3 (do these before anything else -- explain why each one is in the top 3)
- Defer list (things to explicitly postpone -- with a suggested date)
- Delete/delegate list (things that shouldn't be on my plate)
- One thing I'm probably avoiding that should be in the top 3

Build a 2-week sprint plan from this feature list.

Feature list:
{{FEATURE_LIST}}

Team: {{TEAM_SIZE_AND_COMPOSITION}}
Constraints: {{CONSTRAINTS (e.g., "one dev is part-time this sprint", "release is on Friday week 2", "can't touch the payments module until audit is done")}}

Output: sprint goal (one sentence), prioritized ticket list with rough t-shirt sizing, dependencies called out, and what gets cut if the sprint is over-committed (recommend the cut explicitly).

Build a decision matrix for this choice.

Decision: {{DECISION_DESCRIPTION}}
Options: {{OPTION_LIST}}
What matters most to us: {{VALUES_OR_CRITERIA (e.g., "speed to market, team morale, cost, reversibility")}}

Weight the criteria by importance (you decide the weights based on what I told you matters). Score each option 1-5 per criterion. Show the weighted totals. Then write a one-paragraph recommendation that accounts for anything the matrix can't capture (gut check, political factors, information gaps).

Build a strategic narrative from this data.

Data: {{DATA_POINTS_OR_METRICS}}

Audience: {{AUDIENCE}}
Decision they need to make or belief you need to shift: {{GOAL}}

Structure: situation (what the data says is happening), complication (what makes this harder than expected), resolution (what we do about it). One paragraph per section. Under 250 words. Lead with what's true, not what's encouraging.

Write a hiring scorecard for this role.

Role: {{ROLE_TITLE}}
What this person owns: {{RESPONSIBILITIES}}
Must-haves (non-negotiable): {{MUST_HAVES}}
Nice-to-haves: {{NICE_TO_HAVES}}

For each criterion: define what "below bar," "meets bar," and "exceeds bar" looks like in concrete behavioral terms. Include 2 interview questions per criterion that would actually reveal where a candidate falls.

I'm seeing this error in {{SYSTEM_OR_SERVICE}}:

{{ERROR_MESSAGE}}

Context:
- When it started: {{WHEN}}
- What changed recently: {{RECENT_CHANGES}}
- Frequency: {{FREQUENCY (e.g., "every request", "randomly 5% of the time")}}

Give me:
1. Top 3 most likely root causes, ordered by probability
2. For each: the exact check or command that would confirm or rule it out
3. Any red herrings I should NOT chase first
4. Whether this looks like a regression, environment issue, or data issue

Triage this stack trace. Find the actual failure, not the symptom.

Stack trace:
{{STACK_TRACE}}

Tell me:
1. The line where the error actually originates (not where it's caught)
2. What the code was trying to do at that line
3. The most likely class of problem (null reference, network timeout, type mismatch, permissions, etc.)
4. What information is missing from this trace that would help confirm the root cause
5. The fastest path to reproduce this locally

This {{COMPONENT_OR_ENDPOINT}} is slow. Help me diagnose it before I start profiling.

Symptoms:
- P50 latency: {{P50}}
- P99 latency: {{P99}}
- Traffic volume: {{VOLUME}}
- When it got slow: {{TIMELINE}}

Architecture context: {{BRIEF_ARCHITECTURE_DESCRIPTION}}

Give me the most likely bottlenecks in order of probability, the query or profile I should run first to confirm each one, and whether this looks like a scaling issue, regression, or design problem.

This test is flaky. Help me find out why.

Test name: {{TEST_NAME}}
Test code:
{{TEST_CODE}}

Failure pattern: {{FAILURE_PATTERN (e.g., "fails 1 in 10 runs", "fails only in CI", "fails after other tests run")}}
Error message when it fails: {{ERROR_MESSAGE}}

Identify the most likely causes of non-determinism in this test. For each: what is the exact source of randomness or timing dependency, and what is the specific fix.

Something broke after {{TRIGGERING_EVENT (e.g., "Friday's deploy", "the Node upgrade", "the config change")}}. Help me narrow the cause.

What's broken: {{BROKEN_BEHAVIOR}}
What it did before: {{EXPECTED_BEHAVIOR}}
Changes made around that time: {{CHANGE_LOG_OR_DIFF_SUMMARY}}

Walk me through a bisection strategy: what's the smallest test I can run to confirm or rule out each change as the cause? Rank the changes by suspicion level based on the symptom.

Analyze this log excerpt for anomalies, patterns, and actionable signals.

Log:
{{LOG_EXCERPT}}

Tell me:
1. Any error or warning patterns that repeat (quote the recurring line)
2. Timeline of events leading to the failure (reconstruct from timestamps)
3. What the system state was just before the failure
4. What I should add to the logging to make the next incident faster to diagnose

Write 5 opening hooks for this piece. None of them should start with "I," "We," or a question. None should use "game-changer," "unlock," or "this is why."

Topic: {{TOPIC}}
Audience: {{AUDIENCE}}
The one thing I want the reader to feel after the hook: {{DESIRED_FEELING (e.g., "recognized", "curious", "slightly uncomfortable because this is about them")}}

Each hook should take a different angle: contrarian, specific-data, narrative, counter-intuitive, and stakes.

Write a detailed outline for a blog post on {{TOPIC}}.

Audience: {{AUDIENCE}}
Angle (the specific take, not just the topic): {{ANGLE}}
What the reader should be able to do after reading: {{OUTCOME}}

For each section: give the section title, the 2-3 specific points it covers, and one piece of evidence or example that should appear in it (real or clearly illustrative). No generic sections like "Introduction" or "Conclusion" -- name every section by its argument.

Write a social post for {{PLATFORM}} on this topic: {{TOPIC}}

Voice notes:
- Write like a person thinking out loud, not a brand
- No bullet lists
- No "hot take:" opener
- The post should make one specific point, not three
- Under 200 words

Here is a sample of my actual writing voice for reference:
{{VOICE_SAMPLE_OR_RECENT_POST}}

Write 3 versions. Label them by tone: direct, vulnerable, and provocative.

Rewrite this ad copy to work as a {{AD_FORMAT (e.g., "Meta feed ad", "Google search ad", "LinkedIn sponsored post")}}.

Original copy:
{{ORIGINAL_COPY}}

What we know about the audience: {{AUDIENCE_INSIGHT}}
The action we want them to take: {{CTA}}

Rewrite rules: lead with the outcome the user gets, not what the product does. Be specific. Cut every word that doesn't move the reader toward the CTA. Write 3 versions: one for someone who has never heard of us, one for someone who looked at our site and left, and one for someone who is already a user and we want them to upgrade.

Write 8 subject lines for this email campaign.

Email topic: {{EMAIL_TOPIC}}
Audience segment: {{SEGMENT}}
Send context: {{CONTEXT (e.g., "re-engagement after 60 days inactive", "announcing a new feature", "last day of trial")}}

Write 2 subject lines in each style: curiosity gap, direct benefit, urgency (honest, not fake), and social proof. Label each. For each subject line, write the single preview text (preheader) that pairs with it. Under 50 chars per subject line.

Outline one newsletter issue for {{NEWSLETTER_NAME}} targeting {{TARGET_AUDIENCE}}.

This week's theme or angle: {{THEME}}
The one thing the reader should take away: {{KEY_TAKEAWAY}}
Tone: {{TONE (e.g., "direct and practical", "conversational and slightly irreverent", "analytical")}}

Outline each section with: section name, what it covers (2-3 sentences), word count target, and the hook sentence that opens that section. Include a closing CTA that feels like a natural extension of the issue, not a tack-on.

Write a meeting agenda for a {{MEETING_TYPE}} meeting. Length: {{MEETING_LENGTH}}.

Goal of the meeting (what decision or output must exist at the end): {{GOAL}}
Attendees and their roles: {{ATTENDEE_LIST}}
Pre-read or context attendees should have before joining: {{PREREQS}}

Structure the agenda so the most important decision gets the most time and the first 5 minutes are not a status recap. Include: time allocation per item, who owns each item, and the specific question each agenda item is trying to answer (not just a topic label).

Turn this brain-dump into a structured onboarding document for someone new to {{ROLE_OR_PROCESS}}.

Brain-dump from the expert:
{{RAW_NOTES_OR_TRANSCRIPT}}

Structure: purpose (why this process exists and what breaks if it's done wrong), step-by-step procedure (numbered, with decision points called out), common mistakes and how to spot them, and "you'll know you did it right when..." (a specific observable outcome).

Write for someone competent but unfamiliar -- skip basics, explain the non-obvious parts.

Write an incident post-mortem from this timeline.

Incident: {{INCIDENT_DESCRIPTION}}
Timeline:
{{INCIDENT_TIMELINE}}

Structure:
- What happened (2-3 sentences, plain language, no blame)
- Timeline (keep it, just clean it up)
- Root cause (the actual technical or process cause -- not "human error")
- Contributing factors (what made this worse or harder to catch)
- Immediate fix vs. long-term fix (separate these)
- 3 action items with specific owners and deadlines
- What we'd do differently if this happens again before the long-term fix is in place

Create a support ticket triage rubric for {{PRODUCT_NAME}}.

Customer types we serve: {{CUSTOMER_TYPES}}
Our SLA commitments: {{SLA_INFO}}
Types of issues we see most often: {{COMMON_ISSUE_TYPES}}

Define 4 priority tiers (P1-P4). For each tier: the definition, examples of tickets that belong there, response time target, who handles it (support, engineering, or account management), and the escalation path if it isn't resolved in time.

Audit this process and find where it's breaking down.

Process description:
{{PROCESS_DESCRIPTION}}

Symptoms we're seeing: {{SYMPTOMS}}
How long the process has existed: {{AGE}}
What changed recently (if anything): {{RECENT_CHANGES}}

Identify: the step most likely causing the symptoms, any steps that are redundant or duplicate work, any handoff points where information is likely lost, and the single change that would have the highest impact with the lowest disruption.

Help me evaluate {{VENDOR_OR_TOOL}} against our needs before the sales call.

What we need it to do: {{REQUIREMENTS}}
Our current solution (if any): {{CURRENT_SOLUTION}}
Non-negotiables: {{MUST_HAVES}}
Red flags that would end the evaluation: {{DEALBREAKERS}}

Give me:
1. The 5 questions I must ask on the call (not the vendor's preferred questions -- the ones they'd rather not answer)
2. What to ask for in the trial or proof-of-concept
3. The hidden costs to probe for (implementation, migration, seat pricing cliffs, support tiers)
4. Reference check questions to ask their customers (not the references they provide -- what to ask once you're on the call)

Facilitate a retrospective for a team that just completed {{CONTEXT (e.g., "a 6-week sprint", "a product launch", "a difficult quarter")}}.

Team: {{TEAM_SIZE}} people, {{TEAM_CONTEXT (e.g., "remote, been together 18 months, high trust")}}
Known tension points: {{KNOWN_TENSIONS (e.g., "scope creep in the last week", "cross-team dependency that slipped")}}

Design a 60-minute retro agenda that gets past surface-level feedback. Include: the opening prompt (replaces "what went well"), 2-3 exercises to draw out systemic issues rather than one-off complaints, a method for prioritizing what to actually fix, and how to close with commitments that won't be forgotten by next sprint.