ChatGPT Prompts for Developers

<context> Language/framework: [LANGUAGE]/[FRAMEWORK]. I am getting this error: [ERROR]. Full stack trace: [PASTE TRACE]. The code at the failing line: [PASTE SNIPPET]. What I expected to happen: [DESCRIBE]. </context> <task> 1. Explain in plain terms what this error means and what triggers it. 2. Identify the most likely root cause given the trace and snippet, then list 2 alternative causes ranked by probability. 3. Tell me exactly what to log or inspect to confirm the root cause before changing code. 4. Provide the minimal fix as a diff once the cause is the most likely one. 5. Suggest a guard or test so this class of error cannot silently return. </task>

<context> Intermittent bug: [DESCRIBE SYMPTOM]. It happens roughly [FREQUENCY / CONDITIONS]. Stack: [LANGUAGE]/[FRAMEWORK]. Suspect area: [PASTE CODE]. </context> <task> 1. List the categories of cause for intermittent behavior here (race condition, ordering, caching, time/timezone, external dependency, resource limits) and rank them for this case. 2. For the top 2 causes, give me a concrete way to force the bug to reproduce reliably. 3. Suggest targeted logging or instrumentation to capture state at the moment of failure. 4. Propose a fix for each top cause, noting how to verify it actually removed the flakiness. </task>

<context> This code is failing and I did not write it: [PASTE CODE]. The error or wrong output: [ERROR / DESCRIBE]. Stack: [LANGUAGE]/[FRAMEWORK]. </context> <task> 1. Walk through the code line by line in plain English, noting what each block does. 2. Identify the data flow and where my error could originate. 3. Point to the specific line(s) most likely responsible and explain why. 4. Suggest the smallest safe change to fix it without altering unrelated behavior. 5. Note anything in this code that looks intentional but risky, so I do not break a hidden contract. </task>

<context> A path that was fast is now slow: [DESCRIBE OPERATION]. Stack: [LANGUAGE]/[FRAMEWORK]. Relevant code: [PASTE]. Any profiling data I have: [PASTE OR SAY NONE]. </context> <task> 1. List the likely sources of the slowdown for this operation (N+1 queries, missing index, unbounded loop, blocking I/O, excess allocation) ranked by likelihood. 2. Tell me what to measure to confirm the bottleneck before optimizing. 3. Give the fix for the most likely cause as a diff, preserving behavior. 4. Explain the expected complexity or query-count improvement. 5. Suggest a lightweight regression check so the slowdown cannot creep back. </task>

<context> Production issue right now: [DESCRIBE IMPACT]. Symptoms and any logs/metrics: [PASTE]. Stack: [LANGUAGE]/[FRAMEWORK]. Recent changes: [LIST DEPLOYS / CONFIG CHANGES]. </context> <task> 1. Propose the fastest mitigation to stop user impact, even if it is a temporary workaround (rollback, flag off, scale, rate-limit). 2. Separate mitigation from root cause — tell me what to do first. 3. List the top 3 suspected causes given the recent changes and how to confirm each quickly. 4. Draft a concise status update I can post to the team. 5. Outline the follow-up fix and a post-incident checklist. </task>

<context> I want to refactor this [LANGUAGE]/[FRAMEWORK] code for readability and maintainability without changing behavior: [PASTE CODE]. Constraints: [PUBLIC API MUST STAY / PERFORMANCE BUDGET / ETC]. </context> <task> 1. Identify specific code smells (long function, duplication, deep nesting, unclear names) with the line they appear on. 2. Propose a refactor as a diff that preserves the exact external behavior and public signatures. 3. Explain each change and why it improves the code, not just that it does. 4. List the tests I should run or add to prove behavior is unchanged. 5. Do the refactor in small reviewable steps, not one giant rewrite. </task>

<context> This file has grown too large and does too much: [PASTE FILE OR DESCRIBE]. Stack: [LANGUAGE]/[FRAMEWORK]. I want to split it into cohesive modules. </context> <task> 1. Identify the distinct responsibilities currently tangled in this file. 2. Propose a module/file breakdown with a clear name and single responsibility each. 3. Show the new file structure and which functions move where. 4. Provide the diffs to extract each module, updating imports and call sites. 5. Sequence the extraction so the code compiles and tests pass after every step. </task>

<context> These chunks are nearly duplicated and I want to DRY them up carefully: [PASTE THE DUPLICATED CODE]. Stack: [LANGUAGE]/[FRAMEWORK]. </context> <task> 1. Show exactly what is shared versus what genuinely differs across the copies. 2. Decide whether abstraction is actually warranted, or whether the duplication is incidental and should stay (avoid premature abstraction). 3. If warranted, propose the abstraction (function, parameter, strategy) as a diff. 4. Make sure the abstraction does not couple unrelated concerns or add hidden flags. 5. Show the call sites updated to use it. </task>

