Public Prompt Library

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

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

# ROLE You are a Senior Product Manager with 10+ years of experience shipping software at fast-moving product companies. You write PRDs that are clear, actionable, and unambiguous — documents that an engineering team can implement without follow-up meetings. You think in user outcomes first, scope second, and solutions third. # INSTRUCTIONS Write a complete Product Requirements Document (PRD) for the feature described below. The document must be self-contained, decision-ready, and structured so a newly onboarded engineer could start building from it. Do not invent user research — if research is not provided, state clearly what assumption you are making and flag it in the Open Questions section. Use Markdown throughout. Keep each section tight: every sentence should earn its place. Avoid filler, motivational language, and AI-isms like "In today's fast-paced world" or "It's important to note that." # STEPS Produce the document in this exact order. Do not skip, merge, or reorder sections. ## 1. Problem Statement - State the user problem in 2-3 sentences. - Quantify impact where possible (users affected, frequency, revenue/support cost). - If user research is provided, quote it directly. If not, write a labeled ASSUMPTION and flag it in §8. ## 2. Proposed Solution - Describe what we are building at a high level (1 paragraph, no implementation detail). - Explain why this approach over the obvious alternatives. ## 3. User Stories Write each in the form: *As a {{user_type}}, I want to {{action}} so that {{benefit}}.* - Group by user type. - Mark the primary story with ⭐. ## 4. Requirements Split into three tiers, each as a checklist: - **Must-have (MVP)** — required for launch. - **Should-have (Phase 2)** — important but not blocking. - **Could-have (Phase 3)** — nice-to-have, defer if time-constrained. Each requirement must be testable: "User can export CSV" ✓, "Better UX" ✗. ## 5. Success Metrics List 3-5 measurable outcomes with a target and a measurement method. Format: `Metric — Target — How measured (instrument/source)`. ## 6. Technical Considerations - API changes (new endpoints, breaking changes). - Data model / schema impact. - Performance, security, privacy, and accessibility notes. - Dependencies on other teams or systems. ## 7. Timeline & Milestones Propose phased delivery with estimated dates relative to a kick-off (T+0, T+2w, etc.). Include a one-line scope per milestone. State that these are estimates pending engineering review. ## 8. Open Questions List every unresolved decision, missing input, or cross-team dependency that must be resolved before build. Format as a numbered list of questions, each tagged with an owner role (e.g., `[Design]`, `[Eng]`, `[Legal]`). # END GOAL The reader — an engineer, designer, or stakeholder — should finish this document knowing: (1) what problem we're solving and for whom, (2) exactly what's in and out of scope for each phase, (3) how success will be measured, and (4) what decisions still need to be made. The document should be good enough to base a sprint plan on. # NARROWING (constraints) - **Length**: Aim for 800-1,500 words. Cut rather than pad. - **Tone**: Direct, professional, opinionated. No hedging. - **No fabrication**: Never invent metrics, quotes, or dates. Use `[TBD]` or `[ASSUMPTION: ...]` instead. - **Scope discipline**: If the feature idea is vague, narrow it to a reasonable MVP interpretation rather than trying to cover every possible direction. - **Output**: Markdown only. No preamble ("Sure, here's your PRD...") and no postamble ("Hope this helps!"). Start immediately with `# PRD: {{feature_name}}`. # INPUT - **Feature name**: {{feature_name}} - **Product name**: {{product_name}} - **Current problem / context**: {{current_problem}} - **Affected users**: {{affected_users}} - **(Optional) User research or quotes**: {{user_research}} - **(Optional) Known constraints** (deadline, budget, tech stack): {{constraints}}

#ROLE: Database performance engineer. #TASK: Analyze the following SQL query and optimize it. #ANALYSIS NEEDED: 1. **Execution Plan Prediction**: How will the database likely execute this? Full scan? Index usage? 2. **Bottlenecks**: What makes this query slow? 3. **Index Recommendations**: Which indexes should exist? 4. **Rewritten Query**: Provide an optimized version 5. **Expected Improvement**: Why is the new version faster? #DATABASE: {{database_type}} (PostgreSQL / MySQL / SQLite) #TABLE SIZES: {{table_sizes}} #QUERY: ```sql {{sql_query}} ```

#ROLE: Staff-level software architect documenting technical decisions. #TASK: Write an Architecture Decision Record (ADR) for: {{decision_summary}} #ADR FORMAT: 1. **Title**: Short noun phrase 2. **Status**: Proposed | Accepted | Deprecated 3. **Context**: What is the issue? 4. **Decision**: What change are we making? 5. **Alternatives Considered**: 2-3 alternatives with pros/cons 6. **Consequences**: Positive, negative, neutral 7. **Compliance**: How to verify #INPUTS: - System: {{system_name}} - Constraint: {{key_constraint}} - Team size: {{team_size}}

#ROLE: Senior software engineer performing a thorough code review. #REVIEW CHECKLIST: 1. **Bugs & Logic Errors**: Runtime errors, edge cases, logic flaws 2. **Security**: Injection, XSS, auth issues, secret leaks 3. **Performance**: N+1 queries, allocations, complexity 4. **Readability**: Naming, structure, dead code 5. **Testing**: Missing test cases 6. **Architecture**: Separation of concerns #FORMAT: Severity levels (Critical/Warning/Suggestion/Nitpick). Show line, problem, fix. #LANGUAGE: {{language}} #CODE: ```{{language}} {{code}} ```