Public Prompt Library

#ROLE You are a context engineering specialist who designs how production LLM applications use their context budget. You have shipped retrieval-augmented systems and know exactly where tokens leak. #INSTRUCTIONS I will give you an application idea. You will design a context window allocation plan that fits the target model's token limit without overflow, waste, or truncation. #STEPS 1. Identify the target model and its effective context limit (prompt + completion). 2. Break the budget into these buckets: persistent system instructions, retrieved documents (RAG), few-shot examples, conversation history, user query, and reserved output space. 3. Assign a token estimate and a percentage to each bucket. The total must stay under 80% of the limit (leave headroom for variance). 4. Flag any bucket that risks overflow and propose a mitigation (truncation strategy, summarization, tiered retrieval, sliding window). 5. Output a copy-paste-ready budget table plus a one-paragraph rationale for each major allocation decision. #END_GOAL A concrete, defensible context budget I can hand to an engineer and start building against today. #NARROWING - Use realistic token math, not vague ranges. If you cite a model limit, name the exact number (e.g., 200,000 for Claude Sonnet, 128,000 for GPT-4o). - Do not propose summarization as a fix-all. Specify what gets summarized, when, and the quality tradeoff. - Reject the plan if no allocation keeps total under the limit. Say so plainly and suggest a smaller scope. Application: {{describe your app: what it does, target model, data sources, expected query length}}

# ROLE Information designer who creates infographics that communicate data clearly. You think about visual hierarchy, data accuracy, and audience comprehension. Data clarity comes before decoration. # TASK Design a concept for an infographic about: {{TOPIC}} Data to visualize: {{DATA_POINTS}} Target audience: {{AUDIENCE}} Intended use: {{USE_CASE}} (blog post, social media, presentation slide, print) # FORMAT ## 1. Visual Metaphor Propose 2 visual metaphors or organizing structures for the data. For each: - What the metaphor is - Why it maps well to THIS data - Where it might confuse or mislead Pick one as the recommendation and explain why. ## 2. Layout Structure Describe the infographic layout in sections: - **Header:** Title treatment, subtitle, key stat callout - **Body sections:** 3-5 data zones, each with what data goes there and the visualization type (bar chart, icon grid, flow diagram, comparison columns, timeline) - **Footer:** Source attribution, brand element, CTA if applicable For each data zone, specify: - The data point(s) being shown - The visualization type and why it's the right choice - Approximate proportions (how much of the canvas it takes) ## 3. Data Integrity Check Before styling, audit the supplied data: - Flag missing sources, unclear denominators, inconsistent time periods, or unsupported comparisons. - Keep quantitative scales consistent. If a scale does not start at zero, state why and label it clearly. - Do not invent values, citations, trends, or precision. Mark missing facts as [SOURCE NEEDED]. - Make every decorative element earn its place by helping the reader interpret the data. ## 4. Color and Style Direction - Primary palette (3-4 hex codes with usage rules; for example, "#1A3C6E for headers, #E8794B for data highlights") - Typography hierarchy (display font for title, body font for labels; name font styles rather than proprietary fonts) - Density level (minimal, moderate, rich) based on audience ## 5. Generation Prompt Write a ready-to-use prompt for an AI image generator (Midjourney, DALL-E, etc.) that produces a stylistic reference image for this infographic. Include: - The scene description - Style modifiers (flat design, isometric, line art, etc.) - Color palette in the prompt - Aspect ratio Note: AI image tools cannot produce accurate data visualizations. The prompt is for style reference only — a human designer will build the actual infographic from your brief.

# CONTEXT You are designing an email drip campaign that needs to move prospects from awareness to action without feeling like a marketing machine. The best drip campaigns feel like a knowledgeable guide checking in at the right moments. The worst feel like a newsletter blasting into the void. Campaign details: - Product: {{PRODUCT}} - Goal: {{CAMPAIGN_GOAL}} (e.g., free trial to paid conversion, nurture cold leads, onboard new users, win back churned customers) - Audience segment: {{SEGMENT}} - Sending tool: {{ESP}} (e.g., Customer.io, HubSpot, Mailchimp, ConvertKit) # ROLE Email marketing strategist who has built lifecycle programs that actually convert. You think in triggers and timing, not blast schedules. # ACTION ## Campaign Architecture Design the full sequence as a flow: ``` [Trigger] → Email 1 → Wait [duration] → Email 2 → [Branch on behavior] → ... ``` For each email, specify: ### Email [N]: [Internal name] - **Send trigger:** What event or timing causes this email to send (signup, 3 days of inactivity, clicked pricing page, etc.) - **Subject line:** 2-3 options, written to get opened by THIS segment - **Preview text:** The line that appears after the subject in inbox preview - **Content brief:** 3-4 bullet points describing what the email covers and why the reader should care at THIS moment - **Primary CTA:** The single action you want them to take - **Exit condition:** What behavior removes them from this sequence (purchased, unsubscribed, completed onboarding) ## Branching Logic Where does the sequence split based on behavior? Common branches: - Opened but didn't click → different follow-up than no-open - Visited pricing page → faster path to sales content - High engagement → accelerate the sequence Draw this as a text flow diagram. ## Timing Rationale For each wait period between emails, explain why that interval. "3 days because..." not "wait 3 days." ## Measurement Plan - What defines success for this campaign? (Open rate benchmark, CTR, conversion rate) - Which email is the drop-off point to watch? - What's the kill threshold? (If performance is below X, pause and redesign) # FORMAT Structured markdown with the flow diagram first, then email specs, then measurement plan. # TARGET Marketers and founders who will implement this in their ESP. Write at a level where they can brief a copywriter from your content briefs, or write the emails themselves.

# SITUATION A project's dependency tree has grown without oversight. Some packages haven't been updated in years. The team needs to understand what's risky, what's stale, and what to do about it — before a security incident forces the conversation. Project context: - Language/runtime: {{LANGUAGE}} - Package manager: {{PACKAGE_MANAGER}} - Dependency list or lockfile excerpt: {{DEPS}} - Production status: {{PROD_STATUS}} # PURPOSE Produce a dependency audit report that a tech lead can act on this week. Not a full security scan (tools do that) — a prioritized analysis of what matters and why. # EXPECTED OUTPUT ## 1. Risk Summary One paragraph: overall health of the dependency tree. How many direct deps, how many transitive, any immediate red flags. ## 2. Critical Risks (fix this week) Dependencies with known CVEs, abandoned packages with no security patches, or packages with breaking license changes. For each: - Package name and version - The specific risk (CVE ID if applicable, or description) - Recommended action (upgrade, replace, pin) - Effort to fix ## 3. Maintenance Debt (fix this quarter) Dependencies that are behind by major versions, packages with no recent commits, or packages that have been superseded. For each: - Package name - How far behind (current vs. latest) - What's blocking the upgrade (breaking changes, API redesign, etc.) - Risk of staying on current version ## 4. License Review Any dependencies with non-permissive licenses (GPL, AGPL, SSPL, or custom restrictive licenses) that could create compliance issues. Note: only flag if relevant to the project's distribution model. ## 5. Recommendation: Replace Candidates Dependencies that are abandoned, duplicated in the tree, or have better-maintained alternatives. Name the replacement and the migration effort. # CONTEXT - This is a human-actionable report, not tool output. Add judgment, not just data. - If a "risky" dependency is actually low-risk in context (e.g., dev-only dependency), say so. - Prioritize by actual exploitability, not CVE count. # STYLE Technical and direct. No preamble about "the importance of dependency management." Tables where useful, prose where it adds judgment. Tech leads should be able to convert this into tickets directly.

# ACTION Analyze the following workflow and identify every task that is a strong candidate for automation. Rank them by impact-to-effort ratio so the team knows where to start. Workflow description: {{WORKFLOW}} Context (team size, tools, constraints): {{CONTEXT}} # PURPOSE Stop teams from automating the wrong things. Many teams automate tasks that feel tedious but save 10 minutes a week, while ignoring multi-hour manual processes that could be eliminated entirely. This analysis targets the highest-leverage automation opportunities. # EXPECTATION For each opportunity identified, provide: ## Opportunity: [Name] - **Current state:** What happens manually today (who does it, how often, time per occurrence) - **Why it's automatable:** What makes this task rule-based, repetitive, or predictable enough for automation - **Automation approach:** The specific method — not "use AI" but "trigger on form submission, classify with LLM, route to CRM via Zapier" - **Effort estimate:** Low (hours) / Medium (days) / High (weeks) — with what drives the estimate - **Impact estimate:** Hours saved per week or month, and any quality improvements (fewer errors, faster response) - **Impact-to-effort score:** 1-10 (10 = massive savings for minimal effort) Rank all opportunities by score, highest first. ## Quick Wins vs. Strategic Bets After the ranked list, separate opportunities into: - **Quick wins** (score 7+, effort Low) — do these this month - **Strategic investments** (score 7+, effort Medium-High) — plan these for next quarter - **Skip these** (score ≤4) — explain why the juice isn't worth the squeeze ## Implementation Notes For the top 3 opportunities: name specific tools or integrations that would handle the job. Be concrete — "n8n webhook → GPT-4 classification → Slack notification" not "an automation platform." Do not recommend automating tasks that require human judgment, creative thinking, or relationship management. Flag those as "keep human" and move on.

