28 Claude Prompts for Coding (2026)

Write a well-tested function from this spec.

Language: [language]. The function should [inputs -> behavior -> outputs].
It must handle: [edge cases].
<spec>
[any extra detail, examples of input/output]
</spec>

Constraints:
- Clean, idiomatic code following [style/convention].
- Input validation and clear error handling.
- Unit tests for the happy path and every edge case above.
- One-line comments only where the intent isn't obvious.

Build a working single-file app and render it as an Artifact.

What it does: [describe the tool]. Users: [who], on [mobile / desktop].

Constraints:
- One self-contained HTML file with inline CSS and JS, no external dependencies.
- Clean, responsive UI; sensible defaults; handle empty and error states.
- Comment the main sections.
- After it works, list 3 features I could add next and the trade-offs.

Scaffold a [component / module / endpoint] for me.

Stack: [framework and version]. It should [responsibility]. It talks to [DB / API / other modules].
<context>
[paste related types, interfaces, or a sibling file to match the pattern]
</context>

Constraints:
- Match the conventions in the code I pasted.
- Include types, error handling, and a minimal test.
- Leave clearly marked TODOs where I need to fill in business logic.
- Explain the file structure in 3 lines at the top of your reply.

Write a SQL query that answers a question about my data.

Database: [Postgres / MySQL / BigQuery / SQLite].
<schema>
[paste the relevant CREATE TABLE statements or column lists]
</schema>
Question: [what I want to know].

Do this:
- Give the exact query, formatted and readable.
- Explain each join and filter in one line.
- Note any performance concern and an index that would help.
- Warn me about edge cases (NULLs, duplicates, time zones).

Explain what this code does, then add helpful comments.

<code>
[paste the code]
</code>

Do this:
- Give a plain-English summary of what it does and why.
- Walk through it in the order it executes, calling out anything non-obvious.
- Return the same code with concise comments added — do not change the logic.
- Flag anything that looks like a bug or a bad practice.

Diagnose and fix this error. Think step by step before answering.

<error>
[paste the full error and stack trace]
</error>
<code>
[paste the relevant code]
</code>
Expected: [what should happen]. Actual: [what happens].

Do this:
- Most likely root cause first, then 2 alternates.
- The exact fix and where it goes.
- How to confirm it's resolved.
- One thing that would stop this class of bug recurring.

A test is failing and I'm not sure whether the test or the code is wrong.

<test>
[paste the failing test]
</test>
<code>
[paste the code under test]
</code>
<output>
[paste the failure output]
</output>

Do this:
- Tell me whether the bug is in the test or the code, and how you know.
- Give the minimal fix.
- If the test was asserting the wrong thing, explain the correct expected behavior.

Help me reproduce and isolate a bug from a vague report.

The report: "[paste the user's description]".
<code>
[paste the suspected area of code]
</code>

Do this:
- List the most likely conditions that trigger this, ranked.
- Give me the smallest reproduction steps to confirm each hypothesis.
- Suggest the log lines or asserts to add to narrow it down.
- Once I confirm which, tell me the fix.

Explain why this code behaves the way it does.

<code>
[paste the code]
</code>
What I expected: [expectation]. What actually happens: [behavior].

Do this:
- Explain the real mechanism causing the behavior (language semantics, async, references, etc.).
- Show a minimal example that demonstrates the cause.
- Give the idiomatic fix and why it's correct.

Find why this is slow and how to make it faster. Think step by step.

<code>
[paste the code]
</code>
Context: it processes [scale, e.g. 100k rows] and currently takes [time].

Do this:
- Identify the likely bottleneck(s) with reasoning about complexity.
- Rank fixes by impact vs. effort.
- Give the highest-impact fix as concrete code.
- Warn me about any correctness or memory trade-offs.

Act as a staff engineer doing a careful review. Think step by step.

What this change is meant to do: [intent].
<code>
[paste the diff or the files]
</code>

Do this:
- List issues most severe first: correctness, security, edge cases, then style.
- For each, give the location and a concrete fix.
- Call out anything I got right so I keep doing it.
- Don't rewrite the whole file — point to specific lines.

Review this code for security issues only.

Context: it [handles user input / touches auth / calls external APIs].
<code>
[paste the code]
</code>

Do this:
- Flag injection, auth/authorization gaps, unsafe deserialization, secrets in code, and SSRF/XSS/CSRF where relevant.
- Rate each finding (high/medium/low) with the attack it enables.
- Give the fix for each.
- Note anything you can't judge without seeing more of the system.

Be the reviewer who catches what I'd be embarrassed to have a human catch.

<code>
[paste your change]
</code>

Do this:
- Point out the obvious misses first: naming, dead code, missing error handling, off-by-one, forgotten TODOs.
- Then the subtle ones: edge cases, race conditions, unclear intent.
- Suggest the 3 changes that would most improve this before review.
Be blunt.

Write documentation for this code.

Audience: [teammates / external users / future me].
<code>
[paste the module or API]
</code>

Do this:
- A short "what and why" overview.
- Usage examples that actually run.
- Parameters, return values, and errors in a table.
- Gotchas and assumptions a newcomer would trip on.
Match the tone of docs a good open-source project would ship.

