⚡ Prompt Library

I'm getting the following error in {{language}}: Error: {{error_message}} Code causing the error: ```{{language}} {{code}} ``` Expected behavior: {{expected_behavior}} Please: (1) Explain what's causing this error, (2) Show the fix with the corrected code, (3) Explain how to prevent this type of error in the future.

Review this {{language}} code for production readiness. Check for: 1. **Bugs**: Logic errors, edge cases not handled, off-by-one errors 2. **Security**: Injection vulnerabilities, insecure data handling, missing input validation 3. **Performance**: Unnecessary loops, missing indexes, N+1 queries, memory leaks 4. **Readability**: Unclear names, missing comments for non-obvious logic, magic numbers 5. **Best Practices**: Design pattern violations, anti-patterns for this language/framework Code: ```{{language}} {{code}} ``` Format your review as a prioritized list: [CRITICAL], [MAJOR], [MINOR], [SUGGESTION]. For each issue, show the problematic code and the improved version.

Optimize this {{language}} code. The bottleneck is: {{bottleneck_description}} Current complexity: {{current_complexity}} ```{{language}} {{code}} ``` Please: 1. Analyze the current approach and why it's slow 2. Propose 2-3 optimization strategies with their tradeoffs 3. Implement the best approach 4. Provide the new time and space complexity with explanation 5. If the optimization trades space for time (or vice versa), explicitly state the tradeoff

Write comprehensive unit tests for this {{language}} function using {{framework}}. Function purpose: {{function_purpose}} ```{{language}} {{function_code}} ``` Cover these test cases: 1. Happy path (normal expected input) 2. Edge cases (empty input, single element, maximum values) 3. Invalid input (wrong types, null/undefined, negative numbers where relevant) 4. Boundary conditions (exactly at limits) 5. Error cases (expected exceptions/throws) Use descriptive test names that explain WHAT is being tested and WHAT the expected outcome is.

Refactor this {{language}} code to Clean Code standards. Preserve all functionality exactly. ```{{language}} {{code}} ``` Apply these improvements: - Extract functions: break functions >20 lines into smaller, single-purpose functions - Descriptive naming: replace abbreviations and generic names (data, temp, stuff) with meaningful names - Remove duplication: extract repeated code into shared functions - Simplify conditions: replace complex conditionals with named predicates - Remove magic numbers: replace hardcoded values with named constants Show the refactored code with a brief summary of each change made. DO NOT change functionality.

Explain this code to {{audience}}: ``` {{code}} ``` Structure your explanation: 1. What this code does overall (one sentence) 2. Walk through each important part in plain English — no jargon 3. Give a real-world analogy that makes the concept clear 4. Point out anything tricky or non-obvious that {{audience}} might miss

Convert this {{source_language}} code to idiomatic {{target_language}}. ```{{source_language}} {{code}} ``` Requirements: - Use {{target_language}} idioms and conventions — don't just translate syntax literally - Maintain identical behavior and edge case handling - Use the {{target_language}} standard library equivalents where applicable - Add brief comments where the {{target_language}} approach significantly differs After the code, note any differences in behavior or features that couldn't be directly translated.

Generate TypeScript interfaces for this JSON data. Root type name: {{root_type_name}} ```json {{json_data}} ``` Rules: - Use interfaces (not type aliases) for object shapes - Arrays should use Type[] syntax, not Array<Type> - Make optional fields (that might be null/undefined) properly optional with ? - Nested objects should be separate named interfaces - Use union types for fields that have multiple possible types - Add JSDoc comments for fields that have non-obvious purposes

Review this system design like a senior Staff Engineer would in a design review: System: {{system_description}} Requirements: {{requirements}} Scale: {{scale}} Evaluate against these criteria: 1. **Scalability**: Will this handle 10x the load? What breaks first? 2. **Reliability**: Single points of failure, what happens when each component fails? 3. **Consistency**: Data consistency guarantees — is eventual consistency acceptable here? 4. **Latency**: Request path analysis — what's the p99 latency for the critical path? 5. **Cost**: Rough infrastructure cost estimate 6. **Security**: Authentication, authorization, data protection gaps Format: [STRENGTH] or [RISK] tag for each point, with a brief explanation and recommendation.

Design a production system for: {{feature}} Context: {{context}} Constraints: {{constraints}} Provide: 1. **High-level architecture diagram** (text-based ASCII or describe components and data flow) 2. **Database schema** (tables, key fields, indexes, relationships) 3. **API design** (key endpoints with method, path, request/response shape) 4. **Scalability strategy** (how it handles 100x growth) 5. **Failure modes and recovery** (what breaks, how to detect, how to recover) 6. **Implementation order** (MVP → v2 → v3 prioritization)

Explain {{concept}} to me. My background: {{background}}. Use this structure: 1. **ELI5 Version**: Explain it as if I'm 10 years old using an everyday analogy 2. **The Real Explanation**: Now explain the actual technical concept, building on the analogy 3. **Why It Matters**: One concrete example of where this concept is used in the real world 4. **Common Misconception**: One thing people often misunderstand about this 5. **Check Your Understanding**: Give me one question I should be able to answer now Avoid jargon. If you must use technical terms, define them immediately.

Create a structured study plan for learning {{skill}}. My current level: {{current_level}} My goal: {{goal}} Available time: {{hours_per_week}} hours/week for {{weeks_available}} weeks Structure the plan as weekly milestones with: - Week-by-week topics (what to learn each week) - Specific learning resources for each week (free resources preferred) - Practice projects (one per major section) - Checkpoint questions to verify understanding before moving on - Warning signs that you're moving too fast / stuck Make it realistic — account for real learning curves, not optimistic projections.