Proven prompts for coding with Claude

Add a <METHOD> <route> endpoint following the pattern in @<router-file>. Validate the input, return typed responses, and add one happy-path test plus one error-case test.

Implement <function>. Example cases: <input → output>, <input → output>. After implementing, run the tests and show me they pass — show the output, don't just assert that it works.

Create a new component like @<existing> but for <use case>. Reuse its props style, file structure, and styling approach — don't invent new conventions.

Implement <feature> in @<file>. Match the existing patterns in this file. Add types, handle the error cases, and stop after the minimal working version — no extra abstractions.

Build <thing>. Include as many relevant features and interactions as you can think of — go beyond the basics to create a fully-featured version, not a minimal one.

[paste screenshot] Build this component in <framework>. Then take a screenshot of your result, compare it against the mockup, and list the visual differences you still need to fix.

We keep repeating <workflow>. Create a Claude Skill for it: a SKILL.md with YAML frontmatter (a name, and a description that says both what it does AND when to use it), plus any helper scripts. Keep the body concise.

Before writing any code, outline a short plan for <feature>: the files you'll create or touch, the key functions, and the data flow between them. Wait for my OK, then implement.

Write failing tests for <behavior> first and show them to me. Once I confirm, implement until they pass. Don't modify the tests without asking.

I want to build <feature>. Before writing any code, interview me one question at a time — cover the implementation approach, UX, edge cases, and tradeoffs. When we're done, write the agreed decisions to SPEC.md and stop.

Bug: <what users actually see>. It most likely lives in <area or files>. A correct fix means <observable success>. Write a failing test that reproduces it first, then fix the root cause.

Use a subagent to investigate how <system or flow> works across the codebase and report back a concise summary. Don't change anything yet — just map it out.

tail -n 200 <logfile> | claude -p "Flag any anomalies or errors in these logs and name the most likely root cause."

Add targeted logging to narrow down <issue>. Tell me exactly what output to look for and what each value would mean. Once we've found the cause, remove the logs.

Read <file> in full before you answer. Never speculate about code you haven't opened — if you need another file to be sure, open it first, then explain what's wrong.

This worked before my recent changes. Review the diff in @<files> and identify which specific change most likely caused <symptom>. Explain the mechanism.

Write a minimal failing test that reproduces this bug and confirm it fails. Then fix the underlying cause and show the same test passing.

Here's the error: <paste>. Don't fix anything yet — trace the root cause, list the top 2 hypotheses ranked by likelihood, and tell me which files to look at.

[paste screenshot of the error or broken UI] What's causing this? Trace it to the responsible code and explain the mechanism before proposing a fix.

Given this stack trace <paste>, point to the exact line responsible and explain in 2 sentences what is null/undefined/throwing and why.

@<file> has repeated logic in <functions>. Extract a shared helper without changing behavior. Keep the public API identical, and run the tests to confirm nothing broke.

List every file that needs the <X → Y> migration, and for each one describe the exact change. I'll then run you over each file with a scoped, tightly-permissioned command — for now, just produce that per-file plan.

Find all usages of <deprecated API or pattern> across the codebase and list them with file paths. Then propose a refactor plan in small, testable steps — don't change anything yet.

Fix <function> so it works correctly for all valid inputs. Implement the real logic that generalizes — do not hard-code values or special-case the tests just to make them pass.

Refactor <target>. Only make changes that are directly requested or clearly necessary — no new abstractions, no extra config, and no defensive code for cases that can't actually happen.

Rename <old> to <new> across the codebase. Update all references and imports, and don't touch any unrelated code. Show me the list of files changed.

Refactor <function> in @<file> for readability — early returns, clearer names, fewer nested branches. Behavior must stay identical; show me a before/after of the tricky parts.

@<file> is too large. Propose a split into cohesive modules with concrete names and responsibilities. Wait for my OK, then move the code and fix all imports.

Replace any/loose types in @<file> with precise types inferred from how the values are actually used. Don't change runtime behavior, and flag anything that reveals a real bug.

Look through the git history of <file> and summarize how its API evolved and why, before we refactor it. Flag any change that looks like it was made to fix a specific bug.

Review my current diff for correctness bugs and edge cases only. List findings by severity (high/medium/low). Skip style nits and formatting.

Analyze these code paths and list the tests I'm missing — error conditions, boundary values, and unexpected inputs I haven't covered. Don't write them yet, just enumerate the gaps.

Explain what @<file> does in plain language, step by step. Then flag anything that looks unintentional or inconsistent with the rest of the module.

In a fresh context, review this diff and report only gaps that affect correctness or the stated requirements — ignore style. For each finding give the file, the risk, and a concrete fix.

Scan @<file> for performance issues that matter at scale — N+1 queries, needless allocations in hot paths, blocking calls in async code. Only flag things with real impact, and estimate the cost of each.

Act as a strict reviewer. Does this change actually do what the PR description claims? Call out untested paths, missing error handling, and anything that would block approval.

Review the diff against PLAN.md: is every requirement implemented, are the listed edge cases tested, and did anything change that was out of scope? List gaps and scope creep separately.

Audit @<file> for injection, auth, and secret-handling issues. For each finding give the concrete risk, a reproduction path, and a specific fix. Ignore theoretical issues that can't happen given how it's called.

Review this diff and structure your findings with XML tags — <correctness>, <security>, <performance>, <style> — so I can scan each category separately. Put the most serious issues first within each.

You didn't write this code. Review <file> for edge cases, race conditions, and consistency with our existing patterns. Be skeptical and assume there's at least one problem.