Help me design a feature before I write code. Think step by step.

Feature: [what it should do]. Stack: [stack]. Constraints: [perf, deadline, existing patterns].
<context>
[paste relevant existing code or data model]
</context>

Do this:
- Propose 2 approaches with trade-offs.
- Recommend one and explain why.
- Sketch the data model / interfaces / main steps.
- List the edge cases and failure modes to handle.
Don't write the full implementation yet — just the plan.

Refactor this for readability without changing behavior.

<code>
[paste the code]
</code>

Do this:
- Keep the exact same inputs and outputs.
- Improve naming, structure, and duplication.
- Show the refactored version, then list what changed and why.
- Flag anything that looked like a latent bug while you were in there.

Split this large function into smaller, well-named pieces.

<code>
[paste the long function]
</code>

Do this:
- Extract logical units into named helpers with single responsibilities.
- Keep behavior identical; note any hidden coupling you find.
- Show the result and a one-line summary of each new function's job.
- Suggest where a test would lock in the behavior before I ship.

Migrate this code from [old library/version] to [new library/version].

<code>
[paste the code using the old API]
</code>

Do this:
- Rewrite it using the new API, preserving behavior.
- List every changed call and what replaced it, in a table.
- Flag deprecations, breaking changes, and anything I must test.
- Note anything the new version handles differently that could bite me.
If you're unsure about a current API detail, say so instead of guessing.

Add types to this code without changing behavior.

Language/target: [TypeScript / Python type hints / etc.].
<code>
[paste the untyped code]
</code>

Do this:
- Add accurate types; avoid "any"/loose types unless truly necessary.
- Where a type reveals a possible bug, flag it instead of hiding it.
- Keep runtime behavior identical.
- List any place the types surfaced an inconsistency I should check.

Write thorough unit tests for this code.

Framework: [Jest / pytest / etc.].
<code>
[paste the code]
</code>

Do this:
- Cover the happy path, edge cases, and error paths.
- Include the boundary cases I'd forget (empty, null, max, negative, unicode).
- Name each test after the behavior it verifies.
- Point out any behavior that's hard to test and why — it may signal a design issue.

Here's my code and my existing tests. Tell me what I'm not testing.

<code>
[paste the code]
</code>
<tests>
[paste the current tests]
</tests>

Do this:
- List the untested paths, branches, and edge cases, ranked by risk.
- Write tests for the top 5 gaps.
- Flag any behavior that looks untested because it's actually unreachable or dead code.

Generate realistic test data for this.

<schema>
[paste the type, schema, or example record]
</schema>

Do this:
- Produce [N] varied, realistic records covering normal, edge, and invalid cases.
- Include the nasty ones: empty strings, unicode, very long values, boundary numbers, missing optional fields.
- Return it as [JSON / CSV / SQL inserts] I can paste straight in.
- Label which records are meant to be invalid and why.

This test passes sometimes and fails others. Help me find why. Think step by step.

<test>
[paste the test]
</test>
<code>
[paste the code it exercises]
</code>

Do this:
- List the usual causes of flakiness that could apply here (timing, ordering, shared state, randomness, time/timezone, network).
- Rank which is most likely given this code.
- Give the fix that makes it deterministic.

Before we change anything, get your bearings in this repo.

Do this:
- Map the project: languages, frameworks, entry points, and how it's built and tested.
- Summarize the architecture in a short paragraph plus a bullet list of the main modules.
- Tell me the commands to build, run, lint, and test.
- List anything unusual or fragile I should know before we make changes.
Don't edit any files yet — just report back.

Implement this change across the repo.

Goal: [what should be true when you're done]. Acceptance: [how we'll know it works].

Do this:
- Find the files involved and outline your plan before editing.
- Make the change following the codebase's existing patterns.
- Add or update tests, then run them and fix failures.
- Show me a summary of what changed and why.
Ask before anything destructive (deleting files, migrations, force-push).

Summarize the changes on this branch into a commit message and PR description.

Do this:
- A concise, conventional commit message (subject under 72 chars + body).
- A PR description: what changed, why, how it was tested, and any risk.
- A short reviewer checklist for this change.
- Call out anything a reviewer should look at most closely.
Base it on the actual diff, not assumptions.

I need to change [file/area] but it has no tests. Make it safe first.

Do this:
- Read the code and describe its current behavior precisely (a "characterization" of what it does now, bugs and all).
- Write tests that lock in that current behavior so I'll notice if my change breaks it.
- Run them and confirm they pass against the code as-is.
- Then tell me the safest order to make my intended change: [describe change].

Reproduce and fix this bug in the repo. Think step by step.

Symptom: [what's wrong]. Steps to reproduce: [steps]. Expected vs actual: [both].

Do this:
- Reproduce it (write a failing test or run the repro steps) and confirm you see the bug.
- Trace it to the root cause across files.
- Fix it with the smallest safe change.
- Re-run the test/repro to prove it's fixed, and check nothing else broke.
Report the root cause, the fix, and how you verified it.