<context> This [LANGUAGE]/[FRAMEWORK] code uses an outdated pattern: [PASTE CODE]. Target: [MODERN PATTERN / LANGUAGE VERSION], e.g. callbacks to async/await, class components to hooks, etc. </context> <task> 1. Explain the risks of the current pattern and what the modern equivalent buys me. 2. Convert the code to the target pattern as a diff, preserving behavior and error handling. 3. Highlight any behavioral subtleties the conversion can introduce (error propagation, ordering, this-binding). 4. List the minimum test coverage needed before I trust the migration. 5. Recommend whether to do this incrementally or all at once for this case. </task>

<context> This code works but is hard to read: [PASTE CODE]. Stack: [LANGUAGE]/[FRAMEWORK]. Team naming conventions: [DESCRIBE OR SAY DEFAULT]. </context> <task> 1. Suggest clearer names for variables, functions, and types, with a short rationale each. 2. Flag misleading or stale names that imply behavior the code no longer has. 3. Propose structural readability tweaks (early returns, guard clauses, splitting expressions) as a diff. 4. Keep the public surface and behavior identical. 5. Show the before/after of the worst offending section side by side. </task>

<context> Write tests for this function: [PASTE FUNCTION]. Stack: [LANGUAGE]/[FRAMEWORK]. Test framework: [E.G. JEST / PYTEST / JUNIT]. Existing test file for style reference: [PASTE OR SAY NONE]. </context> <task> 1. List the behaviors and branches that need coverage before writing anything. 2. Write tests covering happy path, edge cases, boundary values, and error inputs. 3. Match the framework and the style of my existing tests (naming, setup, assertions). 4. Avoid testing implementation details that would make the tests brittle. 5. Note any input I should fuzz or any case the function does not currently handle. </task>

<context> Here is a function and the tests I already have: [PASTE FUNCTION + EXISTING TESTS]. Stack: [LANGUAGE]/[FRAMEWORK]. </context> <task> 1. Analyze what the current tests cover and, more importantly, what they do not. 2. Enumerate edge cases I am missing: empty/null inputs, boundaries, unicode, large inputs, concurrency, locale, time zones, as applicable. 3. Rank the missing cases by likelihood of a real-world bug. 4. Write the highest-value missing tests in my framework. 5. Flag any case where the function would actually fail today. </task>

<context> I need an integration test for this flow: [DESCRIBE FLOW, E.G. SIGNUP THEN CHARGE]. Stack: [LANGUAGE]/[FRAMEWORK]. Test framework and any test DB/fixtures setup: [DESCRIBE]. Code under test: [PASTE]. </context> <task> 1. Outline the end-to-end path the test must exercise and the external boundaries to control. 2. Decide what to use real versus what to stub/mock (DB, network, clock) and justify it. 3. Write the test including setup, the exercise, assertions on observable outcomes, and teardown. 4. Make it deterministic — no reliance on real time, randomness, or live external services. 5. Note how to run it in isolation and what could make it flaky. </task>

<context> Bug: [DESCRIBE]. It produces [ERROR / WRONG OUTPUT] when [INPUT/CONDITION]. Stack: [LANGUAGE]/[FRAMEWORK]. Code involved: [PASTE]. </context> <task> 1. Write a failing test that reproduces the bug exactly, asserting the correct expected behavior. 2. Confirm the test fails for the right reason against the current code. 3. Only then propose the minimal fix as a diff. 4. Explain why the test will pass after the fix and not give a false positive. 5. Suggest one or two related cases worth locking in while we are here. </task>

<context> I need realistic test data/fixtures for: [DESCRIBE ENTITIES AND RELATIONSHIPS]. Stack: [LANGUAGE]/[FRAMEWORK]. Test framework and factory tooling: [DESCRIBE OR SAY NONE]. </context> <task> 1. Design factories or fixtures that produce valid, minimal-but-realistic data for each entity. 2. Handle relationships and required fields so created objects are actually persistable. 3. Make values varied enough to catch real bugs but deterministic where tests assert on them. 4. Provide reusable builders with sensible defaults and per-test overrides. 5. Note any data that must be unique or cleaned up between tests. </task>

<context> I need to integrate [API/SERVICE NAME] into my [LANGUAGE]/[FRAMEWORK] app to [GOAL]. I will paste the relevant docs/endpoints. Auth method: [API KEY / OAUTH / ETC]. </context> <task> 1. Based only on the docs I paste (do not invent endpoints), outline the request flow for my goal. 2. Write a typed client/wrapper that handles auth, retries on transient errors, and timeouts. 3. Map the API's response into my own domain model rather than leaking its shape everywhere. 4. Handle and surface errors (rate limits, 4xx, 5xx) in a way my app can act on. 5. List the env vars/secrets needed and how to keep them out of source control. If the docs are missing something you need, ask rather than guess. </task>

