50 Best Claude Prompts in 2026: Copy-Paste Templates for Every Task

<role>You are a senior content strategist who writes for a technical 
audience. You prioritize clarity over cleverness and substance over word count.</role>

<task>Write a blog post about [TOPIC].</task>

<requirements>
- Length: 1,500-2,000 words
- Audience: [TARGET READER — e.g., mid-level software engineers]
- Include at least 3 specific, concrete examples (not hypothetical)
- Use ## for section headers, short paragraphs (3-4 sentences max)
- Open with a hook that states the key insight, not a generic introduction
- Close with a practical takeaway the reader can use today
- Tone: direct, slightly opinionated, no hedging language
</requirements>

<avoid>
- "In today's rapidly evolving landscape" or any similar filler opening
- Bullet-point lists longer than 5 items
- Explaining concepts the target audience already knows
- Generic conclusions that restate the introduction
</avoid>

<task>Write a [NUMBER]-email sequence for [GOAL — e.g., onboarding new SaaS trial users].</task>

<context>
Product: [PRODUCT DESCRIPTION]
Audience: [WHO THEY ARE]
Key action we want: [CONVERSION GOAL]
Sending cadence: [e.g., Day 0, Day 2, Day 5, Day 7, Day 10]
</context>

<email_format>
For each email, provide:
- Subject line (under 50 characters, no clickbait)
- Preview text (under 90 characters)
- Body (100-150 words, conversational, one CTA only)
- Goal of this specific email
- Why it's positioned at this point in the sequence
</email_format>

<rules>
- Each email should stand alone — don't assume they read the previous one
- No "just checking in" emails — every email delivers value
- CTA should feel like a natural next step, not a hard sell
- Voice: helpful expert, not pushy salesperson
</rules>

<role>You are a technical writer creating documentation for developers. 
You believe good docs show, then explain — code first, prose second.</role>

<task>Write documentation for [FEATURE/API/TOOL].</task>

<structure>
1. One-sentence description of what it does
2. Quick start code example (copy-paste ready, works as-is)
3. Parameters/options table (name, type, default, description)
4. 2-3 real-world usage examples, increasing in complexity
5. Common gotchas or FAQs (3-5 items)
6. Related features or next steps
</structure>

<context>
[PASTE THE RELEVANT CODE, API SPEC, OR TECHNICAL DETAILS HERE]
</context>

<rules>
- Code examples must be complete and runnable — no pseudocode
- Use real-world variable names, not foo/bar/baz
- If something can fail, show error handling in at least one example
- Don't explain what a function does if the name makes it obvious
</rules>

<task>Rewrite the following text to match the specified tone while 
preserving all factual content and key arguments.</task>

<original_text>
[PASTE TEXT HERE]
</original_text>

