ChatGPT prompt for a coding assistant

Act as a careful senior engineer helping me implement [TASK OR BUG] in [PROJECT CONTEXT AND STACK]. The relevant existing code, interfaces, or error output is [RELEVANT CODE OR LOGS]. The required behavior and constraints are [ACCEPTANCE CRITERIA]. I can run these commands or tests: [AVAILABLE TEST OR BUILD COMMANDS].

Do not invent APIs, files, package behavior, database columns, environment variables, or test results. If a missing dependency, interface contract, security requirement, or product decision prevents a safe implementation, ask up to 3 focused questions before proposing a patch. Otherwise, reason from the code I supplied.

First, state a concise implementation plan that identifies affected files, data flow, invariants, and the smallest safe change. Then provide:
1. The code changes as complete file patches or clearly delimited replacements, preserving the project’s apparent conventions.

2. A short explanation of how the change satisfies each acceptance criterion.
3. Tests: include unit, integration, or manual test cases appropriate to the change, with inputs and expected outputs.
4. Edge cases and failure handling, including invalid input, empty or missing values, retries or concurrency where relevant, authorization boundaries, and backward compatibility.
5. A rollback or migration note if state, schema, public behavior, or stored data changes.

Prefer simple, maintainable code over unnecessary abstraction. Validate external input at the boundary, avoid exposing secrets in logs or errors, and preserve error context useful to operators. If you offer alternatives, recommend one and state its trade-off in one sentence.

Before answering, self-check that every referenced identifier exists in the supplied context or is explicitly marked as an assumption, and that the tests would fail before the fix and pass after it. Flag any acceptance criterion that the proposed code does not fully meet.

Investigate this software failure: [OBSERVED BEHAVIOR]. The expected behavior is [EXPECTED BEHAVIOR]. Here are the reproduction steps, logs, and relevant code: [EVIDENCE]. The system context is [STACK AND DEPLOYMENT CONTEXT]. Produce a ranked list of plausible root causes, the evidence for and against each, and the smallest diagnostic checks to distinguish them. Do not claim a root cause without evidence or propose broad rewrites. End with a recommended next experiment and its expected outcomes. Check that every hypothesis explains the reported symptoms.

Review this proposed change for [FEATURE OR RISK AREA]: [DIFF OR CODE]. The existing behavior and constraints are [CONTEXT]. Return findings ordered by severity: correctness, security, data integrity, performance, compatibility, and test gaps. For each finding, cite the relevant code path, explain the concrete failure scenario, and propose a minimal correction. Do not invent repository conventions or report stylistic preferences as defects. If there are no material findings, say so and name the residual risks. Check that each finding is actionable and supported by the supplied code.

Plan a behavior-preserving refactor of [COMPONENT OR MODULE]. Current code and tests are [CODE AND TESTS]; the maintenance problem is [PROBLEM]. Produce a staged plan with seams to extract, invariants to preserve, tests to add before refactoring, and a small first patch. Identify public APIs, data formats, and side effects that must not change. Do not rewrite working code merely for style. Include rollback signals and a verification command for each stage. Check that every stage can be merged independently without changing intended behavior.