20 Claude Prompts for Coding That Ship Better Code

<context> I'm working on a [language/framework] project. The codebase uses [architecture pattern, e.g. MVC, clean architecture]. Here's the relevant existing code structure: [paste file tree or key files] </context> <task> Implement the following feature: [describe the feature in plain English] Requirements: 1. [requirement 1] 2. [requirement 2] 3. [requirement 3] </task> <constraints> - Follow the existing code style and patterns in the codebase - Include error handling for edge cases - No external dependencies unless absolutely necessary - Write code that a mid-level developer can maintain </constraints> <format> Return each file as a separate code block with the file path as the header. Include inline comments only where the logic isn't self-evident. </format>

<context> Stack: [e.g. Node.js/Express, Python/FastAPI, Go/Gin] Database: [e.g. PostgreSQL with Prisma ORM] Auth: [e.g. JWT, session-based, API key] Existing patterns: [paste one existing endpoint for reference] </context> <task> Create a complete REST API endpoint for: - Resource: [e.g. /api/users/:id/settings] - Methods: [GET, PUT, DELETE] - Include: route handler, validation, service layer, database queries </task> <constraints> - Match the existing endpoint patterns exactly - Validate all input (params, body, query strings) - Return consistent error responses with proper HTTP status codes - Include rate limiting considerations in comments </constraints>

<context> Source language: [e.g. Python] Target language: [e.g. TypeScript] Target framework: [e.g. Next.js with App Router] </context> <task> Convert the following code to [target language], preserving the exact same logic and behavior: [paste source code] </task> <constraints> - Use idiomatic [target language] patterns — don't write [source language]-style code in [target language] - Preserve all edge case handling - Use the target language's type system fully (no 'any' types in TypeScript) - Flag any features that don't have a direct equivalent and explain the workaround </constraints> <format> Return the converted code, then a "Migration Notes" section listing any behavioral differences or caveats. </format>