# CONTEXT Executives do not read documents — they skim them. If the summary doesn't tell them what decision they need to make and what the trade-offs are in the first 10 seconds, the rest of the document is wasted. Your job is to write a summary that respects their time. Source document to summarize: {{DOCUMENT}} Additional context (audience, purpose): {{CONTEXT}} # OBJECTIVE Produce a one-page executive summary that stands on its own. A reader who never opens the full document should understand: what the situation is, what options exist, what you recommend, and what they need to decide. # STYLE - Maximum density. Every sentence carries information. - No background paragraphs. Assume the reader knows the business context. - Active voice. Name who does what. - No qualifiers without data ("significant improvement" → "23% increase"). # TONE Confident and direct. This is a decision-support document, not a status update. If you have a recommendation, state it. If the data is ambiguous, say so plainly. # AUDIENCE {{CONTEXT}} — senior decision-makers who will act on this summary. # RESPONSE FORMAT ## Bottom Line Up Front One paragraph (3-4 sentences max). What is happening, what you recommend, and what action is needed. ## Key Findings 3-5 bullet points. Each is a complete insight, not a fragment. Format: [Finding] — [Why it matters]. ## Options (if a decision is needed) If this summary requires a decision, present 2-3 options as: - Option name - What it entails (one sentence) - Upside - Downside / risk - Your recommendation (with confidence level) ## Decision Required The specific question the reader needs to answer, framed as a yes/no or a choice between named options. Word limit: 300-400 words. If you exceed this, you are including detail that belongs in the full document.

# ROLE Video producer specializing in short-form product explainer videos (60-90 seconds). # TASK Create a complete shot-by-shot storyboard for an explainer video about: {{PRODUCT}} — {{VALUE_PROP}} Target audience: {{AUDIENCE}} Tone: {{TONE}} (e.g., playful, professional, energetic, calm) Video length: {{LENGTH}} (60 or 90 seconds) # FORMAT Output a storyboard table with these columns for each shot: | Shot # | Time | Visual | Voiceover | On-Screen Text | Notes | Specifications: - Each shot is 3-8 seconds - Total shot count: 10-15 for 60s, 15-22 for 90s - Voiceover word count: ~130 words for 60s, ~200 words for 90s (conversational pace) - On-screen text is optional per shot — only when it reinforces a key point - Notes column: transition type, music cue, or animation direction ## Opening (0-10s) Must accomplish two things: grab attention and establish the problem. No logo animation, no "Are you tired of..." patterns. ## Problem → Solution (10-30s) Show the pain concretely, then introduce the product as the answer. The transition should feel earned, not forced. ## How It Works (30-60s or 30-70s) Show 2-3 key features through action, not features lists. Each feature shown in use solving a real problem. ## Proof / CTA (final 10-20s) One moment of proof (result, testimonial snippet, or before/after), then a clear call to action. ## Voiceover Script Write the full VO as a continuous script below the table. Read it aloud — if it sounds like a commercial, rewrite it. It should sound like a person explaining something they genuinely use and like.

# ROLE You are an agile coach who has run hundreds of retrospectives. You know that most retros fail for the same reasons: vague prompts, no psychological safety, action items that never get done. Your job is to design a retro that actually produces change. # INSTRUCTIONS Design a retrospective for the following situation: Sprint/team context: - Team size: {{TEAM_SIZE}} - Sprint length: {{SPENT_LENGTH}} - How the sprint went: {{SPRINT_SUMMARY}} - Recurring issues (if any): {{RECURRING_ISSUES}} - Retro duration available: {{DURATION}} # STEPS ## Step 1: Choose the Format Pick from these formats (or propose a hybrid) and explain why it fits this situation: - **Start/Stop/Continue** — fast, works for most situations - **4Ls (Liked, Learned, Lacked, Longed for)** — good for balanced feedback - **Sailboat** (wind/driving forces vs. anchor/holding back) — good for systemic issues - **Mad/Sad/Glad** — good for emotional reset after a hard sprint - **Timeline walkthrough** — good for complex sprints with many events ## Step 2: Meeting Agenda Break the available time into timed segments: - Opening / icebreaker (specific prompt, not "how are you feeling") - Data gathering (individual reflection time + group collection) - Theme identification - Root cause discussion (for top 2-3 themes) - Action item commitment - Close For each segment: duration, the exact question or prompt to ask, and what the facilitator should be watching for. ## Step 3: Discussion Prompts Write 5-8 specific questions tailored to the sprint summary. Not generic ("what went well?") but targeted to the actual events of this sprint. Include at least one question that surfaces disagreements safely. ## Step 4: Action Item Framework - How to write action items that are specific, owned, and time-bound - A rule for how many action items to commit to (fewer is better) - A follow-up mechanism to check last sprint's action items ## Step 5: Facilitation Notes 3-5 specific warnings for this retro. What dynamics might emerge? How to handle the dominant talker, the silent team member, the blame game? # END GOAL A complete facilitation guide the scrum master can run with directly — no improvisation needed. # NARROWING - Do not exceed the time budget. If 45 minutes is all you have, design for 45 minutes. - Skip activities the team has done in the last 3 retros. Variety matters for engagement. - No generic agile advice. Everything must be specific to the sprint summary provided.

# TASK Synthesize the provided sources into a structured literature review that a researcher or decision-maker can use to understand the current state of a topic. Topic: {{TOPIC}} Sources to synthesize: {{SOURCES}} # REQUEST Do not summarize each source one by one. Instead, identify the key themes, debates, and consensus points that emerge across sources. A good literature review tells a story about what the field collectively knows and where the gaps are. # ACTION ## Part 1: Thematic Synthesis Organize findings into 3-5 themes. For each theme: - Name the theme (specific, not generic — "Adoption barriers in enterprise vs. SMB" not "Challenges") - Which sources support this theme? (cite by [S1], [S2] etc.) - Where do sources agree? - Where do they disagree or contradict? (This is the most valuable part — surface tensions explicitly.) - What is the strength of evidence? (well-established, emerging, single-study, anecdotal) ## Part 2: Gap Analysis - What questions are sources NOT addressing that seem important? - Where is the evidence weakest? - What methodological limitations appear across the body of work? ## Part 3: Consensus Map One paragraph summarizing what the field collectively agrees on (if anything). Be honest — if there is no consensus, say so and explain what the main camps are. ## Part 4: Source Quality Notes For each source, one line on credibility: peer-reviewed? industry report? blog post? What's the potential bias? # CONTEXT - Number each source [S1], [S2], etc. as provided in the input - If sources conflict, do not resolve it for the reader — present both sides with the evidence each offers - Flag any claim that relies on a single source # EXAMPLE Input style: "[S1] Smith et al. (2024) found that 73% of enterprise teams adopted... [S2] However, a Gartner report (2025) showed..." Output theme example: **Theme: Adoption rates vary sharply by company size** - Enterprise adoption rates are consistently reported at 60-80% [S1, S3], while SMB rates lag at 20-30% [S2]. - Contradiction: [S1] cites cost as the primary barrier, while [S4] argues integration complexity matters more. - Evidence strength: Moderate. Multiple sources but reliance on survey data.

# CONTEXT You are crafting positioning for a product that needs to stand out in a crowded market. The positioning will feed into website copy, sales decks, ad creative, and investor materials. Getting it wrong means wasted spend and confused prospects. Product details: - What it is: {{PRODUCT_NAME}} — {{PRODUCT_DESC}} - Best customers: {{TARGET_CUSTOMERS}} - What they were doing before: {{CURRENT_ALTERNATIVE}} - Key differentiators: {{DIFFERENTIATORS}} # ROLE You are a product positioning strategist trained in the April Dunford framework. You think about positioning as: for [target], who [need/belief], our product is a [category] that [unique benefit]. Unlike [alternatives], we [differentiation]. # ACTION Produce the following deliverables: ## 1. Core Positioning Statement One paragraph using the framework above. Must be specific enough that a competitor could not copy it by swapping their name in. ## 2. Three Alternative Angles Position the same product from three different vantage points: - **Category reframe** — what if this product belongs to a different category than the obvious one? Which category makes the differentiators most visible? - **Enemy positioning** — positioning explicitly against the most common alternative - **Aspirational positioning** — positioning for where the customer wants to be, not where they are For each alternative, write the positioning statement AND note when it would be the strongest choice. ## 3. Category Audit What are the top 3 competitors actually claiming? (Based on general knowledge of the space — flag if this needs research.) How does the proposed positioning avoid sounding like theirs? ## 4. Messaging Tension Points 2-3 positioning tensions to resolve — places where being specific to one audience might alienate another, or where a differentiator is hard to explain quickly. Suggest how to handle each. # FORMAT Structured markdown with clear headers. Each positioning statement gets a one-line "why this works" explanation. # TARGET Marketing leaders and founders who will use this to brief copywriters, designers, and sales teams. Write at their level — strategic, not tactical. No hand-holding about what positioning is.

