AI Prompt Library

CopyI'm getting this error: [paste error message and full stack trace] Here's the relevant code: [paste the file/function mentioned in the stack trace] Explain what's causing this error and how to fix it. Show the corrected code.

CopyThis code works locally but fails in production. Here's the code: [paste code] Local environment: [Node version, OS, etc.] Production environment: [hosting platform, Node version] Error in production: [paste error or describe behavior] What environment-specific issues could cause this? Check for: hardcoded paths, environment variables, file system differences, and port/network configuration.

CopyThis function doesn't throw an error but produces the wrong result. Code: [paste function] Input: [what you're passing in] Expected output: [what should happen] Actual output: [what actually happens] Walk through the logic step by step with my specific input and identify where the behavior diverges from my expectation.

CopyThis code is [slow / using too much memory / causing the UI to freeze]. Code: [paste code] When does it get slow? [on page load / after 10 minutes / with large data] How large is the data? [approximate size] Identify the performance bottleneck. Check for: unnecessary re-renders, missing cleanup, O(n²) operations, memory leaks, and unoptimized queries. Suggest a fix for each issue found.

CopyThis code works sometimes and fails other times. I suspect a race condition or timing issue. Code: [paste code] Fails approximately: [how often — 1 in 10? Random?] More likely to fail when: [under load / fast clicking / slow network / etc.] Analyze for race conditions, missing awaits, shared mutable state, and timing-dependent logic. Show the fix.

CopyI'm getting this TypeScript error and I don't understand it: [paste the full error message] Here's the code: [paste relevant code] Here are my type definitions: [paste types] Explain what the error means in plain language. Then show how to fix it without using `any`.

CopyReview this code. Check for: 1. Bugs and logic errors 2. Security vulnerabilities 3. Missing error handling 4. Performance issues 5. Naming and readability 6. Missing edge cases Be specific. For each issue, show the problematic code and the fix. [paste code]

CopyReview this git diff for a PR. Check for bugs, security issues, inconsistencies, and anything that could break existing behavior. Context: [what this PR is supposed to accomplish] [paste git diff] Only flag real issues. If everything looks fine, say so.

CopyReview this API design: [paste endpoint list with methods, paths, and descriptions] Check for: - Inconsistent naming or conventions - Missing endpoints users would expect - Incorrect HTTP methods - Missing query parameters (pagination, filtering, sorting) - Missing error responses - Security concerns (auth, rate limiting, input validation)

CopyReview this database schema: [paste CREATE TABLE statements or schema definition] Check for: - Missing indexes on frequently queried columns - Missing foreign key constraints - Data types that could cause issues (text vs varchar, integer overflow) - Missing NOT NULL constraints where data is required - N+1 query risks from the table relationships - Anything that will be painful to change later

CopyReview this React component for: 1. Unnecessary re-renders (missing useMemo/useCallback) 2. useEffect that should be derived state 3. State that could be computed instead of stored 4. Missing cleanup in useEffect 5. Props drilling that should be context or a store 6. Accessibility issues (missing aria labels, keyboard nav) [paste component]

CopyI'm about to deploy this application to production. Review the codebase for deployment readiness: [paste key files or describe the app] Check for: - Hardcoded localhost URLs or development-only values - Missing environment variable handling - Console.log statements that should be removed - Debug code or TODO comments - Missing error handling on external API calls - CORS configuration appropriate for production - Secrets not committed to the repository

CopyWrite tests for this module using [Vitest/Jest]. [paste code] Include: - Happy path for each public function - Error cases (invalid input, missing data, wrong types) - Edge cases (empty arrays, zero, null, undefined, very large input) - Boundary values - One test you think will fail (to challenge assumptions) Mock these dependencies: [list external deps] Use describe/it blocks. Assert specific values, not just truthiness.

CopyWrite integration tests for these API endpoints using [Vitest/Jest] + supertest. Routes: [paste route file] Auth: [how auth works — JWT, session, etc.] For each endpoint, test: - Success with valid input and valid auth - Rejection without auth token (401) - Rejection with invalid input (400) — check error message format - Not found for missing resources (404) - Users can't access other users' data (403) Create test helpers: a function to create a test user and get a token, and a factory for test data with sensible defaults.

