ChatGPT Prompts for Software Engineers

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

<context> You are writing unit tests in [LANGUAGE] for [FEATURE] in [CODEBASE]. We use the repo's existing test framework and naming style. I will paste the function under test. </context> <task> 1. Enumerate the function's inputs, outputs, and side effects. 2. Derive test cases: happy path, boundary values, invalid input, and error conditions. 3. Write the tests using the existing framework, with descriptive names and arrange-act-assert structure. 4. Mock or stub external dependencies cleanly. 5. Note any behavior that is ambiguous and should be clarified before locking it in tests. </task>

<context> You are hardening tests for [FEATURE] in [CODEBASE] ([LANGUAGE]). The happy path already passes. I want a thorough list of edge cases. I will paste the function or spec. </context> <task> 1. Brainstorm edge cases across categories: empty, null, boundary, very large, malformed, concurrent, and locale/encoding inputs. 2. For each, state the input and the expected behavior. 3. Flag cases where the correct behavior is undefined and needs a product decision. 4. Turn the well-defined cases into test code. 5. Prioritize which edge cases are most likely to occur in production. </task>

<context> You are writing integration tests for [FEATURE] in [CODEBASE], using [LANGUAGE]. The feature spans multiple components (e.g. handler, service, database). I will describe the flow. </context> <task> 1. Identify the components involved and the boundaries worth testing together. 2. Define the test scenarios end-to-end, including setup and teardown. 3. Write the integration tests with realistic fixtures and a clean database/state per run. 4. Assert on observable outcomes, not internal implementation details. 5. Note which external services should be faked vs hit for real and why. </task>

<context> You are adding property-based tests for [FEATURE] in [CODEBASE] ([LANGUAGE]). I want to test invariants rather than fixed examples. I will paste the function. </context> <task> 1. Identify invariants the function must always satisfy (round-trips, idempotence, ordering, bounds). 2. Define generators for valid and adversarial inputs. 3. Write property-based tests using a suitable library for [LANGUAGE]. 4. Add shrinking-friendly assertions so failures minimize cleanly. 5. Explain what each property protects against and a known false-friend to avoid asserting. </task>

<context> You are converting a reported bug in [FEATURE] ([CODEBASE], [LANGUAGE]) into a minimal failing test before I fix it. I will paste the bug report and relevant code. </context> <task> 1. Restate the bug as a precise expected-vs-actual statement. 2. Identify the smallest input that reproduces it. 3. Write a single failing test that asserts the correct (desired) behavior. 4. Confirm the test fails for the current code and would pass once fixed. 5. Suggest where the fix likely belongs, without writing the fix. </task>

<context> You are documenting [FEATURE] in [CODEBASE], written in [LANGUAGE]. Match the repo's existing docstring style. I will paste the code. </context> <task> 1. Write a one-line summary of what the code does. 2. Document each parameter, return value, and thrown error/exception. 3. Note side effects, preconditions, and thread-safety where relevant. 4. Add a short, copy-pasteable usage example. 5. Keep it accurate to the code — do not document behavior the code does not have. </task>

<context> You are writing the README for [CODEBASE], a [LANGUAGE] project that does [FEATURE]. The audience is a developer seeing it for the first time. I will paste package metadata and key entry points. </context> <task> 1. Open with a one-paragraph description of what it does and who it is for. 2. Add Installation, Quick Start, and Configuration sections with runnable commands. 3. Document the main commands or API surface with examples. 4. Include Contributing and License placeholders matching the repo. 5. Keep claims grounded in the provided code — mark anything you inferred as TODO. </task>

<context> You are generating reference documentation for the public API of [FEATURE] in [CODEBASE] ([LANGUAGE]). I will paste the endpoint or function signatures. </context> <task> 1. For each endpoint/method, document the signature, parameters, and return shape. 2. Provide a request and response example for each. 3. List error codes/exceptions and when they occur. 4. Note authentication, rate limits, and idempotency where applicable. 5. Organize entries consistently and flag any signature you could not fully interpret. </task>

<context> You are writing an Architecture Decision Record (ADR) for a choice we made about [FEATURE] in [CODEBASE] ([LANGUAGE]). I will describe the context, the options we considered, and what we picked. </context> <task> 1. Title the ADR and set status (proposed/accepted) and date. 2. Write the Context section: the problem and constraints driving the decision. 3. Write the Decision section in one clear statement. 4. Document the Alternatives considered with their tradeoffs. 5. Write Consequences: what gets easier, what gets harder, and follow-ups. </task>

<context> You are onboarding onto unfamiliar [LANGUAGE] code in [CODEBASE] that implements [FEATURE]. I will paste a chunk of legacy code with little documentation. </context> <task> 1. Give a high-level summary of what the code accomplishes. 2. Walk through the control flow and key data structures step by step. 3. Call out non-obvious behavior, hidden side effects, and likely intent of cryptic parts. 4. Flag risky or suspicious sections that may hide bugs. 5. Produce a concise comment block I can paste above the code to help the next reader. </task>

<context> You are a principal engineer designing a new component for [FEATURE] that will live in [CODEBASE], implemented in [LANGUAGE]. I will describe the requirements and current architecture. </context> <task> 1. Restate functional and non-functional requirements (latency, scale, consistency). 2. Propose two viable designs with a short pros/cons list each. 3. Recommend one and justify it against the requirements. 4. Define the component's interface, data model, and key failure modes. 5. List risks, open questions, and a phased rollout plan. </task>

<context> You are advising on a technical choice for [FEATURE] in [CODEBASE] ([LANGUAGE]). I will list the options under consideration and our constraints. </context> <task> 1. Summarize each option in one sentence. 2. Build a comparison across the dimensions that matter (performance, complexity, cost, team familiarity, lock-in). 3. Identify the decisive factors given our constraints. 4. Make a clear recommendation and name the conditions under which you would change it. 5. List what to prototype to de-risk the choice cheaply. </task>

<context> You are designing a database schema for [FEATURE] in [CODEBASE]. The app is written in [LANGUAGE]. I will describe the entities and access patterns. </context> <task> 1. List the entities, their attributes, and relationships. 2. Propose normalized tables with keys, types, and constraints. 3. Recommend indexes based on the stated query patterns. 4. Call out where denormalization or caching may be justified and the tradeoff. 5. Provide the DDL and note any migration concerns for existing data. </task>

<context> You are planning a large refactor/migration of [FEATURE] in [CODEBASE] ([LANGUAGE]) that must ship without downtime. I will describe the current state and target state. </context> <task> 1. Define the end state and the smallest safe increments to reach it. 2. Sequence the steps so the system stays releasable after each one. 3. Identify backward-compatibility shims and feature flags needed. 4. Call out data migration, rollback, and verification steps per phase. 5. Flag the riskiest step and how to de-risk it. </task>

<context> You are reviewing an architecture for [FEATURE] in [CODEBASE] ([LANGUAGE]) for scalability and reliability. I will paste or describe the proposed design and expected load. </context> <task> 1. Identify the components most likely to become bottlenecks under the stated load. 2. Check for single points of failure and missing backpressure or rate limiting. 3. Evaluate data consistency, caching, and statefulness concerns. 4. Recommend concrete changes ranked by impact. 5. Suggest metrics and load tests to validate the design before launch. </task>