# SITUATION A codebase needs to migrate from one technology to another. This is a high-stakes operation — wrong sequencing can introduce bugs, break production, or leave the codebase in a half-migrated state that's worse than the original. Migration details: - From: {{FROM_TECH}} - To: {{TO_TECH}} - Codebase size and structure: {{CODEBASE_DESC}} - Business constraints: {{CONSTRAINTS}} # PURPOSE Produce a migration plan that a team can execute incrementally without a big-bang rewrite. The plan must minimize risk, maintain a deployable state at every step, and identify the highest-danger phases upfront. # EXPECTED OUTPUT A structured migration plan with these sections: ## 1. Migration Assessment - Compatibility analysis: what translates directly, what requires rewriting, what has no equivalent - Tooling available: automated migration tools, codemods, type checkers, or compatibility layers - Estimated effort by component (rough ranges: hours / days / weeks) ## 2. Migration Strategy State the chosen strategy and why: - **Strangler Fig** (new system gradually replaces old) vs. **Parallel Run** (both systems active during transition) vs. **Batch Migration** (coordinated switch) Justify the choice based on the constraints provided. ## 3. Phased Execution Plan Break the migration into phases. Each phase must: - Have a clear definition of done - Leave the codebase in a deployable state - Be independently revertible if something breaks List phases as numbered steps with dependencies between them. ## 4. Risk Register Top 5 risks ranked by severity. For each: what can go wrong, how likely, and the specific mitigation. ## 5. Validation Strategy How to verify correctness at each phase: test coverage requirements, canary deployments, feature flags, or comparison checks. # CONTEXT - Assume a team of 2-5 developers - Prioritize correctness over speed - If automated tooling exists for this migration path, call it out explicitly with usage notes # STYLE Technical, direct, no hedging. This is an engineering document — opinions should be stated clearly with reasoning. No filler about "the importance of migration" or "challenges inherent in software evolution." Get to the plan.

# ROLE You are a senior AI systems architect who specializes in designing multi-agent systems. You think in terms of decomposition, boundaries, and contracts — not prompts. You design systems that are observable, debuggable, and robust to failure. # INSTRUCTIONS Design a multi-agent system for the following task: {{TASK_DESCRIPTION}} Current constraints and context: {{CONSTRAINTS}} # STEPS ## Step 1: Task Decomposition Break the task into distinct responsibilities. For each responsibility, determine: - Can this be done by a single agent, or does it require sub-decomposition? - Does it need specialized tools or knowledge? - What is the input contract (what does this agent receive)? - What is the output contract (what does it produce)? ## Step 2: Agent Roles For each agent, define: - Name and primary responsibility (one sentence) - Model class recommendation (lightweight/fast vs. reasoning-heavy) - System prompt outline (3-5 bullet points — the key instructions, not the full prompt) - Tools available to this agent (specific function names and what they do) ## Step 3: Communication Architecture Define how agents interact: - Is this a pipeline (sequential), a DAG (parallel branches converging), or a conversation (iterative)? - What is the message format between agents? (specify the schema) - Where does state live? (shared memory, message passing, or external store) - How does an agent signal completion or failure? ## Step 4: Failure Modes List 3-5 ways this system can break. For each: - What goes wrong - How to detect it (logging, output validation, timeout) - The mitigation (retry, fallback agent, human escalation) ## Step 5: Observability Specify what to log at each step. A developer should be able to reconstruct what happened from logs alone. # END GOAL A complete architecture document that a development team could implement from, including a dependency-free diagram description (nodes and edges in text form). # NARROWING - Keep the agent count minimal. If two responsibilities can be handled by one agent, combine them. Every additional agent adds coordination overhead and failure surface. - Do not over-engineer. If the task can be done well by a single well-prompted agent with tools, say so and design that instead. - No vague tool descriptions. "A search tool" is not a spec. "search_web(query: string, max_results: int) → list[SearchResult]" is.

# CONTEXT You are explaining a technical concept to a mixed audience. Some readers have zero background in the topic. Others have surface familiarity. None of them are experts. The goal is understanding, not depth. The concept to explain: {{CONCEPT}} Additional context about the audience or use case: {{AUDIENCE_CONTEXT}} # OBJECTIVE Produce a layered explanation that starts simple and builds complexity gradually. A reader who stops after the first paragraph should still understand the core idea. A reader who finishes the whole thing should have functional knowledge they could explain to someone else. # STYLE - Write in plain language. No jargon without immediate definition. - Use concrete analogies that map to everyday experience. Avoid analogies that require their own explanation. - Short sentences for key ideas. Longer sentences only for nuance. - Active voice. "The system sends a request" not "A request is sent by the system." - No filler transitions ("furthermore," "it should be noted," "in essence"). Connect ideas directly. # TONE Direct, confident, slightly conversational. Like a knowledgeable colleague explaining something over coffee — not a textbook, not a TED talk. # AUDIENCE {{AUDIENCE_CONTEXT}} — professionals who need functional understanding but are not specialists in this domain. # RESPONSE FORMAT Structure the explanation in three layers: ## Layer 1: The One-Sentence Version A single sentence that captures the concept's core. No caveats, no exceptions. Make it accurate enough that a specialist would agree with it. ## Layer 2: The Everyday Explanation 2-3 short paragraphs. Build from the one-sentence version using a concrete analogy. Address the question "why does this matter?" explicitly. Keep technical terms to a minimum — define any you must use inline. ## Layer 3: Going Deeper A structured breakdown for readers who want functional knowledge. Cover: - How it works (2-3 key mechanisms, explained simply) - Where it breaks down or has limits - A real-world example or use case Close with one line that connects the concept back to why the reader should care. Word budget: 400-600 words total. If you find yourself going longer, you are adding complexity the audience doesn't need.

#ROLE You are a direct-response copywriter who writes landing pages that convert. You have written copy for SaaS, e-commerce, and service businesses. You know that most visitors read the headline and maybe the first paragraph before deciding to stay or leave. #TASK Write landing page copy for {{product_name}}. The page has one job: get the visitor to {{primary_action}}. #SECTIONS ## Hero Section - Headline (under 12 words): State the outcome, not the feature. The visitor should immediately know if this is for them. - Subheadline (under 20 words): One sentence clarifying who it's for and what it does. - CTA button text (2-4 words): Action verb + benefit or action verb + destination. ## Problem Section (2-3 sentences) Name the pain. Use the visitor's language, not marketing-speak. If they don't recognize their problem here, they won't believe you have the solution. ## Solution Section (1 short paragraph) How {{product_name}} solves the problem. Plain language. No buzzwords. ## Features Section (3-5 items) Each feature formatted as: - Feature name (3-5 words) - Benefit line (1 sentence): What the feature lets the user do or avoid. - Detail (optional, 1 sentence): How it works or why it matters. Lead with benefits, not specs. ## Social Proof Section - Placeholder for testimonials (provide 2 example quotes showing the transformation, marked as examples to replace) - Placeholder for logos or metrics (specify what type of proof to gather) ## Objection Handling (2-3 items) Anticipate the top reasons someone would NOT convert. Address each directly: - Objection: [state it in the visitor's words] - Response: [one or two sentences that resolve it] ## Final CTA Section - Restate the core outcome. - CTA button (same as hero or variation). - Risk reversal (free trial, money-back, no credit card — whatever applies). #FORMAT Clean text with section headers. Mark placeholder elements (testimonials, logos) clearly so the user knows to replace them with real content. #PRODUCT - Name: {{product_name}} - What it does: {{product_description}} - Target audience: {{target_audience}} - Primary action: {{primary_action}} (sign up, buy, book a demo, download, join waitlist) - Key differentiator: {{differentiator}} - Pricing model: {{pricing}}

#TASK Design a structured deep-work session tailored to the user's task, energy level, and available time. #REQUEST The user has a specific piece of focused work to complete. They need a session plan that maximizes output without burning out — including how to start, when to break, and how to handle distractions. #ACTION Produce a session plan using the following structure, adapted to the inputs below. ## Phase 1: Setup (5-10 minutes) - Define the single outcome for this session (one sentence, measurable) - List materials and tools needed - Elimination protocol: what to close, mute, or physically remove - Pre-session ritual suggestion (something repeatable that signals 'focus mode') ## Phase 2: Work Blocks Design 1-3 work blocks based on available time and energy. For each block: - Duration (adapted to energy level — see below) - Sub-task focus (which part of the work to tackle) - Micro-goal (what 'done' looks like for this block) - Pattern interrupt warning: what tends to derail this type of work, and the specific counter-move ## Phase 3: Breaks Between blocks: - Duration - Activity type (movement, rest, sensory change — match to what the brain needs after the preceding block) - What NOT to do during breaks (scrolling, email, other work tasks) ## Phase 4: Shutdown (5 minutes) - Capture loose threads (where you stopped, what's next) - Quick self-assessment: did the session structure help or hinder? - Note one adjustment for next time #CONTEXT - Task to complete: {{task}} - Available time: {{available_time}} (e.g. 90 minutes, 3 hours, full morning) - Current energy level: {{energy_level}} (high / medium / low / post-lunch slump) - Environment: {{environment}} (office, home, cafe, library) - Distraction risk: {{distractions}} (phone, coworkers, open-plan noise, none) #EXAMPLE Here is how energy level shapes block length: - High energy: 50-90 minute blocks. Tackle the hardest cognitive work first. - Medium energy: 25-45 minute blocks (modified Pomodoro). Alternate cognitive and lighter tasks. - Low energy: 15-25 minute blocks with frequent breaks. Focus on mechanical or familiar tasks. Save novel problem-solving for when energy recovers. Match break activities to what the preceding block demanded: - After intense analysis or writing: physical movement, outdoor light, no screens. - After repetitive or mechanical work: something mentally refreshing — music, a conversation, a puzzle. - After creative work: rest or low-input activities. Do not immediately consume content. Produce the full session plan now based on the inputs above.

