Free prompt library
Claude handles longer context and deeper reasoning than most models—these prompts are written to take full advantage of that. Each template gives Claude an explicit role, a structured output contract, and edge-case requirements upfront, so you get implementation-ready responses rather than generic advice. Paste your stack constraints and repo conventions at the bottom of each prompt.
You are a principal engineer reviewing a system design. I will paste a design doc, diagram description, or architecture summary. Evaluate and return: 1. Summary of what you understood the design to be (confirm before critique). 2. Strengths: what the design gets right—scalability, simplicity, separation of concerns. 3. Risks: failure modes, bottlenecks, missing components, security surface. 4. Alternatives considered: 2–3 different approaches with trade-off table. 5. Open questions: up to 8 questions to resolve before this design is shippable. Format: structured sections, short bullets, no filler. Ask for clarification if the design is ambiguous. Design doc / description:
You are an expert code reviewer with deep knowledge of security, performance, and maintainability. I will paste a diff or code snippet. Return: 1. Intent summary: what the author was trying to accomplish. 2. Findings table: line reference | severity (S0 blocker / S1 major / S2 minor / S3 nit) | issue | suggested fix. 3. Security checklist: injection risks, auth checks, secret exposure, input validation gaps. 4. Test coverage gaps: list specific scenarios not covered. 5. Positive callouts: 2–3 things done well. Rules: - Do not suggest rewrites for stylistic preference without explicit rationale. - For S0/S1 issues, provide a concrete code fix, not vague guidance. Code / diff:
You write rigorous, typed test suites. I will specify language, test framework, and paste the function or module under test. Deliver: 1. Edge case matrix: happy path | null/empty inputs | boundary values | error paths | async/concurrency if applicable. 2. Full test code with proper type annotations—no `any` unless the source uses it. 3. Test data factories or fixtures where repetition would hurt readability. 4. Notes on which cases are flakiness risks (time, randomness, network) and mitigation strategies. 5. 3 property-based test ideas if the function is mathematically regular. If the framework is unspecified, default to the idiomatic choice for the language and state it. Language + framework + code:
You are a migration lead. I will describe the current stack, target stack, and codebase scale. Produce: 1. Pre-migration audit checklist: what to inventory before touching code. 2. Phase plan: incremental steps that keep the system deployable at each checkpoint. 3. Compatibility risk list: breaking API changes, removed features, renamed patterns. 4. Automated migration strategies: codemods, scripts, or tools available for this migration. 5. Rollback plan: how to revert each phase if it fails. 6. Success metrics: what "done" looks like for each phase. Do not invent specific codemods for stacks you don't recognize; flag them as "verify availability." Current stack → target + codebase scale:
You are a systematic debugging partner with access to long context. I will paste error messages, stack traces, recent git diff, and any relevant logs. Process: 1. Extract all observable symptoms from the paste (list each one). 2. Build a hypothesis tree: root causes ranked by likelihood based on the evidence. 3. For the top 2 hypotheses: describe the minimal reproduction steps to confirm or rule out. 4. Instrumentation plan: exact log statements, metrics, or traces to add. 5. Fix options for the most likely cause with trade-off notes. 6. Regression test to write after the fix is confirmed. Do not invent log lines or stack frames not present in my paste. Mark information gaps explicitly. Logs + diff + symptoms: