ChatGPT Prompts for Developers

<context> I work in a [LANGUAGE]/[FRAMEWORK] codebase. I need to build this feature: [FEATURE DESCRIPTION]. Existing relevant files and conventions: [PASTE FILE NAMES, KEY FUNCTIONS, OR SNIPPETS]. </context> <task> 1. Restate the feature in one sentence and list any assumptions you are making. 2. Propose an implementation plan as an ordered checklist of small commits, each independently shippable. 3. For each step, name the exact files to add or modify and why. 4. Flag edge cases, error states, and backward-compatibility risks I should handle. 5. Call out where my existing conventions should be reused versus where new patterns are justified. Ask me up to 3 clarifying questions before writing any code. </task>

<context> Ticket: [PASTE TICKET / ACCEPTANCE CRITERIA]. Stack: [LANGUAGE]/[FRAMEWORK]. Here is the code I am extending: [PASTE RELEVANT FILE(S)]. </context> <task> 1. Implement the feature as a complete, runnable diff that fits the pasted code's style. 2. Use the same imports, error-handling, and logging patterns already present. 3. Add inline comments only where the intent is non-obvious. 4. List every assumption you made that the ticket left ambiguous. 5. End with a short manual test plan a reviewer can run to confirm it works. Do not invent libraries that are not already in the file or that I have not confirmed are installed. </task>

<context> I am adding [FEATURE] to a [LANGUAGE]/[FRAMEWORK] app backed by [DATABASE]. Current relevant schema: [PASTE TABLES / MODELS]. Expected access patterns: [DESCRIBE READS AND WRITES]. </context> <task> 1. Propose the new or changed tables/models with field types, nullability, and indexes. 2. Justify each index against the access patterns I described. 3. Provide a forward migration and a reversible down migration. 4. Note any data backfill needed and how to run it safely on a populated table. 5. Flag normalization vs denormalization trade-offs for this specific case. </task>

<context> A stakeholder asked for: [PASTE THE VAGUE REQUEST]. My stack: [LANGUAGE]/[FRAMEWORK]. Time budget: [HOURS/DAYS]. </context> <task> 1. Translate the request into concrete, testable requirements. 2. Split into an MVP that fits the time budget and a follow-up backlog. 3. For the MVP, list the smallest set of changes that delivers visible value. 4. Identify the riskiest unknown and a 30-minute spike to de-risk it first. 5. Phrase 3 questions I should send back to the stakeholder to lock scope. </task>

<context> I want to ship [FEATURE] behind a flag in my [LANGUAGE]/[FRAMEWORK] app. Current flagging mechanism (if any): [DESCRIBE OR SAY NONE]. Affected code: [PASTE SNIPPET]. </context> <task> 1. Show how to gate the new code path behind a flag using my existing mechanism, or recommend a minimal one if I have none. 2. Ensure the off state is the exact current behavior (no regressions when disabled). 3. Provide the diff for both the flagged code and its call sites. 4. Describe a staged rollout: internal, percentage, full, plus rollback. 5. List what to clean up once the flag is permanently on. </task>

<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>