ChatGPT Prompts for Software Engineers

<context> You are a senior [LANGUAGE] engineer working in [CODEBASE]. We follow the existing conventions, error-handling patterns, and folder structure already present in the repo. I will give you a feature spec for [FEATURE]. </context> <task> 1. Restate the feature in one sentence and list any assumptions you are making. 2. Propose the file(s) to create or modify and a one-line reason for each. 3. Write production-ready [LANGUAGE] code implementing [FEATURE], with input validation, error handling, and inline comments only where logic is non-obvious. 4. List edge cases you handled and any you deliberately deferred. 5. End with a short checklist of what I should verify before merging. </task>

<context> You are building a typed client in [LANGUAGE] for an HTTP API used by [CODEBASE]. I will paste the endpoint list or an OpenAPI snippet for [FEATURE]. </context> <task> 1. Define request and response types/models for each endpoint. 2. Implement a small client class/module with one method per endpoint. 3. Centralize base URL, auth headers, timeouts, and retry-on-5xx logic. 4. Surface errors as typed results rather than throwing raw network errors. 5. Show one usage example per method and note any pagination or rate-limit handling. </task>

<context> You are scaffolding a new module in [CODEBASE] using [LANGUAGE]. The module implements [FEATURE] and must match the existing project layout and dependency-injection style. </context> <task> 1. Outline the module boundary: public interface vs internal helpers. 2. Generate the file structure with stubbed functions and clear TODOs. 3. Wire the module into the app entry point or DI container. 4. Add the minimal config or env keys the module needs, with safe defaults. 5. Provide a one-paragraph README block describing how to use the module. </task>

<context> You are a [LANGUAGE] engineer in [CODEBASE]. I will paste pseudocode or a rough algorithm for [FEATURE] and need it turned into idiomatic, tested code. </context> <task> 1. Translate the pseudocode into idiomatic [LANGUAGE], preserving intent. 2. Replace any hand-waved steps with concrete, correct logic and call out where you did so. 3. Add guard clauses for invalid input and explain the time/space complexity. 4. Suggest a more efficient approach if one exists, with the tradeoff. 5. Include a tiny runnable example demonstrating expected output. </task>

<context> You are extending the command-line tool in [CODEBASE], written in [LANGUAGE]. I want a new command that implements [FEATURE]. </context> <task> 1. Define the command name, arguments, and flags with defaults and help text. 2. Implement argument parsing and validation following the existing CLI framework. 3. Implement the command logic, separating I/O from pure business logic. 4. Handle non-zero exit codes and write errors to stderr. 5. Show example invocations and their expected output. </task>

<context> You are debugging [CODEBASE], written in [LANGUAGE]. I will paste a stack trace and the relevant code for [FEATURE]. The error happens at runtime in production. </context> <task> 1. Read the stack trace top-down and identify the most likely root cause. 2. Explain the failure in plain language and what conditions trigger it. 3. Propose the smallest correct fix, with the exact code change. 4. List two other plausible causes and how to rule each one out. 5. Suggest a guard or assertion that would have surfaced this earlier. </task>

<context> You are reviewing [LANGUAGE] code from [CODEBASE] that produces wrong output for [FEATURE] but does not crash. I will paste the function and a failing input/expected-output pair. </context> <task> 1. Trace the code line by line for the failing input and show intermediate values. 2. Pinpoint the exact line where actual diverges from expected. 3. Explain why the bug occurs, not just where. 4. Provide the corrected code and re-trace it for the same input. 5. Add one more test input that would catch a regression of this bug. </task>

<context> You are investigating a flaky test in [CODEBASE] ([LANGUAGE]) that covers [FEATURE]. It passes locally but fails intermittently in CI. </context> <task> 1. List the usual sources of flakiness (timing, shared state, ordering, randomness, network) and rank which are most likely here. 2. Read the pasted test and implementation and point to specific lines that introduce nondeterminism. 3. Propose a deterministic rewrite of the risky parts. 4. Suggest how to reproduce the flake locally (seeds, parallelism, ordering). 5. Recommend a CI change to catch this class of flake going forward. </task>

<context> You are helping me understand why [FEATURE] in [CODEBASE] behaves differently than I expect. The language is [LANGUAGE]. I will describe expected vs actual behavior and paste the code. </context> <task> 1. Restate my expected behavior and the observed behavior in your own words. 2. Identify the language feature, library quirk, or async/ordering issue causing the gap. 3. Demonstrate the cause with a minimal reproducible snippet. 4. Give the corrected version and explain the mental model I was missing. 5. Point to the relevant docs or spec section for further reading. </task>

<context> You are investigating a performance regression in [FEATURE] within [CODEBASE], written in [LANGUAGE]. I will paste the hot code path and any profiler output I have. </context> <task> 1. Identify the most expensive operations in the pasted path (allocations, N+1 queries, repeated work, blocking I/O). 2. Rank suspected bottlenecks by likely impact. 3. Propose targeted optimizations with the rewritten code for the top one. 4. Estimate the complexity/cost change and any correctness risk of each fix. 5. Suggest a benchmark or metric to confirm the improvement. </task>

<context> You are a staff engineer reviewing a pull request in [CODEBASE], written in [LANGUAGE]. The PR implements [FEATURE]. I will paste the diff. Be direct but constructive. </context> <task> 1. Summarize what the diff does in two sentences. 2. Flag correctness bugs, race conditions, and unhandled errors first, citing exact lines. 3. Note security and input-validation concerns. 4. Call out readability, naming, and duplication issues, ranked by severity. 5. End with a clear verdict: approve, approve-with-nits, or request-changes, and the top three must-fix items. </task>

<context> You are performing a security-focused review of [LANGUAGE] code from [CODEBASE] that handles [FEATURE]. Assume input is untrusted. </context> <task> 1. Check for injection (SQL, command, template), XSS, SSRF, and path traversal in the pasted code. 2. Review auth, authorization, and secrets handling for gaps. 3. Flag unsafe deserialization, insecure defaults, and missing rate limits. 4. For each finding, give severity, the vulnerable line, and a concrete fix. 5. List anything you could NOT verify from the code alone and what to check next. </task>

<context> You are reviewing [LANGUAGE] code in [CODEBASE] that works but is hard to maintain. It implements [FEATURE]. I want refactoring suggestions, not a rewrite. </context> <task> 1. Identify the biggest maintainability smells (long functions, deep nesting, primitive obsession, duplication). 2. For the top three, show the before snippet and a refactored after snippet. 3. Keep behavior identical — note any behavior you might be changing. 4. Explain the principle each refactor applies and why it helps. 5. Order the refactors by payoff-to-risk ratio. </task>

<context> You are reviewing [LANGUAGE] code from [CODEBASE] against our team conventions for [FEATURE]. I will paste our style rules followed by the code. </context> <task> 1. List each violation of the pasted conventions with the offending line. 2. Provide the corrected line or block for each violation. 3. Distinguish hard rule violations from stylistic preferences. 4. Suggest a lint rule or formatter config that would auto-enforce each fixable item. 5. Summarize how many issues are auto-fixable vs need human judgment. </task>

<context> You are reviewing whether a change to [FEATURE] in [CODEBASE] ([LANGUAGE]) is adequately tested. I will paste the changed code and its existing tests. </context> <task> 1. List the behaviors and branches in the changed code. 2. Map each existing test to the behavior it covers. 3. Identify untested branches, edge cases, and error paths. 4. Write the missing test cases as code, named for the behavior they verify. 5. Give a one-line coverage verdict: sufficient or insufficient to merge. </task>