Public Prompt Library

#CONTEXT Our team's code reviews are inconsistent. Some reviewers catch architectural problems; others only flag formatting. I need a shared checklist so every review covers the same ground and we stop relitigating style. #OBJECTIVE Produce a code review checklist tailored to our stack, our common failure modes, and our team's quality bar. The checklist should be short enough that a reviewer can run it in 10 minutes on a normal PR. #STYLE Practical and specific. Each item is a question a reviewer can answer yes/no or a concrete thing to verify. No generic advice like 'ensure code quality.' #TONE Written for working engineers, not process auditors. Skip the preamble about why code review matters. #AUDIENCE Our engineering team — mixed seniority, reviewing PRs in {{your primary language/framework}}. #RESPONSE Structure as a checklist grouped into: 1. **Correctness** (does it do what it claims?) — 3-5 items. 2. **Security** (does it introduce risk?) — 2-4 items, tied to our stack's common vulnerabilities. 3. **Performance** (will it scale or degrade?) — 2-3 items specific to our load patterns. 4. **Maintainability** (will the next engineer understand it?) — 2-3 items. 5. **Tests** (does it prove it works?) — 2-3 items. Keep the total under 20 items. A 50-item checklist gets ignored. After the checklist, add a 'Stop reviewing and talk to the author' section — 2-3 signals that the PR needs a conversation, not a comment thread. Our stack & context: {{language, framework, database, deployment, team size, common bugs you've shipped}}

#SITUATION I hit an error. I have the raw stack trace, error message, or log output. I need to go from 'something broke' to 'here is the most likely cause and the first fix to try' without reading 50 Stack Overflow threads. #PURPOSE Produce a fast, ranked diagnosis that points at the probable root cause and gives me a concrete next action, ordered by likelihood so I try the best bet first. #EXPECTED_OUTPUT Structure the response as: 1. **One-line summary** — what broke and where, in plain language. 2. **The error in context** — what the application was trying to do when it failed. 3. **Ranked causes** (3-5 max): for each, give (a) likelihood (High/Medium/Low) with a one-sentence reason, (b) the specific fix to try, and (c) a code snippet or command if applicable. 4. **What to check if none of these work** — the next debugging step (logs to enable, the minimal repro to build). 5. **Red flags** — anything in the trace that suggests a deeper architectural issue rather than a surface bug. #CONTEXT - Language/framework: {{e.g., Node.js Express, Python FastAPI, Java Spring}} - Environment: {{local / staging / production}} - What I was doing when it broke: {{action that triggered it}} #STYLE Direct and technical. Assume I can read code. Skip the generic 'have you tried turning it off and on again' unless that's genuinely the most likely fix. No filler about how errors are a natural part of development. Stack trace / error output: {{paste the full stack trace or error message here}}

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

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

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

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

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