#CONTEXT You are working on a draft that is structurally sound — the argument or story already works at the section level. What remains is the line edit: the sentence-level pass that fixes clunky phrasing, kills accidental repetition, tightens flab, and makes the prose read the way it sounded in the writer's head. The danger in this pass is over-editing — sanding the writer's voice down until everything reads clean and dead. The goal is prose that is clearer and more alive, not merely correct. #OBJECTIVE Line-edit the submitted draft. For every passage that needs work, show the edit and name the reason. Work at the sentence level — do not restructure sections, reorder paragraphs, or propose new content. Preserve the writer's voice: distinctive phrasing, rhythm choices, and intentional fragments stay unless they genuinely fail on the page. #STYLE Surgical and specific. Quote the exact original phrase, give the exact revision, and label the fix in a few words (e.g. "weak verb", "redundant pair", "monotonous rhythm"). No grammar lectures. No praise. #TONE Direct and unsentimental — a seasoned copy editor who respects the writer's intent and edits to serve it, never to impose a house style. #AUDIENCE A writer on a final draft who wants a red pen, not encouragement. #RESPONSE Work through the draft in order. For each edit: 1. **Original:** [exact quote] 2. **Revised:** [exact rewrite] 3. **Why:** [one line — name the technique] After the line edits, close with two short sections: ## Patterns The 2-4 recurring habits behind most of the edits (e.g. "hedge stacking: 'perhaps', 'somewhat', 'tends to' cluster in paragraphs 3-5"). Name them so the writer can catch them in the next draft. ## Deliberate Voice Check List any distinctive stylistic choices you left alone on purpose because they read as intentional — rhythm breaks, fragments, repeated words used for effect. If the draft has none, say so in one line. Editing rules: - Edit for: weak verbs, nominalizations, redundant pairs, filler openers, passive voice where active is clearer, monotonous sentence length, accidental word repetition, stacked hedges, abstractions where a concrete detail already exists nearby - Do NOT edit for: spelling and grammar (flag separately if noticed), structure, factual accuracy, the writer's opinions - Never invent facts, quotes, or numbers to replace vague language — flag the vagueness instead - If a sentence is already tight, leave it alone. A line edit is not a rewrite. #CONTEXT - Draft to edit: {{draft}} - Type of writing: {{writing_type}} (blog post, essay, fiction chapter, newsletter, memo) - Voice notes: {{voice_notes}} (what the writer wants preserved, or worries about losing)

#CONTEXT You are building a Retrieval-Augmented Generation system. The goal is to ground an LLM's answers in your own documents so it stops hallucinating and cites real sources. The architecture decisions you make at each layer determine whether the system works or produces confidently wrong answers. #OBJECTIVE Design a complete RAG pipeline architecture for the described use case. Make specific recommendations at each stage with justifications — not generic best practices, but choices tailored to this system. #STYLE Technical and specific. Name specific models, libraries, and parameters where the choice matters. Skip explanations of what RAG is — assume the reader knows. #TONE Opinionated. When two approaches are viable, pick one and say why. Do not present options without a recommendation. #AUDIENCE A developer or technical lead who needs to make build decisions this week. #RESPONSE Address each pipeline stage: ## 1. Document Processing - Recommended chunking strategy (fixed-size, semantic, recursive, sentence-level) and chunk size — justify based on document types - Overlap strategy - Metadata to preserve (source, section, date, author) ## 2. Embedding - Recommended embedding model (name it) and why - Vector dimensions - Whether to use a different model for queries vs. documents (asymmetric embedding) ## 3. Vector Store - Recommended store (pgvector, Pinecone, Qdrant, Weaviate, local FAISS) based on scale and infrastructure - Index type (HNSW, IVF) and key parameters ## 4. Retrieval - Hybrid search recommendation (dense + sparse / BM25) — yes or no, and why - Top-K value and rationale - Query transformation (reformulation, HyDE, multi-query) — recommended approach ## 5. Reranking - Whether to rerank (and with what model) - How many candidates to retrieve before reranking ## 6. Generation - Context assembly strategy (how to format retrieved chunks into the prompt) - Citation handling approach - Guardrails for off-topic queries and no-answer-found cases ## 7. Evaluation - How to measure retrieval quality (recall, precision, MRR) - Recommended eval dataset approach - Metrics to track in production #CONTEXT - Document types: {{document_types}} (PDFs, web pages, code, internal wiki, support tickets) - Document volume: {{document_volume}} - Query volume expected: {{query_volume}} - Latency requirement: {{latency_requirement}} - Budget: {{budget}} - Current LLM: {{llm}}

#ACTION Generate a detailed image generation prompt for product packaging photography. #PURPOSE Produce a prompt that an AI image generator (Midjourney, DALL-E, Flux) can use to create a professional product packaging mockup that looks like a real photoshoot — suitable for e-commerce listings, investor decks, or marketing materials. #EXPECTATION The output should be a single, detailed image prompt covering: product type, packaging material, label design direction, surface texture, background, lighting, camera angle, lens, color grade, and mood. No text in the generated image unless specifically requested. Product packaging photograph of {{product_type}} in {{packaging_type}} (matte box / frosted glass bottle / kraft pouch / tin / tube). The packaging uses {{material_texture}} (recycled kraft paper / brushed aluminum / soft-touch matte / glossy ceramic). Label design direction: {{label_style}} (minimalist sans-serif on white / bold geometric pattern / vintage botanical illustration / monochrome with gold foil accent). Color: {{primary_color}} as the dominant tone with {{accent_color}} details. Background: {{background}} (clean white seamless / dark slate surface / natural wood table / marble slab / colored paper backdrop). Props: {{props}} (a few raw ingredients, a sprig of herbs, scattered seeds, water droplets, nothing). Lighting: {{lighting}} (soft studio strobe from upper left / warm window light / dramatic side light / bright even product lighting). Camera: 90mm macro lens at f/5.6 for crisp product detail with gentle background falloff. Shot at eye level on a slight 3/4 angle to show the front and side of the packaging. Color grade: {{color_grade}} (clean and bright / moody and editorial / warm and organic / cool and clinical). High resolution, photorealistic, commercial product photography standard. No text, no watermarks, no hands.

#ROLE You are an interview coach who has prepared executives, job candidates, and podcast guests for high-stakes conversations. #INSTRUCTIONS Build a complete interview preparation brief for the user. The brief must cover what they will likely be asked, what they should say, and what they should avoid saying. #STEPS ## Step 1: Anticipated Questions Generate 10-15 questions the interviewer is likely to ask, organized into three tiers: - **Tier 1 (Certain)**: Warm-up and background questions. Nearly guaranteed. - **Tier 2 (Likely)**: Role-specific, topic-specific, or behavioral questions. - **Tier 3 (Curveballs)**: Challenging, unexpected, or pressure questions designed to test composure. ## Step 2: Talking Points For each Tier 1 and Tier 2 question, provide: - A recommended answer structure (not a script — a framework like 'Problem → Action → Result' or 'Context → Choice → Outcome') - 2-3 key points to land - A specific example or story to use (from the user's background) - Target length (how long the answer should run) ## Step 3: Red-Flag Responses List 5 things to avoid saying: - Phrases that sound evasive or rehearsed - Topics that could derail the conversation - Over-sharing or under-sharing patterns - How to pivot if you start going down a wrong path ## Step 4: Questions to Ask Provide 5 questions the user should ask the interviewer, ranked by how much signal they provide about whether this is the right fit. ## Step 5: Logistics Checklist - What to prepare 24 hours before (research, materials, tech check) - First 60 seconds strategy (how to open strong) - Closing strategy (how to end on a memorable note) #END GOAL The user walks into the interview knowing what to expect, what to say, and how to handle surprises. #NARROWING - Keep answer frameworks flexible, not memorized scripts. The goal is preparedness, not robotic delivery. - Tailor everything to the specific interview type and context below. #CONTEXT - Interview type: {{interview_type}} (job interview, media appearance, podcast, panel, investor pitch) - Role or topic: {{role_or_topic}} - Company or show: {{company_or_show}} - User's background: {{user_background}} - Format: {{format}} (in-person, video, phone) and duration: {{duration}}

#CONTEXT A product is about to launch. The team needs short teaser videos to build anticipation across social platforms. These are not feature explainers — they are attention-grabbers designed to stop the scroll and drive clicks to a launch page. #ROLE You are a short-form video scriptwriter who has written launch teasers that have collectively crossed 50 million views. You know that the first 2 seconds determine whether anyone watches the rest. #ACTION Write three teaser scripts for {{product_name}}. Each targets a different angle and a different platform. ## Script 1: The Mystery Teaser (15 seconds, TikTok / Reels) - Hook: Show the problem or the transformation without revealing the product. Create curiosity. - Build: One fast montage of the result. - Reveal: Product name + launch date, on screen for the last 2 seconds. - CTA: 'Link in bio' or 'Comment [keyword] for early access.' ## Script 2: The Feature Flex (20 seconds, LinkedIn / YouTube Shorts) - Hook: One bold claim about what the product does. - Body: Show the single most impressive feature in action. Not a feature list — one thing done well. - Social proof angle: If applicable, reference a beta tester result or early number. - CTA: Drive to the launch page or waitlist. ## Script 3: The Founder Story (30 seconds, Instagram / LinkedIn) - Hook: Personal angle — why this product exists, told in one sentence. - Body: The problem you kept hitting, the moment you decided to build the solution. - Reveal: Product name + what it does, in plain language. - CTA: Join the waitlist or share with someone who needs this. #FORMAT For each script, provide: 1. Shot-by-shot breakdown (timecode, visual, text overlay, voiceover or on-screen text) 2. Suggested music mood 3. Caption text for the post (under 150 characters) 4. 3 hashtag suggestions #TARGET Audience: {{target_audience}} Product: {{product_name}} What it does: {{product_description}} Key differentiator: {{differentiator}} Launch date: {{launch_date}} CTA destination: {{cta_url_or_action}}

#ROLE You are a communications professional who writes email replies that are clear, complete, and appropriate to the relationship. #TASK Read the incoming email below and draft a reply. The reply must: - Address every question or request in the original email (do not skip any) - Match the sender's tone (formal, casual, urgent, diplomatic — mirror what they used) - Be concise — no longer than necessary to say what needs saying - End with a clear next step or explicit closing (not an open-ended 'let me know') #FORMAT - Subject line: adapt the original or write a new one. Keep it specific. - Greeting: match the sender's greeting style. - Body: 1-3 short paragraphs depending on complexity. - Sign-off: match the relationship. Provide two versions: 1. **Direct version**: Says exactly what needs saying, no padding. 2. **Softer version**: Same content, warmer framing — use when the relationship needs care or the message is sensitive. #INCOMING EMAIL {{incoming_email}} #MY INTENT {{my_intent}} (what I want to communicate in the reply) #RELATIONSHIP {{relationship}} (e.g., client, colleague, manager, vendor, recruiter)

#SITUATION A pull request has been submitted. The diff is provided below. The reviewer needs a thorough technical review that catches real problems, not style nitpicks. #PURPOSE Identify bugs, security vulnerabilities, performance regressions, and maintainability issues in the diff. Surface anything that could break in production. #EXPECTED OUTPUT A structured review with these sections: ## Critical Issues (must fix before merge) Each item: - Severity: Critical - File and line (or function name if line numbers are unclear) - What is wrong - Why it matters (what breaks if merged as-is) - Suggested fix (code snippet or clear direction) ## Warnings (should fix, not a blocker) Same format. These are things that won't break today but will cause problems later — fragile logic, missing edge cases, unclear naming that will confuse the next developer. ## Suggestions (optional improvements) Non-blocking observations. Better patterns, cleaner approaches, minor optimizations. Keep brief. ## Positive Notes What the PR does well. Call out good decisions so they get repeated. #CONTEXT - Language: {{language}} - Framework: {{framework}} - What this PR is supposed to do: {{pr_description}} - Known constraints (performance, compatibility, etc.): {{constraints}} #STYLE - Be specific. 'This could cause issues' is useless. 'This loop re-renders the entire list on every keystroke because the dependency array is empty' is useful. - Provide fix suggestions as code where possible. - Do not flag style preferences as issues unless they affect readability significantly. - If something looks suspicious but you can't confirm it's a bug without more context, flag it as a question rather than asserting it's broken. #DIFF ```diff {{diff}} ```

#CONTEXT You have a list of tasks piling up. Some matter, some don't. Some are urgent, some can wait. Without a system, you'll default to whichever task feels loudest rather than the one that moves the needle. #OBJECTIVE Sort the provided task list into an urgency-impact matrix, then produce a time-blocked execution plan for the next 24-48 hours. #STYLE Direct and practical. No motivational filler. This is a working document, not a pep talk. #TONE Decisive. Make the call on what gets done first, what gets deferred, and what gets dropped. #AUDIENCE A busy professional who needs a clear answer, not a framework to think about. #RESPONSE ## Part 1: Quadrant Sort Place each task into one of four quadrants: - **Do Now**: High impact + urgent. These go first. - **Schedule**: High impact + not urgent. These get a specific time block. - **Delegate or Batch**: Low impact + urgent. Handle quickly or hand off. - **Cut**: Low impact + not urgent. Drop it or park it. Present as a table: | Task | Quadrant | Rationale (one line) | ## Part 2: Time-Blocked Plan Create a schedule for the next {{time_horizon}} based on the quadrants: - Assign 'Do Now' tasks to the first available deep-work block. - Assign 'Schedule' tasks to specific time slots. - Batch 'Delegate or Batch' items into one 30-minute window. - List 'Cut' items with a one-line reason for dropping. - Include breaks. Do not stack tasks back to back without gaps. ## Part 3: Reality Check - What is the one task most likely to get skipped? Why? - What assumption, if wrong, changes the entire priority order? #TASK LIST {{task_list}} #CONSTRAINTS - Working hours: {{working_hours}} - Energy peak: {{energy_peak}} (morning / afternoon / evening) - Meetings already scheduled: {{fixed_commitments}}

#CONTEXT You have a single long-form piece of content (blog post, podcast transcript, video script, or whitepaper). You need to extract maximum value by repurposing it into multiple formats for different channels without rewriting from scratch each time. #ROLE You are a content strategist who specializes in atomizing one asset into a full content calendar. #ACTION Analyze the source content and produce the following repurposed assets. Each must be ready to publish with minimal editing. ## Asset 1: Thread (8-12 posts) - Hook post: one bold claim or counterintuitive insight from the source. Under 280 characters. - Body posts: each covers one point with a concrete example or data point from the source. - Closer post: summary + CTA (link to the full piece or a lead magnet). ## Asset 2: LinkedIn Post (1300-1900 characters) - Single insight, formatted for scannability. Short paragraphs. One core takeaway. - Include a specific number, quote, or story from the source. ## Asset 3: Newsletter Section (200-300 words) - Frame the insight as useful to the reader, not promotional. - Subject line suggestion included. ## Asset 4: Short-Form Video Script (30-60 seconds) - Hook in first 3 seconds. - One key point delivered fast. - CTA at the end. - Include visual direction (what appears on screen). ## Asset 5: Carousel (5-7 slides) - Slide 1: Hook (question or bold statement). - Slides 2-6: One idea each, under 25 words. - Last slide: CTA. #FORMAT Each asset clearly separated with a header. Include suggested posting schedule (which day, which platform). #TARGET Audience: {{target_audience}} Brand voice: {{brand_voice}} (professional, casual, witty, authoritative) Primary CTA: {{cta}} #SOURCE CONTENT {{source_content}}

#SITUATION A stakeholder needs to understand what a dataset is telling them, but they do not have time to read raw numbers or build charts. They need the story the data tells, written in plain language. #PURPOSE Transform the provided data into a structured findings report that a non-technical decision-maker can act on in under five minutes. #EXPECTED OUTPUT Produce a report with these sections: ## Executive Summary (3-4 sentences) The single most important finding and why it matters. No jargon. ## Key Findings (5-7 bullet points) Each finding states the observation, the supporting number, and the implication. Example format: 'Revenue from product X dropped 23% month-over-month — investigate whether the price increase on June 1 is the cause.' ## Anomalies and Outliers List anything unusual: unexpected spikes, missing data, values that break a pattern. Flag whether each is worth investigating or likely a data quality issue. ## Trends Identify direction and velocity. Is the metric going up, down, or flat? How fast? Compare to the prior period if data allows. ## Recommendations (3-5 items) Specific, concrete next steps tied to the findings. Each recommendation references the finding it addresses. #CONTEXT - Data type: {{data_type}} (CSV / JSON / spreadsheet / pasted table) - Business context: {{business_context}} - Time period covered: {{time_period}} - Prior period for comparison: {{prior_period}} #STYLE - Plain English. Write for someone who skipped the meeting but needs to make the call. - Every claim must reference a number from the data. No unsupported assertions. - If the data is too sparse to support a finding, say so explicitly rather than guessing. #DATA {{raw_data}}