CopyWrite tests for this React component using React Testing Library. [paste component] Test: - Renders correctly with default props - Renders correctly with all optional props - User interactions (click, type, select) produce expected behavior - Loading and error states display correctly - Conditional rendering shows/hides the right elements - Callbacks are called with correct arguments Use screen queries (getByRole, getByText) over testIds.

CopyHere's a function and its existing tests: Function: [paste function] Current tests: [paste test file] What edge cases are missing? Think about: - Boundary values (0, -1, MAX_INT, empty string, empty array) - Null and undefined in every parameter - Concurrent calls - Very large inputs - Unicode and special characters - Timezone-dependent behavior - Network failures (if applicable) List each missing case and write the test for it.

CopyWrite characterization tests for this legacy code. These tests should capture what the code ACTUALLY does — not what it should do. [paste code] For each public function, test with typical inputs and document the actual output, even if the output seems wrong. I'm using these tests as a safety net before refactoring — they need to pass against the current implementation.

CopyThis function is too long and does too many things. Split it into smaller functions with clear responsibilities. [paste function] Rules: - Each extracted function should have a clear name that describes what it does - Keep the original function as an orchestrator that calls the smaller ones - Don't change the external behavior — same inputs, same outputs - Add TypeScript types to all extracted functions

CopyThese files contain duplicated logic: [paste file 1] [paste file 2] Identify the duplicated patterns and extract them into shared utility functions. Show: 1. The shared functions 2. How each file changes to use them 3. Where to put the shared code (suggest a file path)

CopyConvert this callback-based code to async/await. [paste code] Rules: - Error-first callbacks become try/catch - Preserve all logic — only change the async pattern - Add proper TypeScript return types (Promise) - Handle the case where callbacks were used for multiple results (convert to array or iterator)

CopyThe naming in this code is unclear. Rename variables, functions, and parameters to be more descriptive. [paste code] Rules: - Function names should describe what they do (verb + noun) - Variable names should describe what they contain - Boolean variables should read as questions (isLoaded, hasPermission, canEdit) - Don't rename anything that's part of a public API or external interface - Show a before/after mapping of all renamed identifiers

CopyThis code is more complex than it needs to be. Simplify it. [paste code] Simplification targets: - Replace classes with plain functions where no state is needed - Remove configuration objects that only have one usage - Inline utility functions that are only called once - Replace complex abstractions with straightforward logic - Remove unused generics Constraint: same inputs, same outputs. Only reduce internal complexity.

CopyReview this codebase and identify the top 5 issues worth fixing, ranked by impact. [paste code — or multiple files] For each issue: 1. What the problem is 2. Where it is (file and line) 3. Why it matters 4. The fix (show code) 5. Estimated effort (1-line fix, 10-minute refactor, or larger change) Only the top 5. Ignore style preferences and focus on bugs, maintainability, and clarity.

CopyCreate a [ComponentName] component. Props: [paste Props interface] Requirements: - Functional component, named export - [describe visual layout] - [describe interactions] - [describe conditional rendering] - Tailwind for styling, no inline styles - No `any` types

CopyCreate a custom hook: [hookName] Signature: [paste desired function signature with generics] Behavior: - [what the hook manages] - [side effects and cleanup] - [return values] Include JSDoc with a usage example. Clean up on unmount. Handle race conditions if async.

CopyCreate an Express route: [METHOD] [path] Zod validation schema: [paste schema] Auth: userId available via req.user.id Repository: [repoName] with methods [list methods] Response format: - Success: { data: T } with appropriate status code - Error: { error: string, code: string } Include: input validation, auth check, error handling with try/catch, and ownership verification if accessing user-specific data.

CopyCreate a Zustand store. Store interface: [paste interface with state and actions] Rules: - Use immer middleware - Loading pattern: set loading → fetch → set data → clear loading - Error pattern: set error, clear loading - Auth token from: [how to get it] - API base URL: [url] - [optimistic update requirements if any]

CopyCreate a Zod validation schema for this TypeScript type: [paste type/interface] Rules: - Add sensible string length limits (min/max) - Add format validation for emails, URLs, UUIDs - Use .transform() for normalization (trim, lowercase) where appropriate - Use .default() for optional fields with sensible defaults - Export both the schema and the inferred type

