50 Claude Prompts for Developers

Review this pull request diff for issues. Diff: [paste diff]. Check for: bugs, security vulnerabilities, performance issues, naming inconsistencies, missing error handling, and deviations from [language/framework] best practices. Rate severity of each finding as critical, warning, or suggestion.

Tip: Pasting the full diff rather than individual files lets Claude catch cross-file inconsistencies.

Analyze this codebase structure and identify architectural concerns. Files: [paste file tree or key files]. Evaluate: separation of concerns, dependency direction, coupling between modules, naming conventions, and consistency. Suggest a refactoring roadmap prioritized by impact.

Tip: Claude's long context window is ideal for analyzing entire module structures at once.

Read this function and explain what it does as if writing documentation for a new team member: [paste code]. Include: purpose, parameters, return value, side effects, error conditions, and a usage example. Flag any behavior that is surprising or non-obvious.

Tip: Asking Claude to flag 'surprising behavior' surfaces hidden side effects and implicit assumptions.

Compare these two implementation approaches for [feature]: Approach A: [paste code]. Approach B: [paste code]. Evaluate: correctness, readability, performance, testability, and maintainability. Recommend which to use and under what circumstances you would choose the other.

Tip: Asking Claude to identify when the losing approach would win ensures you understand the tradeoffs, not just the conclusion.

I need to design a [system type] that handles [requirements]. Think step by step through the design. Consider: data model, API contracts, service boundaries, failure modes, and scaling bottlenecks. Present 2 approaches with tradeoffs, then recommend one with justification.

Tip: Claude's extended thinking shines on system design. Let it reason through tradeoffs rather than jumping to a solution.

Here is our current system architecture: [describe or paste diagram]. We need to add [new feature/requirement]. Analyze the impact on existing components, identify integration points, flag potential issues, and propose the minimal changes needed.

Tip: Describing the existing system helps Claude propose changes that fit your architecture rather than greenfield solutions.

Design an event-driven architecture for [use case]. Define: events, producers, consumers, event schema, ordering guarantees needed, idempotency strategy, dead letter handling, and monitoring. Use [message broker].

Tip: Always specify ordering and idempotency requirements — they fundamentally shape event-driven architectures.

We are experiencing [performance issue] at [scale]. Current architecture: [describe]. Profile data: [paste if available]. Diagnose the most likely bottleneck, propose 3 solutions ranked by effort-to-impact ratio, and outline implementation steps for the top recommendation.

Tip: Real performance data (response times, query profiles) helps Claude diagnose the actual bottleneck rather than guessing.

Generate API documentation for these endpoints: [paste route definitions or OpenAPI spec]. For each: description, parameters with types and validation rules, request/response examples, error responses, and authentication requirements. Format as Markdown.

Tip: Pasting actual code or specs produces more accurate docs than describing endpoints verbally.

Write a technical design document for [feature]. Sections: Problem Statement, Goals and Non-Goals, Proposed Solution, Data Model Changes, API Changes, Migration Plan, Security Considerations, Testing Strategy, Rollout Plan, and Open Questions.

Tip: Non-goals are as important as goals — they prevent scope creep during implementation.

Create an onboarding guide for a new developer joining the [project name] codebase. Cover: repository structure, local setup, architecture overview, key conventions, common workflows, debugging tips, and 'things I wish I knew on day one.'

Tip: The best onboarding docs are written by someone who recently onboarded. Use Claude to draft, then validate with a recent hire.

I am stuck on this algorithmic problem: [describe problem with constraints]. Think through it step by step. Consider brute force first, then optimize. Analyze time and space complexity of each approach. Implement the optimal solution in [language] with comments explaining the logic.

Tip: Letting Claude show its reasoning step by step for algorithms produces better solutions than asking for the answer directly.

We have a race condition in this concurrent code: [paste code]. Multiple [threads/processes/requests] access [shared resource]. Walk through the execution timeline showing how the race occurs, then provide a fix using [mutex/semaphore/atomic/lock-free approach].

Tip: Ask Claude to trace the execution timeline — visualizing the interleaving is the key to understanding race conditions.

Convert this complex SQL query to [ORM] code, maintaining identical behavior: [paste SQL]. Then convert this [ORM] code to raw SQL: [paste ORM code]. Explain any behavioral differences and edge cases where they might diverge.

Tip: Bidirectional translation (SQL to ORM and ORM to SQL) catches subtle behavioral differences ORMs hide.

I need to implement [complex feature] with these constraints: [list constraints]. Break this into subtasks, define the interface for each, identify dependencies between them, and implement the most critical subtask first with full code.

Tip: Having Claude decompose before implementing prevents monolithic solutions that are hard to test and debug.

Write a Dockerfile for a [language/framework] application. Requirements: multi-stage build, non-root user, minimal image size, proper layer caching, health check, security best practices, and .dockerignore. Explain each decision.

Tip: Multi-stage builds can reduce image size by 10x. Always separate build dependencies from runtime.

Create Infrastructure as Code using [Terraform/Pulumi/CDK] for [describe infrastructure]. Include: compute, networking, database, storage, IAM roles with least privilege, monitoring, and auto-scaling. Add comments explaining security decisions.

Tip: Least-privilege IAM from the start is far easier than retrofitting permissions later.

Design a monitoring and alerting strategy for [application type] running on [infrastructure]. Define: key metrics, log aggregation, trace sampling, dashboard layout, alert thresholds, escalation policy, and runbook templates for the top 5 expected incidents.

Tip: Alert on symptoms (latency, error rate) not causes (CPU, memory) to reduce alert noise.

Write a disaster recovery plan for [system]. Cover: RTO and RPO targets, backup strategy, failover procedure, data recovery steps, communication plan, post-incident review template, and quarterly DR testing checklist.

Tip: A DR plan that is never tested is just a wish. Include the testing schedule in the plan itself.