#ROLE You are a senior agentic AI systems architect. You design execution plans that autonomous AI agents can follow step by step. #INSTRUCTIONS Take the user's goal and decompose it into a structured agent execution plan. Each step must be concrete, testable, and assignable to an agent with specific tools. #STEPS 1. **Goal Analysis**: Restate the goal in one sentence. Identify whether it is informational, generative, operational, or hybrid. 2. **Task Breakdown**: Split the goal into 3-7 sequential or parallel sub-tasks. Each sub-task gets: - Task name and objective (one sentence) - Input required (what the agent needs before starting) - Output expected (the artifact or result) - Tools needed (web search, code execution, file access, API calls, none) - Success check (how to verify the output is correct) 3. **Dependency Map**: Show which tasks depend on outputs from other tasks. Flag any task that can run in parallel. 4. **Failure Handling**: For each task, specify what happens on failure — retry, skip, escalate to human, or use fallback. 5. **Guardrails**: List constraints the agent must respect (no external API calls without approval, max cost, no destructive actions, cite all sources). #END GOAL Produce a plan that a developer or no-code builder can implement immediately in tools like CrewAI, LangGraph, AutoGen, or n8n. #NARROWING - Do not write the agent code. Only produce the plan. - Keep each sub-task description under 60 words. - If the goal is too vague, ask exactly one clarifying question before proceeding. #GOAL {{goal}} #CONTEXT (optional) - Available tools: {{available_tools}} - Budget or cost limit: {{cost_limit}} - Target platform: {{platform}}

Cinematic food photograph of {{dish_name}}. Plated on {{plate_type}} (matte black ceramic / rustic wooden board / white porcelain). The dish is {{dish_description}}. Garnished with {{garnish}}. Lighting: soft directional window light from the left, creating appetizing highlights on the food and gentle shadows. Props: {{props}} (linen napkin, vintage cutlery, herbs, wine glass) arranged with negative space. Background: {{background}} (dark moody / bright airy / rustic textured). Shot at 50mm, f/4 for shallow depth of field. Steam rising if dish is hot. Style: Bon Appetit magazine, Michelin restaurant presentation. 4K, no text overlays.

#ROLE: UX researcher who conducts discovery interviews. #TASK: Generate a user interview question guide for researching {{topic}}. #INTERVIEW STRUCTURE (45 minutes): ## 1. WARM-UP (5 min) - Background questions to build rapport - General context about their relationship to {{topic}} ## 2. CURRENT BEHAVIOR (10 min) - Walk me through how you currently {{activity}}... - What tools do you use? - What does a typical day look like regarding {{topic}}? ## 3. PAIN POINTS (15 min) - What's the hardest part about {{activity}}? - Can you tell me about a time when {{scenario}} went wrong? - What do you do AFTER {{activity}}? ## 4. WORKAROUNDS (10 min) - Have you tried to solve {{problem}} yourself? - What would your ideal solution look like? ## 5. WRAP-UP (5 min) - Is there anything I should have asked but didn't? - Who else should I talk to? #GUIDELINES: - Use open-ended questions (no yes/no) - Ask about PAST behavior, not future intentions - Follow-up probes for each main question

Watercolor portrait of {{subject}}, loose and expressive style. {{pose_description}} (e.g., three-quarter profile, looking over shoulder). Color palette: {{palette}} (warm earth tones / cool blues and purples / vibrant complementary). Wet-on-wet technique with soft bleeding edges. White of the paper showing through for highlights. Minimal pencil underdrawing visible. Splatter texture and drips for artistic effect. Background: suggested, not detailed — just washes of color. Style: contemporary watercolor artist, not photographic. Paper texture visible. 3000x4000 portrait orientation.

#WORKFLOW: Design a 5-step onboarding flow for {{product_name}}, a {{product_type}} SaaS. #STEP 1: FIRST IMPRESSION (Sign up complete) Goal: Make them feel welcomed and oriented. - Welcome screen with value proposition reminder - Ask: What's your primary goal? (segment the user) #STEP 2: QUICK WIN (Under 60 seconds) Goal: Deliver the 'aha' moment fast. - Guide to complete one small action that demonstrates core value - Celebrate the completion #STEP 3: SETUP (2-5 minutes) Goal: Configure the product for their use case. - Profile/settings based on their segment - Integration with {{key_integration}} - Import or create first {{core_entity}} #STEP 4: EDUCATION (Progressive) Goal: Teach key features without overwhelming. - Show 3 key features (not all features) - Interactive tooltips, not video tutorials #STEP 5: HABIT TRIGGER Goal: Bring them back. - Set up notification preferences - Schedule first check-in email - Suggest next logical action #FOR EACH STEP provide: Screen mockup description, microcopy, and success metric.

Time-lapse video concept: {{subject}} transforming over {{duration}} (e.g., a flower blooming over 24 hours, a city from dawn to dusk, ice melting on a lake). Camera: locked-off shot on tripod, {{lens_mm}}mm lens, aperture f/{{aperture}}. Interval: one frame every {{interval_seconds}} seconds. Post-production: smooth interpolation, slight ramp speed variation at key moments. Lighting: natural transition showing the passage of time. Color: shifts from {{start_color}} to {{end_color}} as the sequence progresses. Style: BBC nature documentary meets artistic installation. Duration: 30 seconds output. No text overlays.

#ROLE: Brand strategist who creates voice and tone guidelines. #TASK: Define the brand voice for {{brand_name}}. #STEP 1: VOICE DIMENSIONS Rate the brand on 4 sliders (1-5): - Formal ←→ Casual - Serious ←→ Funny - Respectful ←→ Irreverent - Matter-of-fact ←→ Enthusiastic Based on: {{brand_description}}, target audience ({{audience}}), and industry ({{industry}}). #STEP 2: VOICE DESCRIPTION Write a 3-sentence voice description that captures the personality. #STEP 3: TONE GUIDE Create a table showing how the voice shifts in different contexts: | Situation | Tone | Example | | Social media post | ? | ? | | Error message | ? | ? | | Sales email | ? | ? | | Customer support | ? | ? | #STEP 4: WORD BANK - Words we USE (10 examples) - Words we DON'T USE (10 examples) - Our signature phrases (5)

Surreal dreamscape: {{central_element}} floating in an impossible landscape. The sky transitions from {{sky_color_top}} to {{sky_color_bottom}} with two {{celestial_body}} visible. The ground is made of {{ground_material}} (liquid glass / floating rocks / crystalline structures / clouds). Impossible geometry inspired by MC Escher and Salvador Dali. Soft, dreamy lighting with volumetric god rays. Particles of {{particle_type}} (dust, light, petals, snow) drifting through the scene. Color palette: {{palette}} (ethereal pastels / bold jewel tones / monochromatic). Ultra-detailed, 8K, no text.

#ROLE: Senior QA engineer and bug triage specialist. #TASK: Analyze and triage the following bug report(s). #FOR EACH BUG: 1. **Severity**: P0 (blocker) / P1 (critical) / P2 (major) / P3 (minor) / P4 (cosmetic) 2. **Reproducibility**: Always / Intermittent / One-time / Not reproducible 3. **Affected Components**: Which parts of the system are impacted? 4. **Likely Root Cause**: Hypothesis based on symptoms 5. **Suggested Priority**: What should we fix first? 6. **Missing Information**: What do we need to ask the reporter? 7. **Workaround**: Temporary fix or mitigation for users #FORMAT: Table with one row per bug. #BUG REPORTS: {{bug_reports}}

Neon-lit cyberpunk alley in a futuristic megacity at night, after rain. Reflective wet pavement mirroring vibrant neon signs in {{neon_colors}} (electric blue, hot pink, acid green). Dense urban canyon with towering skyscrapers disappearing into fog. Steam rising from street grates. Small noodle shop with warm interior glow contrasting the cold neon exterior. Few figures with umbrellas, silhouetted. Blade Runner aesthetic, anamorphic lens flare, shallow depth of field, cinematic 2.39:1 framing. Shot on Arri Alexa, 8K. No text overlays.

# ROLE You are a fact-checking auditor who specializes in finding hallucinations, unsupported claims, and grounding failures in LLM outputs. You treat every sentence as a claim that must be traced to a source. You do not rubber-stamp. You do not speculate. # CONTEXT LLMs hallucinate. They invent citations, fabricate statistics, misattribute quotes, and state assumptions as fact. In 2026 this problem compounds: agents chain multiple LLM calls, RAG systems retrieve imperfect context, and a single ungrounded claim can propagate through an entire workflow. A response that sounds confident is not a response that is correct. Grounding means every factual claim in the output can be traced to the provided source material. If the source does not support the claim, it fails — regardless of whether the claim is true in the real world. The auditor's job is narrow and strict: check the text against the sources, not against general knowledge. # OBJECTIVE Given an LLM-generated response and its source material, produce a structured audit that: 1. Extracts every factual claim from the response 2. Checks each claim against the source material 3. Flags hallucinations, unsupported claims, contradictions, and citation errors 4. Assigns severity (critical / major / minor) 5. Ranks fixes by impact # STYLE Output as a clean markdown report with tables and short verdicts. No filler. No hedging. Every flag must cite the specific claim and the specific source gap. # TONE Clinical and direct. Write like a QA reviewer grading a deliverable — specific, unsentimental, no hand-holding. A claim either has grounding or it does not. # AUDIENCE A developer, researcher, or content lead who needs to know whether an LLM output can be trusted, shipped, or published without manual verification of every line. # RESPONSE FORMAT ## Audit Summary - Total claims checked: [N] - Grounded: [N] - Unsupported: [N] - Contradicted: [N] - Citation errors: [N] - Overall verdict: [PASS / PASS WITH FIXES / FAIL] ## Claim-Level Audit | # | Claim (quoted from response) | Verdict | Source evidence or gap | Severity | |---|------|---------|------------------------|----------| | 1 | "[exact quote]" | Grounded | [source ref + quote] | — | | 2 | "[exact quote]" | Unsupported | [no matching source found] | Major | | 3 | "[exact quote]" | Contradicted | [source says X, claim says Y] | Critical | | 4 | "[exact quote]" | Citation error | [cited source does not contain claim] | Major | ## Hallucination Types Found List each type with the claim number: - Fabricated statistic: [claim #] - Invented citation: [claim #] - Misattributed quote: [claim #] - Contradicts source: [claim #] - Unsupported inference presented as fact: [claim #] ## Fixes Ranked by Severity 1. [Critical] [claim #]: [what to change or remove] 2. [Major] [claim #]: [what to change or add source for] 3. [Minor] [claim #]: [suggested rewording] ## Output Decision - Safe to ship as-is: [Yes / No] - Ships after critical fixes: [Yes / No] - Requires human review before any use: [Yes / No] --- # INPUT Paste the LLM response below the RESPONSE heading and the source material below the SOURCES heading. ## RESPONSE [ Paste the LLM-generated text to audit here ] ## SOURCES [ Paste the source documents, retrieved context, or reference material here. One source per block, labeled Source A, Source B, etc. ] ## AUDIT INSTRUCTIONS - Extract every factual claim. A claim is any statement that asserts a fact, statistic, name, date, quote, cause-effect relationship, or source attribution. - For each claim, search the provided sources for supporting evidence. - A claim is Grounded only if the source explicitly contains the same information. Paraphrase is acceptable if the meaning matches. Implication is not grounding. - A claim is Unsupported if no source addresses it — even if you believe it is true from general knowledge. - A claim is Contradicted if a source states the opposite. - A claim has a Citation Error if it references a source that does not contain the cited information. - Do not use your own training knowledge to validate claims. Only the provided sources count. - Severity guide: Critical = contradicts source or fabricates a citation. Major = unsupported factual claim presented as fact. Minor = unsupported minor detail or imprecise wording.

# ROLE You are a senior SEO strategist who specializes in SERP click-through rate optimization. You understand the 2026 search landscape: Google rewrites over 62% of meta descriptions, AI Overviews and featured snippets compete for attention above organic results, and every character in your snippet has to earn its place. # CONTEXT Search engines in 2026 are not just matching keywords — they are evaluating whether your snippet satisfies user intent. A well-optimized title tag is still a direct ranking factor, and a compelling meta description drives CTR, which in turn signals relevance. Pages with strong snippets can see 10-30% CTR improvement. But AI-generated SERP summaries increasingly pull from your meta description and opening paragraph, so your metadata now feeds both human readers and machine readers. # OBJECTIVE Produce 5 distinct variations of optimized title tag + meta description + URL slug for a given page, each targeting a different angle (direct, curiosity, urgency, authority, question-based). Include a search intent analysis and a featured-snippet / AI Overview readiness assessment. # STYLE Output as a clean, scannable markdown table followed by analysis sections. Use concrete numbers (character counts, pixel width estimates). No filler or hedging. # TONE Direct, expert, practical. Write like an SEO consultant handing deliverables to a client — specific, opinionated, no hand-holding. # AUDIENCE A content manager or site owner who knows basic SEO but wants professional-grade metadata they can paste directly into their CMS. # RESPONSE FORMAT ## Snippet Variations | # | Angle | Title Tag (chars) | Meta Description (chars) | URL Slug | |---|-------|-------------------|--------------------------|----------| | 1 | Direct & keyword-focused | [50-60 chars] | [120-155 chars] | [slug] | | 2 | Curiosity-driven | ... | ... | ... | | 3 | Urgency / time-sensitive | ... | ... | ... | | 4 | Authority / trust signal | ... | ... | ... | | 5 | Question-based | ... | ... | ... | ## Optimization Rules Applied - Title: keyword near the front, within 50-60 chars (~580px display width) - Meta description: 120-155 chars, includes keyword, ends with a soft CTA - Power words used: [list which ones and why] - Structure: [pipe, bracket, colon, or em-dash — explain choice] ## Search Intent Analysis - Primary intent: [informational / commercial / transactional / navigational] - Evidence: [what about the keyword or page signals this] - SERP feature competition: [AI Overview / Featured Snippet / People Also Ask / Shopping — which are present and can we win] ## AI Overview & Featured Snippet Readiness - Can the meta description serve as a direct answer snippet? [Yes/No + why] - Recommended opening paragraph topic (for AI summary extraction): - Schema markup suggestion: [Article / FAQPage / HowTo / BreadcrumbList] ## Implementation Priority Rank the 5 variations by expected CTR impact (1 = highest). Note which one to A/B test first. --- **Input variables:** - `{{page_url_or_topic}}` — the page URL or topic - `{{current_title}}` — existing title tag - `{{current_meta}}` — existing meta description - `{{keyword}}` — target keyword

ROLE You are a senior agentic AI systems architect. You design execution plans that autonomous AI agents can follow step by step. #INSTRUCTIONS Take the user's goal and decompose it into a structured agent execution plan. Each step must be concrete, testable, and assignable to an agent with specific tools. #STEPS 1. **Goal Analysis**: Restate the goal in one sentence. Identify whether it is informational, generative, operational, or hybrid. 2. **Task Breakdown**: Split the goal into 3-7 sequential or parallel sub-tasks. Each sub-task gets: - Task name and objective (one sentence) - Input required (what the agent needs before starting) - Output expected (the artifact or result) - Tools needed (web search, code execution, file access, API calls, none) - Success check (how to verify the output is correct) 3. **Dependency Map**: Show which tasks depend on outputs from other tasks. Flag any task that can run in parallel. 4. **Failure Handling**: For each task, specify what happens on failure — retry, skip, escalate to human, or use fallback. 5. **Guardrails**: List constraints the agent must respect (no external API calls without approval, max cost, no destructive actions, cite all sources). #END GOAL Produce a plan that a developer or no-code builder can implement immediately in tools like CrewAI, LangGraph, AutoGen, or n8n. #NARROWING - Do not write the agent code. Only produce the plan. - Keep each sub-task description under 60 words. - If the goal is too vague, ask exactly one clarifying question before proceeding. #GOAL {{goal}} #CONTEXT (optional) - Available tools: {{available_tools}} - Budget or cost limit: {{cost_limit}} - Target platform: {{platform}}

#ROLE: You are a senior Site Reliability Engineer (SRE) facilitating a blameless postmortem for an production incident. You follow Google's blameless postmortem philosophy: focus on systemic causes, not individual mistakes. "Blamelessness" means assuming everyone acted with good intent and the best information they had at the time. #INSTRUCTIONS: Given the incident details below, produce a complete, structured postmortem document. Be factual and specific. Avoid speculation where data exists. Where the data is incomplete, say what you don't know and recommend how to find out. #STEPS: ## Step 1 - Incident Summary Write a 2-3 sentence summary covering: what the impact was (users/scope affected), when it started and ended, and severity level (SEV1-SEV4). Keep this tight - a reader should understand the incident from this paragraph alone. ## Step 2 - Impact Assessment Quantify the blast radius: number of users affected, requests dropped, revenue lost, SLA/SLO impact. If exact numbers are not available, provide best estimates and label them as such. ## Step 3 - Timeline Reconstruction Build a chronological timeline with timestamps. Include: first alert triggered, detection time, acknowledgment, investigation milestones, mitigation attempt(s), resolution, and service recovery. Mark key turning points. ## Step 4 - Root Cause Analysis Apply the "5 Whys" technique. Start from the symptom and drill down to the systemic cause. Stop when you reach a process, tooling, or organizational gap - not when you reach a person. The goal is to find the broken system, not the person who "should have known." ## Step 5 - Contributing Factors List anything that made the incident worse or harder to resolve: insufficient monitoring, missing runbooks, cascading failures, deployment timing, communication gaps. Be honest about what slowed the response. ## Step 6 - What Went Well Acknowledge what worked during the response. This is not fluff - it documents effective practices worth repeating. Examples: fast escalation, good alerting, a runbook that helped. ## Step 7 - Action Items Output a prioritized table of action items. Each must have: action, owner (assign TBD if unknown), priority (P0/P1/P2), and target date. Tie each action item to a specific root cause or contributing factor. Prefer preventive actions (stop it happening again) over detective actions (notice it faster next time). ## Step 8 - Lessons Learned Write 3-5 key takeaways. These should be transferable insights, not just incident-specific notes. "Our deployment process needs automated rollback" is useful. "We should be more careful" is not. #END_GOAL: A blameless postmortem document that a team can act on immediately - clear root causes, concrete action items with owners, and lessons that improve the overall system. #NARROWING: - Do NOT assign blame to individuals. If a human action contributed, frame it as: "The process allowed X to happen" not "X should have done Y." - Do NOT omit contributing factors to keep things positive. Honest assessment builds trust. - If the incident involved a third-party dependency, note it - but still ask what you could do to be more resilient to that dependency failing. - Keep the tone professional and direct. This is an engineering document, not a narrative.

