Public Prompt Library

#ROLE You are a software architect with extensive experience in legacy system modernization and technical debt reduction. #TASK Develop a modernization plan for a specific legacy codebase (language, framework, approximate size) that improves maintainability, security, and/or performance while minimizing business disruption. #REQUEST Generate a phased modernization plan that includes: 1. Assessment phase: code analysis, dependency mapping, risk identification 2. Goal setting: define specific modernization objectives (e.g., upgrade framework, improve test coverage, reduce deployment time) 3. Prioritization framework: rank components by business value, technical risk, and effort 4. Pilot selection: choose a low-risk, high-visibility component to modernize first 5. Detailed pilot plan: steps, resources, timeline, success metrics 6. Knowledge transfer strategy: document patterns, train team members 7. Incremental rollout approach: how to expand from pilot to full system 8. Decommissioning plan for retired components 9. Metrics to track before, during, and after modernization 10. Contingency plans for common setbacks (integration issues, performance regressions, team turnover) #ACTION Present the plan as a timeline with phases, key milestones, and deliverables. Include specific techniques (e.g., strangler fig pattern, API facades, automated refactoring tools). #CONTEXT Assume the legacy system is currently in production and critical to business operations. The team has limited bandwidth for modernization work alongside feature development. #EXAMPLE For a monolithic Java Spring Boot application considering migration to microservices: outline how to identify service boundaries, extract first service, implement inter-service communication, and handle data consistency.

#SITUATION I inherited a module with zero tests. I want to change it, but without tests I have no way to know what breaks. Full coverage is not the goal — I need a safety net around the behavior that matters, fast. #PURPOSE Generate a runnable starter test suite for the module below, prioritized by risk: the tests that catch the most likely regressions come first, so I can stop at any point and still have gained something. #EXPECTED OUTPUT ## 1. Behavior Inventory List the observable behaviors of the module (what it does, not how). 5-12 items. Mark each: CRITICAL (breaks users if wrong) / IMPORTANT (breaks features) / MINOR. ## 2. Test Suite A complete test file, runnable as-is: - Test framework: {{framework}} (e.g., pytest, Vitest, Jest, JUnit, Go testing) - Ordered by the priority above, highest first - Each test named for the behavior it pins ('returns empty list when input empty', not 'test_3') - Arrange-Act-Assert structure, one behavior per test - Explicit mocks/stubs for external calls (network, DB, clock, filesystem) — no live calls - Edge cases: empty input, boundary values, error paths where the module defines them ## 3. Untestable Boundary Anything in the module that cannot be unit tested as written (hidden state, direct I/O, global mutation). For each: what it is, and the smallest refactor that would make it testable. Do not perform the refactor — just specify it. ## 4. First Refactor Target Given these tests exist, the one safe refactor I should do first and why. #CONTEXT - Language and version: {{language}} - Test framework and runner command: {{framework}} - Why I am touching this module: {{change_planned}} #STYLE Ship-shape code, no pseudocode, no TODO comments left in the suite. Comments only where a test exists to pin down surprising behavior. #MODULE ```{{language}} {{paste_module_code}} ```

#SITUATION A team ships code but bugs reach production. They have some tests but no strategy — unit tests for trivial getters, no integration tests for critical paths, flaky E2E tests that everyone ignores. You need a test strategy that catches real regressions and runs fast enough to not block deploys. #PURPOSE Produce a test strategy document tailored to the stack, team size, and risk profile. Not a testing textbook — a decision document. #EXPECTED OUTPUT ## 1. Test Pyramid (or Diamond, or Trophy) for THIS Project - Unit: target coverage %, what to test (pure logic, edge cases), what to skip (getters, framework glue) - Integration: which boundaries (DB, API, message queue), contract testing approach - E2E: critical user journeys only (max 5-10), tool selection, flake mitigation ## 2. Layer Definitions For each layer: - Tools (name them: Vitest, Playwright, Pact, etc.) - When it runs (pre-commit, CI, nightly, on-demand) - Target execution time - Who writes/maintains ## 3. Coverage Targets - Statements: % - Branches: % - Functions: % - Critical paths: 100% (define what counts as critical) ## 4. Test Data Strategy - Fixtures vs. factories vs. production snapshots - How to handle PII - Database seeding for integration tests ## 5. Flaky Test Protocol - Detection (automated) - Quarantine process - Fix or delete SLA ## 6. CI/CD Integration - Pipeline stages - Gate criteria (what blocks merge) - Reporting (where results go) ## 7. What We Explicitly Don't Test List the conscious omissions so future reviewers know it was a decision, not an oversight. #CONTEXT Stack: {{language}}, {{framework}}, {{database}}, {{deployment}} Team: {{team_size}} engineers Risk profile: {{risk}} (fintech/healthcare = high, internal tool = lower) Current test state: {{current_state}} (none / some unit / flaky E2E / etc.) Release cadence: {{release_frequency}}

#CONTEXT A codebase has little or no documentation. New developers take months to become productive. You need to generate docs that explain what the code actually does — not what someone hoped it would do. #ROLE You are a senior engineer who writes documentation that prevents bugs. You document behavior, not intention. #ACTION Analyze the provided code and produce documentation in these sections: ## 1. System Overview - What this module/service does (2-3 sentences) - Key responsibilities (bullet list) - What it does NOT do (boundary clarification) ## 2. Architecture Map - Component diagram (text-based: Component A → Component B → External API) - Data flow: input → processing → output - External dependencies (databases, APIs, message queues) ## 3. Key Functions/Classes For each public function or class: - Signature - What it returns / side effects - Preconditions (what must be true before calling) - Postconditions (what is guaranteed after) - Error modes (what exceptions, when) - Example call with realistic parameters ## 4. Business Logic Rules Extract the implicit rules: - Validation logic - State transitions - Edge cases the code handles (or doesn't) - Any "tribal knowledge" behaviors ## 5. Known Issues & Technical Debt - Functions marked TODO/FIXME - Workarounds in the code - Performance characteristics (N+1 queries, unbounded loops) - Security considerations (input sanitization, auth checks) ## 6. Onboarding Guide - How to run locally - How to run tests - How to debug common failures - Where to add a new feature #FORMAT Markdown with clear headers. Code snippets in fenced blocks. Flag assumptions with [ASSUMPTION: ...]. #CODE TO DOCUMENT {{paste_code_or_file_paths}}

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