<context> I am adding an endpoint to my [LANGUAGE]/[FRAMEWORK] API for: [DESCRIBE RESOURCE/ACTION]. Existing API conventions: [PASTE A SAMPLE ENDPOINT]. Consumers: [WHO CALLS IT]. </context> <task> 1. Propose the route, method, request and response shapes following my existing conventions. 2. Define validation rules and the exact error responses for each failure mode. 3. Specify status codes, pagination/filtering if relevant, and idempotency where it matters. 4. Write the handler implementation as a diff matching my patterns. 5. Note auth/authorization requirements and any rate-limiting concern. </task>

<context> I need to receive webhooks from [SERVICE] in my [LANGUAGE]/[FRAMEWORK] app. Events I care about: [LIST]. Signing/secret mechanism per their docs: [PASTE]. </context> <task> 1. Implement signature verification exactly as the provider specifies, rejecting unverified calls. 2. Make the handler idempotent so retried/duplicate deliveries are safe. 3. Acknowledge fast and do heavy work async; outline how given my stack. 4. Handle out-of-order and unknown event types gracefully. 5. Provide the handler diff plus a way to test it locally with a sample payload. </task>

<context> My integration with [API/SERVICE] is failing. Request I send: [PASTE METHOD, URL, HEADERS, BODY]. Response I get: [PASTE STATUS + BODY]. Stack: [LANGUAGE]/[FRAMEWORK]. What I expected: [DESCRIBE]. </context> <task> 1. Interpret the response status and body and explain what the API is telling me. 2. Compare my request against the API's requirements and pinpoint the discrepancy (auth, headers, encoding, payload shape, scopes). 3. Rank the likely causes and tell me the fastest way to confirm each. 4. Provide the corrected request and the matching code change. 5. Suggest logging so future integration failures are diagnosable. </task>

<context> This code calls an external service and is fragile under failure: [PASTE CODE]. Stack: [LANGUAGE]/[FRAMEWORK]. Acceptable latency and failure behavior: [DESCRIBE]. </context> <task> 1. Identify failure modes the current code ignores (timeout, retry storms, partial failure, slow upstream). 2. Add timeouts, bounded retries with backoff, and a circuit-breaker or fallback as appropriate. 3. Ensure retries are only applied to safe, idempotent operations. 4. Make failures observable (metrics/logs) without leaking sensitive data. 5. Deliver the changes as a diff and explain the trade-offs of each safeguard. </task>

<context> I just joined a [LANGUAGE]/[FRAMEWORK] project and need to get productive fast. I will paste the README, the file tree, and a few key files: [PASTE]. </context> <task> 1. Summarize what this app does and its high-level architecture from what I pasted. 2. Map the main modules and how a typical request/data flow moves through them. 3. Point me to the 5 files I should read first to understand the core. 4. Flag conventions, gotchas, and any non-obvious patterns I should respect. 5. Suggest a small, low-risk first task that would teach me the codebase. </task>

<context> I know [LANGUAGE/FRAMEWORK I KNOW] and need to become productive in [NEW LANGUAGE/FRAMEWORK] for [GOAL]. I learn best from concrete examples and comparisons. </context> <task> 1. Map the core concepts of the new tech onto the ones I already know, highlighting where the analogy breaks down. 2. Show idiomatic examples for the 5 tasks I will hit most often for my goal. 3. Call out the most common beginner mistakes coming from my background. 4. Recommend the canonical tooling and project structure for this ecosystem. 5. Give me a tiny project to build that exercises the essentials. </task>

<context> I need to pick a [TYPE OF LIBRARY/TOOL] for my [LANGUAGE]/[FRAMEWORK] project to [GOAL]. Constraints: [LICENSE / BUNDLE SIZE / TEAM SKILL / MAINTENANCE]. Candidates I am considering: [LIST OR ASK]. </context> <task> 1. Compare the candidates on the criteria that matter for my constraints, in a table. 2. Be explicit about trade-offs and where each option is the wrong choice. 3. Flag maintenance health signals to check (last release, open issues, community) rather than asserting them as fact. 4. Recommend one with a clear rationale tied to my constraints. 5. Note the migration cost if I picked it and later wanted to switch. </task>

<context> I keep using [CONCEPT, E.G. EVENTUAL CONSISTENCY / CLOSURES / OAUTH] without truly understanding it. My background: [LANGUAGE]/[FRAMEWORK] developer. </context> <task> 1. Explain the concept from first principles in terms a working developer cares about. 2. Use a concrete example in my stack, not abstract pseudocode. 3. Show where it actually shows up in real code and what breaks without it. 4. Address the misconceptions developers most often hold about it. 5. Give me 3 questions to test whether I really understand it, with answers. </task>

<context> My team is considering adopting [TECHNOLOGY] for [USE CASE]. Current stack: [LANGUAGE]/[FRAMEWORK]. Team size and experience: [DESCRIBE]. </context> <task> 1. Summarize what problem this technology solves and when it is genuinely worth the complexity. 2. List the concrete benefits and the often-underestimated costs (ops, hiring, lock-in, learning curve). 3. Describe what a minimal pilot would look like and what success/failure criteria to set. 4. Identify what could go wrong for a team of my size and how to mitigate it. 5. Give a balanced recommendation, including the case for NOT adopting it. </task>