<context> Database: [e.g. PostgreSQL] ORM: [e.g. Prisma, Drizzle, SQLAlchemy, raw SQL] Existing schema: [paste current schema or describe existing tables] </context> <task> Design and write the schema/migration for: [describe the data model — entities, relationships, constraints] Include: 1. Table definitions with proper types and constraints 2. Indexes for common query patterns 3. Migration file(s) 4. Seed data for development </task> <constraints> - Use appropriate data types (don't default everything to VARCHAR) - Add foreign key constraints with proper ON DELETE behavior - Include created_at/updated_at timestamps - Consider query performance — add indexes for fields used in WHERE and JOIN - No duplicate data — normalize unless there's a performance reason not to </constraints>

<context> Language: [language] Environment: [e.g. Node.js 20, Python 3.12, browser] What should happen: [expected behavior] What actually happens: [actual behavior] Error message (if any): [paste error] </context> <task> Debug this code and explain exactly what's wrong: [paste the code] Provide: 1. The root cause (not just the symptom) 2. The fix with explanation 3. How to prevent this class of bug in the future </task> <constraints> - Don't just say "the issue is on line X" — explain WHY it's wrong - If there are multiple issues, list all of them, not just the first one - Show the fixed code as a complete replacement, not just a diff </constraints>

<context> Project: [describe project and its purpose] This PR: [describe what this PR does] Team coding standards: [mention any specific standards or link] </context> <task> Review this code change as a senior developer. For each issue found, categorize as: - 🔴 Blocker: Must fix before merge - 🟡 Suggestion: Should fix, not blocking - 💡 Nit: Style preference, take it or leave it Focus on: 1. Logic errors or edge cases 2. Security vulnerabilities 3. Performance issues 4. Maintainability concerns 5. Missing tests or test gaps </task> <constraints> - Be specific — cite the exact line and explain the issue - For each issue, provide the fix, not just the problem - Don't flag style issues that a linter should catch - If the code is good, say so — don't invent problems </constraints> Here's the diff: [paste the diff or code]

<task> I'm new to this codebase and need to understand how it works. Explain the following code as if you're onboarding a new team member: [paste the code — can be multiple files] </task> <format> Structure your explanation as: 1. **High-level overview** — What does this code do in one paragraph? 2. **Architecture** — How are the pieces connected? (include a simple ASCII diagram) 3. **Key concepts** — What patterns or abstractions does a reader need to understand? 4. **Data flow** — Walk through a typical request/operation step by step 5. **Gotchas** — What's non-obvious or likely to trip someone up? </format> <constraints> - Assume I know [language] but not this specific codebase - Don't explain basic language features — focus on architecture and design decisions - If something looks like a workaround or tech debt, flag it </constraints>

<context> Application type: [e.g. web app, API, CLI tool] Framework: [e.g. Express, Django, Rails] Auth method: [e.g. JWT, sessions, OAuth] </context> <task> Audit this code for security vulnerabilities: [paste code] For each vulnerability found: 1. What it is (name the vulnerability type — XSS, SQLi, IDOR, etc.) 2. How it could be exploited (specific attack scenario) 3. The fix (show the corrected code) 4. Severity: Critical / High / Medium / Low </task> <constraints> - Focus on OWASP Top 10 categories - Don't flag theoretical issues that require unlikely conditions — focus on exploitable vulnerabilities - If the code looks secure, say so and explain what it's doing right - Check for: injection, auth bypass, data exposure, CSRF, insecure deserialization </constraints>

<context> Language: [language] Test framework: [e.g. Jest, pytest, Go testing, RSpec] Code to test: [paste the function/module/class] </context> <task> Write a comprehensive test suite covering: 1. Happy path — expected inputs produce expected outputs 2. Edge cases — boundary values, empty inputs, null/undefined 3. Error cases — invalid inputs, network failures, timeouts 4. Integration points — if it calls other services, mock them properly </task> <constraints> - Each test should test ONE thing (clear test name = clear intent) - Use descriptive test names: "should [expected behavior] when [condition]" - Don't test implementation details — test behavior - Group related tests with describe/context blocks - Include setup and teardown where needed </constraints>

<context> App type: [e.g. Next.js web app] E2E framework: [e.g. Playwright, Cypress, Selenium] Feature to test: [describe the user flow] Test environment: [e.g. local dev, staging] </context> <task> Write E2E tests for this user flow: [describe step by step what the user does] Include: 1. Happy path test 2. Error state test (what if something fails?) 3. Edge case test (what if the user does something unexpected?) </task> <constraints> - Use realistic test data, not "test123" - Wait for elements properly — no arbitrary sleep/delays - Tests should be independent (no test depends on another test's state) - Include proper selectors (prefer data-testid over CSS classes) - Clean up test data after each test </constraints>

<task> Generate test data for the following data model: [paste your type definitions, schema, or describe the data structure] Create: 1. A factory function that generates valid test data with sensible defaults 2. 5 realistic fixture records covering different scenarios (not just random data) 3. Edge case fixtures: empty strings, max-length values, Unicode, special characters 4. Invalid data fixtures for testing validation </task> <constraints> - Use realistic names, emails, dates — not "John Doe" or "[email protected]" - Date values should be relative (e.g. "3 days ago") not hardcoded - Factory function should accept partial overrides for any field - Cover the boundary values for any numeric fields </constraints> <format> Return the factory function first, then the fixture data as named exports. </format>

<context> Language: [language] Test framework: [e.g. Jest, pytest] This code has NO existing tests. It works in production but we need to add a test safety net before refactoring. </context> <task> Create a test strategy and initial test suite for this legacy code: [paste the code] Approach: 1. First, identify what this code actually does (document the current behavior) 2. Write characterization tests that capture the CURRENT behavior (even if it has bugs) 3. Identify the riskiest areas that need tests most urgently 4. Flag any code that's untestable in its current form and suggest minimal refactors to make it testable </task> <constraints> - Don't refactor the production code — only suggest the minimum changes needed for testability - Characterization tests should pass against the current code, not idealized behavior - Mark any tests that capture suspected bugs with a clear comment - Focus on the public API, not internal implementation </constraints>

<context> Problem: [what are you building and why] Scale: [expected users/requests/data volume] Team: [team size and experience level] Existing infrastructure: [cloud provider, current stack] Budget constraints: [if any] </context> <task> Design a system architecture that solves this problem: [detailed description of requirements] Include: 1. High-level architecture diagram (ASCII) 2. Component breakdown with responsibilities 3. Data flow for the 3 most common operations 4. Technology choices with reasoning (not just "use Kafka") 5. Trade-offs you're making and why </task> <constraints> - Optimize for the stated scale — don't over-engineer for 10x growth that isn't certain - Every technology choice must have a "why this over alternatives" justification - Address: scalability, reliability, security, and developer experience - Include a "what I'd add at 10x scale" section separately </constraints>

<context> Codebase: [language/framework, approximate size] Pain points: [what's causing problems — slow builds, bugs, hard to add features, etc.] Team capacity: [how much time can you dedicate to refactoring] </context> <task> Create a refactoring plan for this code: [paste the code or describe the architecture] Provide: 1. Assessment: What's the actual problem? (not just "it's messy") 2. Priority-ordered list of refactors with effort estimates (S/M/L) 3. For each refactor: what it fixes, risk level, and how to verify it worked 4. A migration strategy that doesn't require a big-bang rewrite 5. What to leave alone (not everything needs fixing) </task> <constraints> - Each refactor must be deployable independently (no "refactor everything then ship") - Include rollback strategies for risky changes - Estimate effort realistically — account for testing and code review time - Prioritize by: impact on team velocity > code quality > consistency </constraints>

<context> Application: [describe the application] Database: [e.g. PostgreSQL, MongoDB, DynamoDB] Expected scale: [number of records, query patterns, read/write ratio] </context> <task> Design a database schema for these requirements: [list requirements — entities, relationships, business rules] Provide: 1. Entity-relationship diagram (ASCII) 2. Table definitions with types, constraints, and indexes 3. Explanation of normalization decisions (when you chose to denormalize and why) 4. Common query patterns and which indexes support them 5. Migration path if requirements change (what's easy to change vs. hard) </task> <constraints> - Optimize for the stated query patterns, not theoretical perfection - Include soft deletes if the business needs audit trails - Use appropriate types (don't make everything a string) - Consider: concurrent writes, eventual consistency needs, data growth </constraints>