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}}

# 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.

# 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 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}}

#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}}

#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.

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.

#WORKFLOW: Generate a complete 10-slide pitch deck structure for {{startup_name}}. #STEP 1: STRUCTURE Create the slide-by-slide outline: 1. Title (name + tagline) 2. Problem (3 pain points with evidence) 3. Solution (how you solve it, with a visual) 4. Market (TAM/SAM/SOM with sources) 5. Product (key features, demo screenshots) 6. Traction (metrics, growth chart, key wins) 7. Business Model (how you make money) 8. Competition (2x2 matrix positioning) 9. Team (why YOU are the right people) 10. Ask (how much, what for, milestones) #STEP 2: CONTENT For each slide, write: - Headline (under 8 words) - Body text (under 30 words) - Visual direction (what image/chart goes here) #STEP 3: REFINEMENT Review for: - Narrative flow (does it tell a story?) - Clarity (can a non-expert understand?) - Credibility (are claims backed by data?) #STARTUP DETAILS: - Industry: {{industry}} - Stage: {{stage}} (pre-seed / seed / Series A) - Key differentiator: {{differentiator}}

# ROLE You are a senior product designer who specializes in first-run user experience for SaaS products. You have shipped onboarding flows for products with millions of users. You think in terms of activation rate, time-to-value, and retention — not feature lists. # CONTEXT Most SaaS onboarding fails because it tries to teach everything at once. Users sign up, get a tour of 20 features, and leave without doing the one thing that matters. The research is clear: users decide whether a product is worth keeping within the first session, usually within the first 60 seconds. That window is where you either deliver an aha moment or lose them forever. The best onboarding flows share a structure: welcome, quick win, setup, progressive education, habit trigger. Each step has one job, one success metric, and one clear next action. No step tries to do two things. This prompt designs that flow for a specific product. # OBJECTIVE Given a product name, type, and key details, design a complete 5-step onboarding flow that: 1. Delivers the first aha moment within 60 seconds of signup 2. Configures the product for the user's specific use case without overwhelming them 3. Teaches through doing, not through video tutorials or feature tours 4. Builds a reason to return on day two 5. Includes screen descriptions, microcopy, and a success metric for every step # STYLE Structured, specific, and implementation-ready. Describe each screen as if briefing a UI designer who will build it tomorrow. Use concrete copy — real button labels, real helper text, real empty states — not placeholders like welcome message here. # TONE Practical and direct. No onboarding philosophy lectures. No did-you-know-that-40-percent preamble. Just the flow, the screens, the copy, and the metrics. # AUDIENCE A product manager, founder, or designer who needs to build or fix an onboarding flow and wants a concrete spec they can hand to a developer or use as a design brief. # RESPONSE FORMAT ## Flow Overview - Product: {{product_name}} - Type: {{product_type}} - What it does: {{what_it_does}} - Primary activation event: [the one action that proves the user got it] - Target time to first value: under 60 seconds ## Step 1: First Impression **Goal:** [one sentence — what this step must achieve] **Screen:** [visual description: layout, key elements, what the user sees first] **Microcopy:** - Headline: "[actual copy the user reads]" - Subtext: "[actual copy]" - Primary button: "[actual label]" - Secondary action: "[actual label or none]" **Interaction:** [what happens when they click the primary button — where do they go, what loads] **Success metric:** [the number you track to know this step worked] ## Step 2: Quick Win (under 60 seconds) [Same structure as Step 1] ## Step 3: Setup (2–5 minutes) [Same structure] ## Step 4: Progressive Education [Same structure] ## Step 5: Habit Trigger [Same structure] ## Retention Strategy - Day 2 trigger: [what brings them back the next day] - Week 1 milestone: [what success looks like after 7 days] - Churn signal: [behavior that predicts the user will leave — so you can intervene] --- # INPUT Product name: {{product_name}} Product type: {{product_type}} What it does (one sentence): {{what_it_does}} Key integration: {{key_integration}} Core entity the user creates (e.g., project, report, campaign): {{core_entity}} Primary user goal: {{primary_goal}}

#WORKFLOW: Multi-step prompt chain for turning research into published content. ## STEP 1: RESEARCH Topic: {{topic}} Research latest developments, statistics, and expert opinions. Compile a fact sheet with 10 key data points with sources. ## STEP 2: ANGLE Based on research, identify 3 unique content angles that have not been overdone. For each, explain why it is interesting and who would care. ## STEP 3: DRAFT Selected angle: {{chosen_angle}} Write a {{content_format}} (800-1200 words). Hook in first 2 sentences. Include data points naturally. End with clear CTA. ## STEP 4: OPTIMIZE Review draft for SEO, readability (grade 8), engagement, and CTA effectiveness. Provide revised version with tracked changes. #USAGE: Run each step sequentially, using previous output as next input.