AI coding prompts that help you debug, build, and learn.

Find the cause before proposing a patch.

Act as a senior [language/framework] developer. Diagnose the runtime error below. First explain the most likely cause using only the supplied code and error output. Then propose the smallest safe fix as a diff. Do not invent missing files or APIs; list any information you still need. Finally provide exact steps to verify the fix.

Environment: [versions and operating system]
Expected behavior: [what should happen]
Actual behavior: [what happens]
Error: [paste full error]
Relevant code: [paste minimal code]

Useful when a large project hides the real failure.

Help me create a minimal reproducible example for this [language/framework] bug. Identify which parts of the supplied code are relevant, remove unrelated dependencies one at a time, and preserve the failure. Return: (1) a minimal code sample, (2) setup steps, (3) expected versus actual behavior, and (4) the next diagnostic test. Do not claim a root cause until the reduced example supports it.

Project context: [context]
Code and error: [paste]

Learn what the code does without receiving a vague summary.

Explain the code below to a developer who understands [known concepts] but is new to [topic]. Start with the overall purpose, then trace the data flow in execution order. Explain important syntax, assumptions, side effects, and failure cases. End with three questions I should be able to answer to confirm understanding. Do not rewrite the code unless a correctness issue requires attention.

Code: [paste code]

Focus the review on risk rather than personal style.

Review this change as a careful maintainer. Context: [feature and users affected]. Prioritize correctness, security, data loss, concurrency, accessibility, and backward compatibility. Ignore harmless style preferences. For every issue, cite the exact code, explain the failure scenario, assign severity, and suggest a focused fix. If you cannot verify an assumption from the diff, state what evidence is missing.

Diff: [paste diff]
Relevant requirements: [paste]

Turn a request into code with explicit acceptance criteria.

Implement [feature] in the existing [stack] project. Respect the current architecture and dependencies shown below. Acceptance criteria: [criteria]. Constraints: [browser/runtime support, libraries, performance, accessibility]. First summarize the files you expect to change. Then provide the implementation as focused diffs and the tests needed. Do not replace unrelated code or introduce a dependency without explaining why.

Relevant files: [paste]

Make improvement measurable and protect existing behavior.

Refactor the code below to improve [readability/performance/maintainability] without changing observable behavior. Identify the invariants that must remain true. Provide a small staged diff, explain each change, and add or update tests that prove behavior is preserved. Avoid speculative abstractions and keep public APIs compatible.

Code: [paste]
Existing tests: [paste]
Known constraints: [list]

Cover behavior and failure paths instead of chasing a percentage.

Design tests for the [function/component/API] below. Derive cases from its contract and risks: normal behavior, boundaries, invalid input, failure paths, and one regression scenario. Use [test framework]. For each test, state what bug it would catch, then provide runnable code. Mock only external boundaries and do not test implementation details.

Contract: [paste]
Code: [paste]

Make schema, parameters, and scale visible.

Write a parameterized [database] query that [goal]. Use only the schema below. Requirements: [filters, sorting, pagination, transaction rules]. Return the query, parameter list, and a short explanation of indexes or performance risks. Never interpolate untrusted input. If the schema cannot support the request safely, explain the missing relation or constraint instead of guessing.

Schema: [paste schema]

Account for authentication, failures, and secret handling.

Show how to integrate [API] into this [server/runtime]. Use the official API contract supplied below. Keep secrets in server-side environment variables, validate inputs, set a timeout, handle non-2xx responses, and avoid logging credentials or sensitive payloads. Provide the smallest working example plus retry and rate-limit guidance. Mark any endpoint or field you cannot verify.

API contract: [paste excerpt or link]
Existing code: [paste]

Describe behavior across screen sizes and input methods.

Build a responsive [component] in [framework]. It must support keyboard navigation, visible focus, semantic labels, loading, empty, error, and success states. Match these design tokens: [tokens]. Preserve the project’s existing component patterns. Return complete component code, minimal styles, and interaction tests. Explain any accessibility decision that is not obvious.

Existing patterns: [paste]

Measure first and optimize the actual bottleneck.

Help diagnose this performance problem in [system]. Symptom: [symptom]. Baseline measurement: [metric]. Workload: [data size and traffic]. Analyze the evidence below, rank possible bottlenecks, and propose one measurement that would confirm or reject each. Recommend an optimization only after connecting it to evidence, and include a rollback or comparison plan.

Profiling data/logs: [paste]

Use explanation, prediction, and practice—not just an answer.

Teach me [concept] using [language]. My current level: [level]. Begin with a plain-language mental model, then show one small example and trace it line by line. Ask me to predict the output of a second example before revealing the explanation. Finish with a short exercise and a checklist for evaluating my solution. Do not solve the final exercise unless I ask.