CopyCreate a SQL migration for this data model: [paste TypeScript interface] Database: [SQLite / PostgreSQL / MySQL] Requirements: - UUIDs as primary keys (TEXT for SQLite, UUID for Postgres) - Created/updated timestamps - Foreign keys with appropriate ON DELETE behavior - Indexes on columns that will be queried frequently - NOT NULL where data is required - UNIQUE constraints where business rules require them

CopyInfer TypeScript types for this JavaScript module: Code: [paste module] Usage: [paste how it's called across the codebase] Rules: - Use string literals and unions where usage implies specific values - Use readonly for arrays that aren't mutated - Use optional (?) for parameters not always provided - No `any` — use `unknown` if truly undetermined - Add JSDoc where types alone don't explain intent

CopyCreate a typed error handling system for an Express API: 1. An AppError class with: code (string), statusCode (number), details (optional Record<string, string>) 2. Factory functions: notFound(resource), validation(details), unauthorized(), forbidden() 3. Express error handler middleware that formats AppError vs unknown errors 4. An asyncHandler wrapper that catches promise rejections Error code format: DOMAIN_ACTION_REASON (e.g. USER_CREATE_EMAIL_TAKEN)

CopyExplain this code in plain language. I didn't write it and I need to understand it. [paste code] Cover: - What does it do overall? (one paragraph) - What are the inputs and outputs? - What are the non-obvious side effects? (database writes, API calls, global state changes) - What would break if I changed or removed this code?

CopyExplain this regular expression piece by piece: [paste regex] For each part, show: the pattern, what it matches, and an example of matching text. Then show 3 strings that match and 3 that don't.

CopyCompare these two approaches for [what you're building]: Approach A: [describe or paste code] Approach B: [describe or paste code] For each, evaluate: - Complexity (code and mental model) - Performance characteristics - Testability - Maintainability as the project grows - Known pitfalls Which would you recommend for [my specific context]? Be direct.

CopyHere's the file structure of a project I need to understand: [paste output of: find src -type f -name '*.ts' | head -40] Give me a high-level architecture overview: - What are the major modules? - How do they relate to each other? - What does each directory handle? - What's the entry point and how does a request flow through the system?

CopyExplain [concept] to me. I'm working with [your stack: e.g., React + TypeScript + Express]. - Start with what it is in one sentence - Show a minimal working example using my stack - Explain when I'd use it and when I wouldn't - Show a common mistake people make with it - Compare it briefly to [alternative] which I'm already familiar with

CopyAdd JSDoc comments to all exported functions and types in this module. [paste code] Rules: - Describe what the function does, not how it does it - Document all parameters with @param and their purpose - Document return type with @returns - Add @throws for functions that throw errors - Add @example with a realistic usage example - Keep descriptions concise — one line if possible - Don't modify any code, only add documentation

CopyGenerate a README.md for this project. Package.json: [paste] Project structure: [paste tree output] Brief description: [one sentence about what this does] Include: - Project description (2-3 sentences) - Tech stack - Getting started (install, configure, run) - Environment variables with descriptions - Available scripts (dev, build, test) - Project structure overview - API endpoints if applicable Keep it concise. Developers read READMEs to get started quickly, not to read essays.

CopyGenerate a changelog from these git commits: [paste: git log --oneline --since="2 weeks ago" --no-merges] Group by: Added, Changed, Fixed, Removed Skip trivial commits (typos, formatting, merge commits) Use past tense. One line per item. Be concise.

CopyGenerate API documentation for these endpoints: Routes: [paste route files] Validation schemas: [paste Zod schemas] Types: [paste response types] For each endpoint, document: - Method and path - Description (one sentence) - Request body or query parameters with types - Success response with example - Error responses with codes and meanings - Authentication requirement

CopyAdd inline comments to this code explaining the non-obvious parts. [paste code] Rules: - Only comment things that aren't obvious from reading the code - Explain WHY, not WHAT (the code shows what, comments should show why) - Don't comment simple assignments, loops, or standard patterns - Do comment: business rules, workarounds, edge case handling, performance choices - Keep comments to one line where possible

CopyI need to add [feature] to my project. Current architecture: [brief description or paste key files] Tech stack: [list] Before writing any code, plan the implementation: 1. What files need to change and what new files are needed? 2. What types/interfaces should I define? 3. What's the data model change (if any)? 4. What's the API change (if any)? 5. What are the edge cases I should handle? 6. What should I build first, second, third? Then critique your own plan: what problems or missing pieces do you see?

CopyI'm planning to implement [describe your approach]. Here's my reasoning: [explain why you chose this approach] Before I start building this, what are the problems with this approach? Be critical. Look for: - Scalability issues - Edge cases it doesn't handle - Simpler alternatives I might be missing - Maintenance burden - Security concerns Don't be polite — be useful.

CopyDesign a REST API for [describe the application]. Users can: [list all user actions] Conventions: - RESTful resource naming (plural nouns) - Response envelope: { data: T } for items, { data: T[], meta: { total, page, pageSize } } for lists - Error format: { error: string, code: string } - JWT auth via Authorization header For each endpoint, specify: method, path, request body/params, success response, and error responses.

CopyDesign a database schema for [describe the application]. Entities: [list the main entities and their relationships] Database: [SQLite / PostgreSQL / MySQL] Include: - Table definitions with appropriate column types - Primary keys, foreign keys, unique constraints - Indexes for columns that will be queried/filtered - ON DELETE behavior for foreign keys - Created/updated timestamps After the schema, note any design trade-offs you made and alternatives you considered.

CopyI'm building [describe the UI/feature]. Design the React component tree: - What components are needed? - How do they nest? (show the hierarchy) - What props does each component accept? - Where does state live? (which component owns which state) - What data flows down and what events flow up? Show the tree as an ASCII diagram, then list each component with its Props interface.

CopyPerform a security audit on this code: [paste code] Check for: - SQL injection (string interpolation in queries) - XSS vulnerabilities (unescaped user input in HTML) - Hardcoded secrets or API keys - Data exposure (returning password hashes, internal IDs) - Missing input validation - Insecure authentication logic - Missing rate limiting on auth endpoints - CORS misconfiguration - Missing Content-Security-Policy headers For each finding, show: severity (critical/high/medium), the vulnerable code, and the fix.

CopyReview this authentication implementation line by line: [paste auth code — registration, login, token verification] Check specifically for: - Password hashing algorithm and salt rounds - Token generation (is it cryptographically secure?) - Token expiration handling - Password hash exposure in API responses - Timing attack vulnerability in comparisons - Account enumeration (do login errors reveal which part was wrong?) - Session/token invalidation on password change

CopyCheck this codebase for exposed secrets and insecure configuration: [paste code or key config files] Look for: - Hardcoded API keys, tokens, or passwords - Default secrets that work in production (e.g. JWT_SECRET = 'secret') - Sensitive data in logs or error messages - Missing .env.example file - .env file that might be committed to git - Production config that's too permissive

CopyAssess the security risk of these dependencies: [paste package.json dependencies section] For each dependency: - Is it actively maintained? - Are there known vulnerabilities? - Is it from a trusted source? - Could it be replaced with a built-in alternative? Flag any dependencies that are: abandoned (no updates in 2+ years), have known CVEs, or are unnecessary (the functionality exists in Node.js or the framework).

CopyWrite a conventional commit message for this diff: [paste: git diff --cached] Format: type(scope): description Types: feat, fix, refactor, test, docs, chore, style Keep the description under 72 characters. If the change is complex, add a body explaining why (not what — the diff shows what).

CopyWrite a PR description for these changes: [paste: git diff main...HEAD] Include: - Summary (what this PR does, in 2-3 sentences) - Changes (bullet list of what was modified) - Testing (how this was tested) - Notes for reviewers (anything non-obvious or that needs extra attention)

CopyGenerate a .gitignore for a [describe your project: e.g., "TypeScript Express API with SQLite"]. Include rules for: - Build output and compiled files - Dependencies (node_modules) - Environment files (.env but not .env.example) - IDE and editor files - OS-specific files - Database files (if local SQLite) - Log files - Test coverage output Add a comment above each section explaining what it's for.