#ROLE: Business strategy consultant. #TASK: Conduct a comprehensive SWOT analysis for {{subject}}. #FRAMEWORK: ## STRENGTHS (Internal, Positive) - What advantages do they have? - What do they do better than anyone? - What unique resources can they draw on? ## WEAKNESSES (Internal, Negative) - What could they improve? - What should they avoid? - What factors lose them opportunities? ## OPPORTUNITIES (External, Positive) - What trends could they capitalize on? - What market gaps exist? - What partnerships/alliances are possible? ## THREATS (External, Negative) - What obstacles do they face? - What are competitors doing? - What external factors could cause problems? #STRATEGIC RECOMMENDATIONS: 1. **S-O Strategy**: Use strengths to maximize opportunities 2. **W-O Strategy**: Improve weaknesses to capture opportunities 3. **S-T Strategy**: Use strengths to minimize threats 4. **W-T Strategy**: Minimize weaknesses to avoid threats #SUBJECT: {{subject}} #INDUSTRY: {{industry}}

#ROLE: Executive coach facilitating a weekly review session. #TASK: Guide me through a structured weekly review. #SECTION 1: LOOKING BACK - What were my top 3 accomplishments this week? - What didn't get done? Why? - What surprised me (positively or negatively)? - Rate the week 1-10 on: Productivity, Energy, Relationships, Growth #SECTION 2: LEARNING - What's one thing I learned about myself? - What's one thing I learned about my work? - What mistake did I make, and what's the lesson? #SECTION 3: LOOKING FORWARD - What are my top 3 priorities for next week? - What's one thing I should STOP doing? - What's one thing I should START doing? - What's my #1 focus for the week? #OUTPUT: Clean, fillable template. Ask each question one at a time.

Abstract digital gradient background. Fluid, organic color transitions between {{color_1}} and {{color_2}} with hints of {{color_3}}. Style: soft, ethereal, like ink dropping in water or aurora borealis. Subtle grain texture. Smooth bokeh light spots in the brighter areas. No hard edges, no geometric shapes, no text. Mood: {{mood}} (calm, energetic, mysterious, luxurious). Resolution: 3840x2160 (4K). Suitable as a website hero background or wallpaper.

#ROLE: Strategic decision-making facilitator. #TASK: Help me make a decision between {{num_options}} options using a weighted decision matrix. #MY OPTIONS: {{options}} #STEP 1: CRITERIA Identify the key criteria for this decision. Ask me: - What matters most? (cost, time, quality, risk, scalability, etc.) - Weight each criterion 1-5 based on importance. #STEP 2: SCORE For each option, score it 1-5 on each criterion. #STEP 3: CALCULATE Multiply score × weight for each cell. Sum rows. Rank options. #STEP 4: STRESS TEST - Which assumption, if wrong, would change the winner? - What's the worst-case scenario for the top option? - Is there a hybrid approach that combines the best of multiple options? #DECISION CONTEXT: {{context}}

#ROLE: Product demo video scriptwriter. #TASK: Write a {{duration}}-second tutorial video script for {{product_name}}. #STRUCTURE: 1. **Hook (0-5s)**: Show the end result. What will users achieve? 2. **Problem (5-10s)**: The pain point this solves. 3. **Steps (10-{{duration-10}}s)**: Walkthrough key steps with screen recording directions. 4. **Outro (last 5s)**: Recap + CTA. #FOR EACH SCENE specify: - **Voiceover**: Exact narration text - **Visual**: What's on screen (UI screenshot, B-roll, text overlay) - **Duration**: Seconds for this scene - **Text overlay**: Any text shown (keep minimal) #PRODUCT: {{product_name}} #FEATURES TO SHOW: {{key_features}} #TARGET USER: {{target_user}}

Minimalist workspace photograph. A clean {{desk_type}} desk (oak / walnut / white lacquer) against a {{wall_color}} wall. On the desk: a {{laptop_type}} laptop slightly open, a ceramic mug with {{beverage}}, a small potted {{plant_type}}, and one hardcover book. Natural window light from the left creating soft shadows. Shot at 35mm, f/2.8, from a 45-degree angle showing depth. Color grade: muted, desaturated, warm whites. Style: Kinfolk magazine, wellness aesthetic. No clutter, no cables visible, no text. 4K resolution.

#ROLE: Technical writer specializing in developer documentation. #TASK: Generate API documentation for the following endpoint. #DOC SECTIONS: 1. **Summary**: One-line description of what the endpoint does. 2. **Endpoint**: Method + URL path 3. **Authentication**: Required? What type? 4. **Parameters**: Table with name, type, required, description 5. **Request Body**: JSON schema with example 6. **Response**: Success (200) with example, Error responses (4xx, 5xx) 7. **Rate Limits**: If applicable 8. **Code Examples**: cURL, JavaScript, Python #FORMAT: Clean Markdown, ready for a docs site. #ENDPOINT SPEC: - Method: {{method}} - Path: {{path}} - Purpose: {{purpose}} - Parameters: {{parameters}}

# RISEN Framework: Character Voice Consistency Checker **R — Role:** You are a senior fiction editor with 15+ years of experience in character voice consistency for publishers like Tor, HarperCollins, and indie serial fiction platforms. You specialize in dialogue diagnostics — catching voice drift before readers do. **I — Instructions:** You will build a comprehensive voice profile from sample dialogue, then audit new dialogue against that profile. Work methodically through each step. Do not skip the profile-building phase even if the dialogue seems straightforward. **S — Steps:** **STEP 1 — BUILD VOICE PROFILE** Analyze the sample dialogue and extract these six dimensions: 1. **Vocabulary Register**: Is the word choice simple, educated, technical, slang-heavy, archaic? Note specific examples and the reading-grade level equivalent. 2. **Sentence Architecture**: Short and punchy? Long and flowing? Mixed? What's the average sentence length? Do they use fragments, run-ons, or perfectly balanced clauses? 3. **Verbal Fingerprints**: Identify repeated words, filler words ("like," "look," "I mean"), catchphrases, or distinctive speech patterns (e.g., answering questions with questions, trailing off, interrupting themselves). 4. **Emotional Register**: Stoic, expressive, sarcastic, earnest, defensive, warm? How does emotion manifest — through word choice, sentence rhythm, or what they DON'T say? 5. **Subtext Patterns**: What do they avoid saying? How do they deflect, lie, or reveal truth indirectly? 6. **Anti-Voice List** (critical): Words, expressions, idioms, and emotional reactions that this character would NEVER use. Be specific — "formal jargon" is less useful than "would never say 'nevertheless' or 'furthermore.'" **STEP 2 — AUDIT NEW DIALOGUE** When new dialogue is provided, score it on a 1-10 consistency scale using these criteria: | Score | Meaning | Action | |-------|---------|--------| | 9-10 | Fully in voice | No changes needed | | 7-8 | Minor deviations | Small word-level fixes | | 5-6 | Noticeable drift | Rewrite suggested lines | | 3-4 | Significantly off | Flag and provide alternatives | | 1-2 | Wrong character | Full rewrite needed | For each deviation, cite the specific profile dimension violated and suggest a fix that brings it back into voice. **E — End Goal:** Deliver a voice profile that a writer can use as a living reference document across multiple chapters, co-writers, or serialized installments — plus a repeatable audit that catches voice drift before publication. **N — Narrowing:** - Do not rewrite entire scenes. Focus only on dialogue lines. - Do not comment on plot, pacing, or description unless it directly affects voice perception. - If the character has a known arc (e.g., becomes more guarded over time), note that voice evolution is expected — flag only inconsistent drift, not intentional character development. - For ensemble casts, build separate profiles per character and note when voices are bleeding into each other. **VARIABLES:** - CHARACTER NAME: {{character_name}} - SAMPLE DIALOGUE: {{sample_dialogue}} - NEW DIALOGUE TO CHECK: {{new_dialogue}}

Minimalist workspace photograph. A clean {{desk_type}} desk (oak / walnut / white lacquer) against a {{wall_color}} wall. On the desk: a {{laptop_type}} laptop slightly open, a ceramic mug with {{beverage}}, a small potted {{plant_type}}, and one hardcover book. Natural window light from the left creating soft shadows. Shot at 35mm, f/2.8, from a 45-degree angle showing depth. Color grade: muted, desaturated, warm whites. Style: Kinfolk magazine, wellness aesthetic. No clutter, no cables visible, no text. 4K resolution.

#ROLE: Technical writer specializing in developer documentation. #TASK: Generate API documentation for the following endpoint. #DOC SECTIONS: 1. **Summary**: One-line description of what the endpoint does. 2. **Endpoint**: Method + URL path 3. **Authentication**: Required? What type? 4. **Parameters**: Table with name, type, required, description 5. **Request Body**: JSON schema with example 6. **Response**: Success (200) with example, Error responses (4xx, 5xx) 7. **Rate Limits**: If applicable 8. **Code Examples**: cURL, JavaScript, Python #FORMAT: Clean Markdown, ready for a docs site. #ENDPOINT SPEC: - Method: {{method}} - Path: {{path}} - Purpose: {{purpose}} - Parameters: {{parameters}}