<target_tone>[TONE — e.g., "conversational and direct, like explaining 
to a smart friend over coffee" or "formal and precise, suitable for 
an academic journal"]</target_tone>

<rules>
- Keep every factual claim from the original
- Preserve the argument structure and logical flow
- Change vocabulary, sentence length, and voice to match the target tone
- If the original has jargon that doesn't fit the new tone, replace or define it
- Maintain approximately the same word count (within 15%)
</rules>

<task>Write product descriptions for an e-commerce listing.</task>

<product>
Name: [PRODUCT NAME]
Category: [CATEGORY]
Key features: [LIST 3-5 FEATURES]
Price point: [PRICE RANGE — e.g., "premium, $150+"]
Target buyer: [WHO BUYS THIS]
Differentiator: [WHAT MAKES IT DIFFERENT FROM COMPETITORS]
</product>

<deliverables>
1. Headline (under 10 words, benefit-focused)
2. Short description (25-30 words for search results / cards)
3. Long description (150-200 words with features woven into benefits)
4. 5 bullet points for the feature list (start each with a verb)
</deliverables>

<rules>
- Write about what the buyer experiences, not what the product has
- No superlatives without justification ("best-in-class" banned unless you explain why)
- Include one sensory detail (how it feels, looks, sounds in use)
</rules>

<role>You are the editor of a weekly newsletter about [TOPIC] with 
[NUMBER] subscribers. Your readers are [AUDIENCE DESCRIPTION].</role>

<task>Write this week's newsletter issue.</task>

<content_to_cover>
- [STORY/TOPIC 1]
- [STORY/TOPIC 2]
- [STORY/TOPIC 3]
</content_to_cover>

<format>
- Subject line: punchy, under 50 chars, creates curiosity
- Opening: 2-3 sentences of personal/editorial perspective
- Main sections: 3 items, each with a bold headline, 2-3 paragraph summary, 
  and a "why it matters" takeaway
- Closing: one recommendation (book, tool, article) and a one-line sign-off
- Total length: 600-800 words
</format>

<voice>Like a smart friend who reads everything so you don't have to. 
Opinionated but fair. Occasionally funny, never trying too hard.</voice>

<task>Transform these job responsibilities into achievement-oriented 
resume bullet points.</task>

<raw_experience>
[PASTE JOB DUTIES, PROJECTS, OR ROUGH NOTES HERE]
</raw_experience>

<rules>
- Start each bullet with a strong past-tense action verb (Led, Built, Reduced, etc.)
- Include specific numbers wherever possible (%, $, time saved, team size)
- Format: [Action] + [what you did] + [measurable result]
- If no number is available, describe scope (team size, user base, system scale)
- 1 line per bullet, 15-25 words each
- Write 3-5 bullets per role
- Order by impact, not chronology
</rules>

<example>
Weak: "Responsible for managing the company blog"
Strong: "Grew company blog traffic from 5K to 45K monthly visitors in 8 months by implementing a data-driven content strategy targeting long-tail keywords"
</example>

<task>Create [NUMBER] social media posts for [PLATFORM] about [TOPIC/PRODUCT].</task>

<brand_context>
Brand: [BRAND NAME]
Voice: [DESCRIBE — e.g., "witty, informed, slightly sarcastic but never mean"]
Audience: [WHO FOLLOWS THIS ACCOUNT]
Goal: [ENGAGEMENT / TRAFFIC / AWARENESS / CONVERSIONS]
</brand_context>

<format_per_post>
- Hook (first line that stops the scroll)
- Body (2-4 short paragraphs, or thread if Twitter/X)
- CTA (what you want the reader to do)
- Hashtags: [NUMBER] relevant hashtags
</format_per_post>

<rules>
- Each post should work standalone — no "as I mentioned yesterday" references
- Vary the formats: question, hot take, list, story, data point
- No emoji spam (2 max per post)
- Don't start any post with "Did you know..."
</rules>

<task>Write a customer case study based on the following raw information.</task>

<raw_info>
[PASTE INTERVIEW NOTES, METRICS, QUOTES, OR ROUGH DETAILS HERE]
</raw_info>

<structure>
1. **Headline**: "[Customer] achieved [result] with [Product]" format
2. **Snapshot**: Company name, industry, size, challenge, result (5-line summary box)
3. **Challenge**: What problem were they facing? (150-200 words)
4. **Solution**: How did they implement the product? (200-250 words)
5. **Results**: What changed? Specific metrics. (150-200 words)
6. **Quote**: One pull-quote from the customer (or draft one that sounds natural for approval)
7. **What's Next**: Future plans with the product (2-3 sentences)
</structure>

<rules>
- Lead with the result in the headline — the story hooks on the outcome
- Use the customer's actual words wherever raw quotes exist
- Quantify everything that can be quantified
- Don't make the product the hero — the customer is the hero
</rules>

<task>Edit the following text for [FOCUS — choose: clarity, conciseness, 
grammar, persuasiveness, or all].</task>

<text>
[PASTE TEXT HERE]
</text>

<instructions>
- Make edits directly in the text (don't just list suggestions)
- After the edited version, provide a brief changelog: list the 5-10 
  most significant changes you made and why
- Preserve the author's voice — edit, don't rewrite
- Flag any factual claims that seem questionable (mark with [VERIFY])
- If sentences can be cut entirely without losing meaning, cut them
</instructions>

<task>Review this code for bugs, security issues, performance problems, 
and readability.</task>

<code language="[LANGUAGE]">
[PASTE CODE HERE]
</code>

<context>[WHAT THIS CODE DOES AND WHERE IT RUNS — e.g., "This is an 
Express middleware that handles JWT authentication in a Node.js API 
serving ~10K requests/minute"]</context>

<review_format>
For each issue found:
1. **Severity**: Critical / Warning / Suggestion
2. **Line(s)**: Which lines are affected
3. **Issue**: What's wrong (one sentence)
4. **Fix**: The corrected code
5. **Why**: Why this matters (one sentence)

After the issue list, provide an overall assessment (3-5 sentences) 
and rate the code: Ship It / Needs Changes / Needs Rewrite.
</review_format>

<task>Write a [LANGUAGE] function and its tests.</task>

<specification>
Function name: [NAME]
Input: [DESCRIBE INPUTS WITH TYPES]
Output: [DESCRIBE EXPECTED OUTPUT WITH TYPE]
Behavior: [DESCRIBE WHAT IT SHOULD DO]
Edge cases to handle: [LIST THEM]
</specification>

<requirements>
- Include JSDoc/docstring with parameter descriptions
- Handle errors explicitly — no silent failures
- Write tests for: happy path, edge cases, and error conditions
- Tests should use [FRAMEWORK — e.g., Jest, pytest, Go testing]
- Each test should test one thing and have a descriptive name
</requirements>

<context>[ANY RELEVANT CONSTRAINTS — e.g., "This runs in a browser, 
no Node.js APIs available" or "Must be compatible with Python 3.9+"]</context>

<task>Diagnose this error and provide a fix.</task>

<error>
[PASTE THE FULL ERROR MESSAGE AND STACK TRACE]
</error>

<code language="[LANGUAGE]">
[PASTE THE RELEVANT CODE — include surrounding context, not just the error line]
</code>

<context>
- Runtime: [e.g., Node.js 20, Python 3.12, Chrome 125]
- What triggered it: [e.g., "Happens when a user submits a form with an empty email field"]
- Frequency: [e.g., "Every time" / "Intermittent, about 5% of requests"]
- What I've tried: [LIST WHAT YOU ALREADY ATTEMPTED]
</context>

<instructions>
1. Explain the root cause (not just what the error says — why it happens)
2. Provide the minimal fix
3. If there's a deeper architectural issue causing this, mention it
4. Suggest how to prevent this class of error in the future
</instructions>

<task>Refactor this code to improve readability and maintainability 
without changing its external behavior.</task>

<code language="[LANGUAGE]">
[PASTE CODE HERE]
</code>

<rules>
- Don't change the function signatures or return types
- Don't add new dependencies
- Keep the refactored code in the same language and paradigm
- Explain each change you made in a comment above the changed section
- If you extract helper functions, name them descriptively
- The refactored version should pass all existing tests
</rules>

<priorities>
1. Remove duplication
2. Improve naming (variables, functions)
3. Simplify conditional logic
4. Break up long functions (>30 lines)
5. Add type annotations if missing
</priorities>

<task>Design a REST API endpoint for [FEATURE].</task>

<context>
Application: [WHAT THE APP DOES]
Existing endpoints: [LIST RELEVANT ONES IF APPLICABLE]
Auth: [HOW AUTH WORKS — e.g., "JWT Bearer token, roles: admin, user"]
Database: [DATABASE TYPE AND RELEVANT TABLES/MODELS]
</context>

<deliverables>
1. HTTP method and route path
2. Request format (headers, params, body with TypeScript interface)
3. Response format (success and error cases with TypeScript interfaces)
4. HTTP status codes for each scenario
5. Validation rules for input
6. Authorization check (who can call this)
7. Implementation notes (caching, rate limiting, pagination if applicable)
8. Example curl command
</deliverables>

<task>Optimize this database query for performance.</task>

<query>
[PASTE SQL QUERY OR ORM CODE]
</query>

<context>
Database: [PostgreSQL / MySQL / MongoDB / etc.]
Table sizes: [APPROXIMATE ROW COUNTS FOR RELEVANT TABLES]
Current performance: [e.g., "Takes 3.2 seconds on average"]
Indexes: [LIST EXISTING INDEXES IF KNOWN]
</context>

<instructions>
1. Explain why the current query is slow
2. Provide the optimized query
3. Suggest indexes to add (with CREATE INDEX statements)
4. Estimate the performance improvement
5. Note any tradeoffs (write performance, storage, complexity)
</instructions>

<task>Convert this [SOURCE LANGUAGE] code to idiomatic [TARGET LANGUAGE].</task>

<source_code language="[SOURCE]">
[PASTE CODE]
</source_code>

<rules>
- Don't do a line-by-line translation. Write it the way a [TARGET LANGUAGE] 
  developer would write it from scratch.
- Use standard libraries and idioms of the target language
- Preserve all error handling (adapt to target language patterns)
- Include equivalent type annotations/declarations
- Add comments only where the target language approach differs 
  significantly from the source
- Note any features that don't have a direct equivalent and explain 
  the workaround chosen
</rules>

<task>Build a command-line tool in [LANGUAGE].</task>

<specification>
Name: [TOOL NAME]
Purpose: [WHAT IT DOES]
Commands/Arguments:
  [COMMAND 1]: [DESCRIPTION]
  [COMMAND 2]: [DESCRIPTION]
Options/Flags:
  --[FLAG 1]: [DESCRIPTION]
  --[FLAG 2]: [DESCRIPTION]
</specification>

<requirements>
- Parse arguments using [LIBRARY — e.g., commander, argparse, cobra]
- Include --help output with examples
- Colored output for errors (red) and success (green)
- Exit code 0 on success, 1 on error
- Handle Ctrl+C gracefully
- Include a README.md with installation and usage instructions
</requirements>

<task>Write comprehensive unit tests for this existing code.</task>

<code language="[LANGUAGE]">
[PASTE THE CODE TO TEST]
</code>

<requirements>
- Testing framework: [Jest / pytest / Go testing / etc.]
- Cover: happy path, edge cases, error conditions, boundary values
- Each test should test one behavior and have a clear name that 
  describes the scenario
- Use arrange-act-assert pattern
- Mock external dependencies (database, API calls, file system)
- Aim for high branch coverage — identify untested branches explicitly
- After the tests, list any code paths that are untestable and why
</requirements>

<task>I need to decide between these architectural approaches for [FEATURE/SYSTEM].</task>

<options>
Option A: [DESCRIBE APPROACH A]
Option B: [DESCRIBE APPROACH B]
Option C: [DESCRIBE APPROACH C — if applicable]
</options>

<context>
- Scale: [EXPECTED LOAD / DATA VOLUME]
- Team: [TEAM SIZE AND SKILL LEVELS]
- Timeline: [WHEN THIS NEEDS TO SHIP]
- Existing stack: [CURRENT TECH STACK]
- Constraints: [BUDGET, COMPLIANCE, INTEGRATION REQUIREMENTS]
</context>

<instructions>
For each option, analyze:
1. Pros (be specific — "scales well" isn't enough, say why)
2. Cons (be honest — don't undersell the risks)
3. Implementation effort (person-weeks)
4. Operational complexity (what breaks at 3am?)
5. Reversibility (how hard to switch later?)

Give a clear recommendation with your reasoning. If it depends on 
factors I haven't mentioned, ask about those factors first.
</instructions>

<task>Analyze the following document and provide a structured breakdown.</task>

<document>
[PASTE THE FULL DOCUMENT — Claude handles up to 200K tokens, so don't summarize first]
</document>

<analysis_requested>
1. Executive summary (3-5 sentences)
2. Key claims or arguments (numbered list)
3. Evidence quality: for each key claim, rate the supporting evidence 
   as Strong / Moderate / Weak / Missing
4. Assumptions: what does the document assume but not state?
5. Gaps: what questions does this document not answer?
6. If applicable: who benefits from this narrative?
</analysis_requested>

<task>Conduct a competitive analysis based on the information provided.</task>

<my_product>
[DESCRIBE YOUR PRODUCT/SERVICE]
</my_product>

<competitors>
[LIST COMPETITORS AND WHAT YOU KNOW ABOUT THEM — paste pricing pages, 
feature lists, reviews, or any available data]
</competitors>

<deliverables>
1. Feature comparison matrix (table format)
2. Pricing comparison (normalize to monthly/annual where possible)
3. Positioning map: where each competitor sits on [AXIS 1] vs [AXIS 2]
4. Each competitor's likely target customer
5. Your strongest differentiator
6. Your most vulnerable gap
7. 3 strategic recommendations based on the analysis
</deliverables>

<task>Interpret this data and explain what it means for [BUSINESS/PROJECT].</task>

<data>
[PASTE DATA — CSV, JSON, TABLE, OR DESCRIPTION OF METRICS]
</data>

<context>
What this data represents: [EXPLANATION]
Time period: [WHEN]
What we expected: [WHAT THE HYPOTHESIS WAS]
What decisions depend on this: [WHAT WE'RE TRYING TO DECIDE]
</context>

<instructions>
1. Summarize the key trends in plain language
2. Identify any anomalies or surprises
3. If the data supports or contradicts the hypothesis, state which and why
4. List 3 actionable conclusions
5. What additional data would strengthen the analysis?
6. Present any caveats or limitations of drawing conclusions from this data
</instructions>

<task>Review this legal document and flag important items in plain language.
I understand you're an AI, not a lawyer. I want a first-pass analysis 
to prepare for my attorney meeting.</task>

<document>
[PASTE CONTRACT, TERMS, AGREEMENT, OR POLICY]
</document>

<analysis>
1. What this document actually says in plain English (paragraph summary)
2. Key obligations: what am I committing to? (numbered list)
3. Key rights: what am I entitled to? (numbered list)
4. Red flags: clauses that seem unusual, one-sided, or potentially problematic
5. Missing protections: standard clauses that are absent
6. Defined terms: any terms with definitions that differ from common understanding
7. Questions to ask my attorney (prioritized)
</analysis>

<task>Synthesize these sources into a comprehensive research summary.</task>

<sources>
[PASTE MULTIPLE RESEARCH PAPERS, ARTICLES, OR DATA SOURCES — 
Claude's long context handles them all at once]
</sources>

<deliverables>
1. Overview: what question do these sources collectively address? (2-3 sentences)
2. Consensus: where do the sources agree? (with citations to specific sources)
3. Disagreements: where do they conflict? Present both sides.
4. Methodology comparison: how did different sources approach the question?
5. Strength of evidence: overall, how confident should we be in the conclusions?
6. Gaps: what questions remain unanswered?
7. Annotated bibliography: one-sentence summary of each source's contribution
</deliverables>

<rules>
- Cite specific sources by name/number when making claims
- Distinguish between "Source A found X" and "X is true"
- If a source has obvious methodological limitations, note them
</rules>

<task>Convert these meeting notes into structured action items and a summary.</task>

<raw_notes>
[PASTE RAW MEETING NOTES, TRANSCRIPT, OR RECORDING SUMMARY]
</raw_notes>

<output_format>
**Meeting Summary** (5-7 sentences max)

**Decisions Made:**
- [DECISION]: decided by [WHO], rationale: [WHY]

**Action Items:**
| # | Action | Owner | Deadline | Dependencies |
|---|--------|-------|----------|-------------|

**Open Questions** (things raised but not resolved):
- [QUESTION]: needs input from [WHO]

**Key Discussion Points** (for anyone who wasn't there):
- [TOPIC]: [2-sentence summary of the discussion]
</output_format>

<rules>
- If a deadline wasn't explicitly stated, write "TBD — needs date"
- If an owner wasn't assigned, write "UNASSIGNED — needs owner"
- Don't infer decisions that weren't explicitly made
</rules>

<task>Analyze these survey responses and identify patterns.</task>

<responses>
[PASTE SURVEY DATA — CSV, individual responses, or summary statistics]
</responses>

<context>
Survey purpose: [WHAT WE WERE TRYING TO LEARN]
Respondent profile: [WHO TOOK THE SURVEY]
Sample size: [NUMBER]
Collection method: [HOW IT WAS DISTRIBUTED]
</context>

<analysis>
1. Top themes: what are the 3-5 most common themes? (with frequency)
2. Sentiment distribution: positive / neutral / negative breakdown
3. Surprising findings: anything unexpected?
4. Segments: do different groups (by role, tenure, etc.) have different responses?
5. Strongest signal: what's the single clearest takeaway?
6. Representative quotes: 3-5 verbatim quotes that best capture the themes
7. Recommended follow-up questions for deeper investigation
</analysis>

<task>Analyze these financial figures and provide strategic insights.</task>

<financial_data>
[PASTE FINANCIAL STATEMENTS, REVENUE DATA, BUDGET, OR METRICS]
</financial_data>

<context>
Company/project: [NAME]
Industry: [INDUSTRY]
Stage: [STARTUP / GROWTH / MATURE]
What we're evaluating: [e.g., "Should we raise prices?" or "Is this acquisition target healthy?"]
</context>

<analysis>
1. Key financial metrics (calculate margins, ratios, growth rates)
2. Trends: what direction are things moving?
3. Benchmarks: how do these numbers compare to industry norms?
4. Risk factors: what could go wrong based on these numbers?
5. Opportunities: what do the numbers suggest we should do more of?
6. Bottom line recommendation: clear, actionable guidance
</analysis>

<note>I understand this isn't financial advice. I'm using this as an 
analytical starting point.</note>

<task>Document this process so someone new can follow it without help.</task>

<process_description>
[DESCRIBE THE PROCESS IN WHATEVER FORM YOU HAVE — rough notes, steps 
from memory, scattered documentation]
</process_description>

<output_format>
1. **Process name and purpose** (one sentence)
2. **When to use this process** (trigger conditions)
3. **Prerequisites** (what you need before starting)
4. **Steps** (numbered, with enough detail that someone new can follow)
   - For decision points, use "If X, go to step N; otherwise continue"
5. **Common mistakes** (what goes wrong and how to avoid it)
6. **Checklist** (compressed version for experienced people)
7. **Who to contact** if something goes wrong
</output_format>

<rules>
- Write for someone doing this for the first time
- Don't assume tribal knowledge — if something is "obvious," explain it anyway
- Include time estimates for each major step
</rules>

<task>Conduct a SWOT analysis for [COMPANY/PRODUCT/PROJECT].</task>

<context>
[PROVIDE ALL RELEVANT CONTEXT — company background, market position, 
recent developments, competitive landscape, internal capabilities]
</context>

<format>
For each quadrant (Strengths, Weaknesses, Opportunities, Threats):
- List 5-7 items
- Each item: one-sentence description + one-sentence "so what" 
  (why this matters strategically)
- Rank items within each quadrant by impact (highest first)

Then provide:
- **Top strategic priority**: The single most important thing to 
  act on, considering all four quadrants
- **Biggest blind spot risk**: What could catch us off guard?
- **3 strategic moves**: Concrete actions that leverage strengths 
  against opportunities while mitigating top threats
</format>

<task>Write the [SECTION] section of a business plan.</task>

<business>
Company: [NAME]
What it does: [ONE PARAGRAPH]
Stage: [IDEA / PRE-REVENUE / REVENUE / SCALING]
Target market: [WHO]
Revenue model: [HOW YOU MAKE MONEY]
</business>

<section>[SECTION NAME — e.g., "Market Analysis" or "Go-to-Market Strategy" 
or "Financial Projections"]</section>

<requirements>
- Length: [WORD COUNT]
- Audience: [WHO READS THIS — investors, bank, internal]
- Include specific numbers and market data where relevant
- Tone: confident but honest about risks
- Cite sources for market claims (even if you need to note [source needed])
</requirements>

<task>Help me develop a pricing strategy for [PRODUCT/SERVICE].</task>

<context>
Product: [WHAT IT IS]
Current pricing: [IF ANY]
Costs: [YOUR COST STRUCTURE — COGS, margins, fixed costs]
Competitors: [COMPETITOR PRICES]
Target customer: [WHO]
Value delivered: [WHAT THE CUSTOMER GAINS — time saved, revenue generated, risk reduced]
</context>

<deliverables>
1. Pricing model recommendation (flat / tiered / usage-based / freemium / hybrid)
2. Specific price points with rationale for each tier
3. Anchoring strategy (how to present prices for maximum perceived value)
4. Comparison to competitors (where you sit and why)
5. Potential objections and rebuttals
6. Pricing page copy (headline + tier descriptions)
7. When to revisit pricing (triggers for price changes)
</deliverables>

<task>Write a cold outreach email for [PRODUCT/SERVICE].</task>

<context>
Product: [WHAT YOU SELL]
Prospect: [THEIR ROLE AND COMPANY TYPE]
Pain point: [THE PROBLEM YOU SOLVE FOR THEM]
Proof: [ANY SOCIAL PROOF — case studies, metrics, known customers]
</context>

<rules>
- Subject line: under 40 characters, no spam triggers
- Body: under 100 words total
- Opening line: reference something specific about the prospect or 
  their company (provide a template variable for personalization)
- One clear value proposition — what changes for them
- CTA: low commitment (reply, 15-min call, watch a 2-min demo)
- No "I hope this email finds you well"
- No "I'd love to" — just ask directly
- P.S. line with one additional hook
</rules>

<task>Write a job description for [ROLE] at [COMPANY].</task>

<context>
Company: [BRIEF DESCRIPTION — what you do, size, stage, culture]
Role: [TITLE]
Reports to: [WHO]
Team: [WHAT TEAM, HOW BIG]
Location: [REMOTE / HYBRID / ONSITE + CITY]
Compensation: [RANGE IF SHARING]
</context>

<structure>
1. Opening hook (2-3 sentences — sell the role, not the company history)
2. What you'll do (6-8 bullets — concrete projects, not vague responsibilities)
3. What we're looking for (split into Required and Nice-to-Have — be honest about which is which)
4. What we offer (compensation, benefits, culture — specific, not generic)
5. How to apply
</structure>

<rules>
- Use "you" language, not "the ideal candidate"
- Include at least 2 specific projects or challenges they'd tackle in the first 6 months
- Don't list 15 required skills for a mid-level role
- Avoid gendered language and unnecessary jargon
</rules>

<task>Draft a response to this customer email.</task>

<customer_email>
[PASTE THE CUSTOMER'S EMAIL]
</customer_email>

<context>
Our product: [WHAT WE SELL]
Their account status: [FREE / PAID / ENTERPRISE]
The actual situation: [WHAT'S REALLY GOING ON — is the customer right? 
Is there a known issue? What can we actually do?]
</context>

<rules>
- Acknowledge their frustration before problem-solving
- Be honest about what happened (no corporate deflection)
- Provide a concrete next step with a timeline
- If we messed up, say so plainly
- If the customer misunderstands something, explain clearly without being condescending
- Under 200 words
- Sign off with a specific name, not "The [Company] Team"
</rules>

<task>Help me write OKRs for [TEAM/DEPARTMENT] for [TIME PERIOD].</task>

<context>
Company mission: [WHAT THE COMPANY IS TRYING TO ACHIEVE]
Team: [WHAT THIS TEAM DOES]
Current performance: [WHERE THINGS STAND NOW]
Strategic priorities: [TOP 2-3 COMPANY PRIORITIES THIS QUARTER]
</context>

<rules>
- 3 Objectives maximum (ambitious but achievable)
- 3-4 Key Results per Objective (measurable, with specific numbers)
- Each Key Result should be a metric that moves, not a task to complete
- Bad KR: "Launch the new dashboard" (that's a task)
- Good KR: "Dashboard adoption reaches 40% of active users within 6 weeks of launch"
- Include current baseline for each KR where possible
- Rate each Objective: 0.7 confidence = stretch target = well-calibrated
</rules>

<task>Write a monthly investor update email.</task>

<data>
Key metrics this month:
- [METRIC 1]: [VALUE] (vs [LAST MONTH] and [TARGET])
- [METRIC 2]: [VALUE] (vs [LAST MONTH] and [TARGET])
- [METRIC 3]: [VALUE] (vs [LAST MONTH] and [TARGET])

Highlights: [WHAT WENT WELL]
Challenges: [WHAT DIDN'T GO WELL]
Asks: [WHAT YOU NEED FROM INVESTORS — intros, advice, none]
Next month priorities: [TOP 3]
Cash position: [MONTHS OF RUNWAY / BURN RATE]
</data>

<format>
Keep it under 500 words. Lead with metrics. Be honest about misses — 
investors respect candor over spin. The "Asks" section should be specific 
("We need an intro to a VP of Engineering at a Series B+ company") not 
vague ("We'd love any help you can provide").
</format>

<task>Create an SOP for [PROCESS].</task>

<process_info>
[DESCRIBE THE PROCESS — what triggers it, who does what, tools used, 
common variations, how long it takes]
</process_info>

<sop_format>
**SOP Title**: [PROCESS NAME]
**Version**: 1.0
**Effective Date**: [DATE]
**Owner**: [ROLE]

**Purpose**: Why this process exists (one sentence)
**Scope**: What this covers and doesn't cover
**Prerequisites**: What must be true before starting

**Procedure**:
Step-by-step with screenshots/examples where helpful.
Include decision trees for branching paths.

**Exception Handling**: What to do when things go wrong
**Quality Checks**: How to verify the process was done correctly
**Revision History**: Version tracking table
</sop_format>

<task>Write a feature specification for [FEATURE NAME].</task>

<context>
Product: [PRODUCT NAME]
User need: [THE PROBLEM THIS SOLVES]
Target user: [WHO USES THIS]
Priority: [HIGH / MEDIUM / LOW]
</context>

<spec_format>
1. **Overview**: What and why (3-5 sentences)
2. **User Stories**: 3-5 user stories in "As a [user], I want [action] so that [benefit]" format
3. **Requirements**:
   - Must have (ship-blocking)
   - Should have (expected but deferrable)
   - Nice to have (future iteration)
4. **User Flow**: Step-by-step walkthrough of the primary use case
5. **Edge Cases**: What happens when things aren't ideal
6. **Non-Requirements**: What this feature explicitly does NOT do (prevents scope creep)
7. **Technical Considerations**: Known constraints, dependencies, or integration points
8. **Success Metrics**: How we'll know this feature is working
9. **Open Questions**: Unresolved decisions needing input
</spec_format>

<task>Create a presentation outline for [TOPIC/PURPOSE].</task>

<context>
Audience: [WHO]
Duration: [MINUTES]
Goal: [WHAT SHOULD THE AUDIENCE DO/FEEL/KNOW AFTER]
Key message: [THE ONE THING THEY SHOULD REMEMBER]
Presentation style: [KEYNOTE / BOARDROOM / WORKSHOP / SALES PITCH]
</context>

<deliverables>
For each slide:
1. Slide title
2. Key message (one sentence)
3. Visual suggestion (what should be on the slide)
4. Speaker notes (3-5 bullet points of what to say)

<rules>
- First slide: start with a surprising fact, question, or bold claim — not your name
- Maximum 1 idea per slide
- No slides with more than 6 bullet points
- Include one "audience participation" moment for presentations over 10 minutes
- Build toward the key message — don't front-load it
- End with a specific, actionable CTA — not "any questions?"
</rules>
</deliverables>

<task>Generate [NUMBER] original story premises for [GENRE].</task>

<constraints>
Genre: [GENRE]
Tone: [e.g., dark humor, literary, thriller, heartwarming]
Setting: [ANY PREFERENCE — or "surprise me"]
Length the story would be: [SHORT STORY / NOVELLA / NOVEL]
</constraints>

<for_each_premise>
1. Logline (one sentence that sells the concept)
2. The hook (what makes this premise unusual or compelling)
3. Central conflict
4. Opening scene suggestion (first 100 words of atmosphere)
5. The question the reader keeps reading to answer
</for_each_premise>

<rules>
- No chosen-one narratives unless subverted
- Each premise should be genuinely distinct — don't give 5 variations of one idea
- At least one premise should combine two genres unexpectedly
</rules>

<task>Develop a detailed character for [STORY/PROJECT].</task>

<seed>[WHATEVER YOU HAVE — a name, a role, a single trait, a situation, 
or just "I need a villain for a heist story"]</seed>

<character_profile>
1. **Basics**: Name, age, appearance (3 distinctive physical details, not a full description)
2. **Voice**: How they talk — give a sample line of dialogue
3. **Want vs Need**: What they pursue vs what they actually need (these should conflict)
4. **Wound**: The formative experience that shaped them (show, don't tell)
5. **Contradiction**: The trait that makes them unpredictable
6. **Relationship to power**: How they react when they have authority vs when they don't
7. **Secret**: What they don't want others to know
8. **First impression vs reality**: How they seem on meeting vs who they actually are
</character_profile>

<rules>
- Make them specific, not archetypal
- Give them at least one trait that makes them hard to like AND one that makes them hard to hate
- Their dialogue sample should be distinctive enough to identify them without a name tag
</rules>

<task>Build a setting for [TYPE OF STORY/GAME/PROJECT].</task>

<seed>[STARTING CONCEPT — e.g., "a city where sound is currency" or 
"near-future Mars colony, year 3 of settlement"]</seed>

<worldbuilding_layers>
1. **The Rule**: What's the one foundational difference from our world? 
   Follow its implications rigorously.
2. **Economy**: How do people make a living? What's scarce? What's abundant?
3. **Power structure**: Who's in charge and why do people accept it?
4. **Daily life**: What does an ordinary person's Tuesday look like?
5. **Tension**: What's the fault line — the issue everyone argues about?
6. **History**: Two past events that everyone in this world knows about
7. **Sensory details**: What does this world smell, sound, and feel like?
8. **Map or geography**: Key locations and what they mean socially
</worldbuilding_layers>

<rules>
- Internal consistency matters more than novelty
- The most interesting worldbuilding comes from second-order effects 
  of the foundational premise
- Include one detail that implies a larger story without explaining it
</rules>

<task>Write a dialogue-driven scene between [CHARACTER A] and [CHARACTER B].</task>

<context>
Setting: [WHERE AND WHEN]
Relationship: [HOW THEY KNOW EACH OTHER]
Subtext: [WHAT'S REALLY GOING ON BENEATH THE CONVERSATION]
Goal: [WHAT EACH CHARACTER WANTS FROM THIS EXCHANGE]
</context>

<rules>
- 80% dialogue, 20% action/description beats
- Each character should have a distinctive speech pattern
- No character should say exactly what they mean — the subtext 
  should come through indirectly
- Include at least one moment of silence or interrupted thought
- The power dynamic should shift at least once during the scene
- No speech tags beyond "said" / "asked" — use action beats instead
  ("She set down her glass." not "she said angrily")
- End the scene on a line that recontextualizes the conversation
</rules>

<task>Write a [FORM — sonnet / haiku sequence / free verse / song lyrics] 
about [SUBJECT].</task>

<constraints>
Tone: [e.g., elegiac, playful, furious, tender]
Audience: [WHO IS THIS FOR]
Specific imagery to include: [ANY IMAGES OR METAPHORS YOU WANT]
Specific imagery to avoid: [CLICHÉS OR IMAGES YOU'RE TIRED OF]
</constraints>

<rules>
- If a formal structure (sonnet, villanelle), follow the rules precisely
- Concrete images over abstract statements — show the grief, don't name it
- Every line should earn its place — cut any line that's just filler
- Read it aloud (mentally) — the sound matters as much as the meaning
- Provide 2 versions: one that follows the brief closely, one that 
  takes a creative risk with it
</rules>

<task>Process this data through a multi-step analysis pipeline.</task>

<data>
[PASTE YOUR DATA]
</data>

<pipeline>
Step 1 — Clean: Identify and flag any inconsistencies, missing values, 
or obvious errors. List them.

Step 2 — Categorize: Group the data into [CATEGORIES] based on [CRITERIA]. 
Show the categorization logic.

Step 3 — Analyze: For each category, calculate [METRICS]. 
Present in a table.

Step 4 — Interpret: What do the patterns mean for [BUSINESS QUESTION]?

Step 5 — Recommend: Based on the analysis, what should we do? 
Provide 3 options ranked by confidence.
</pipeline>

<rules>
- Show your work at each step — I want to verify the reasoning, not just the conclusion
- If a step requires assumptions, state them explicitly
- If the data is insufficient for a confident answer, say so at that step
</rules>

<task>Write a system prompt for an AI assistant with the following role.</task>

<role_description>
[DESCRIBE WHAT THE AI ASSISTANT SHOULD DO — e.g., "A customer support 
bot for a SaaS company that handles billing questions, feature requests, 
and bug reports"]
</role_description>

<context>
Company: [COMPANY NAME AND WHAT IT DOES]
Users: [WHO INTERACTS WITH THIS BOT]
Tone: [REQUIRED VOICE]
Limitations: [WHAT THE BOT SHOULD NOT DO — e.g., "never give refunds directly, always escalate"]
</context>

<system_prompt_requirements>
The system prompt should include:
1. Role definition (who the AI is)
2. Tone and personality guidelines
3. Response format preferences
4. Knowledge boundaries (what it knows and doesn't)
5. Escalation rules (when to hand off to a human)
6. Prohibited behaviors (what it must never do)
7. Example exchanges (2-3 showing ideal behavior)
</system_prompt_requirements>

<task>Create a self-study curriculum for learning [SUBJECT].</task>

<context>
Current level: [BEGINNER / INTERMEDIATE / ADVANCED]
Available time: [HOURS PER WEEK]
Duration: [WEEKS/MONTHS]
Learning style: [READING / DOING / VIDEO / MIXED]
Goal: [WHAT I WANT TO BE ABLE TO DO WHEN I'M DONE]
</context>

<curriculum_format>
For each week/phase:
1. Topic and learning objective
2. Resources (specific books, courses, tutorials — with links/titles)
3. Practice exercise (hands-on application)
4. Self-assessment (how to know you've understood it)
5. Time allocation breakdown

Also include:
- Prerequisites check (what should I already know?)
- Milestones (checkpoints every 2-4 weeks with concrete skill demonstrations)
- Common plateaus and how to push through them
- Communities or forums for getting help
</curriculum_format>

<task>Help me make a decision between [NUMBER] options using a structured framework.</task>

<decision>[WHAT I'M DECIDING]</decision>

<options>
Option A: [DESCRIBE]
Option B: [DESCRIBE]
Option C: [DESCRIBE — if applicable]
</options>

<criteria>
[LIST THE FACTORS THAT MATTER TO YOU — e.g., cost, speed, risk, 
quality, learning curve, long-term value]
</criteria>

<instructions>
1. For each criterion, ask me to assign a weight (1-5) — or assign 
   reasonable defaults and let me adjust
2. Score each option against each criterion (1-10) with justification
3. Calculate weighted scores
4. Present a decision matrix table
5. Give your recommendation, including:
   - The clear winner (if any)
   - When you'd pick a different option (scenario-dependent recommendation)
   - What would need to be true for the losing option to win
</instructions>

<task>Improve this prompt to get better results from an AI model.</task>

<original_prompt>
[PASTE THE PROMPT YOU'VE BEEN USING]
</original_prompt>

<context>
Model I'm using: [ChatGPT / Claude / Gemini / Other]
What I'm trying to get: [DESIRED OUTPUT]
What I'm actually getting: [CURRENT OUTPUT AND WHY IT'S NOT RIGHT]
</context>

<instructions>
1. Diagnose: What's wrong with the current prompt? (be specific)
2. Improved version: Rewrite it with fixes applied
3. Annotate: For each major change, explain why it should produce better results
4. Variations: Provide 2 alternative approaches to the same task 
   (different framing, different structure)
5. Testing suggestion: How to A/B test the original vs improved versions
</instructions>