For a small review, paste permitted code and a diff into the chat. OpenAI's code-review documentation describes choosing a clear review scope and investigating findings.
Include the contract, not just the changed line
This original JavaScript helper must return unique labels in their original first-seen order, without modifying the input array. A proposed revision sorts before removing duplicates:
function uniqueLabels(labels) {
return [...new Set(labels.sort())];
}
The code might look tidy in isolation. The contract reveals two problems: sorting changes the intended order, and sort() changes the caller's array.
For ['zebra', 'apple', 'zebra'], the expected return is ['zebra', 'apple']; the input should still contain its original three entries in that order. The proposed helper returns ['apple', 'zebra'] and leaves the input as ['apple', 'zebra', 'zebra'].
Those are two observable consequences of one introduced operation. A useful review can report them together and identify the affected callers. It should not inflate them into claims that every part of the application is broken.
Ask for evidence before a rewrite
Review this change for correctness defects.
Base and proposed code or diff: [PASTE]
Relevant callers and surrounding code: [PASTE]
Required behavior and supported runtime: [PASTE]
Existing relevant tests: [PASTE OR NONE]
For each finding, give the changed location, a concrete input or
starting state, the required result, and the result the proposed
code would produce. Explain the path from the changed line to the
failure. Separate a reproduced result from a prediction that still
needs execution. Ask for missing context rather than inventing it.
Prioritize defects introduced by this change. Keep optional style
ideas separate. Do not edit files, approve, merge, or post comments.
The prompt can help focus a review, but a detailed explanation can still be wrong. Run the proposed reproduction in the actual supported environment. If the necessary caller or configuration is missing, obtain it before treating the finding as established.
Turn the finding into a focused fix and regression check
For this sample's stated contract, removing the sort addresses both effects:
function uniqueLabels(labels) {
return [...new Set(labels)];
}
In JavaScript, a Set preserves insertion order. The MDN Set reference documents that behavior. This is a label-string example; a different equality requirement would need its own contract.
The regression check should assert both the returned order and the unchanged input. An assertion that only checks the result contains two labels would miss both the ordering requirement and mutation of the caller's array.
After the fix, rerun the reproduction and the relevant existing tests. Record which revision was tested. A review of an earlier diff does not establish that later edits are correct.
Leave a comment another developer can act on
A specific sample comment is: “Sorting here changes first-seen order and mutates the caller's array. With ['zebra','apple','zebra'], the helper returns ['apple','zebra'] and reorders the input. The contract requires ['zebra','apple'] with the input unchanged. Remove sorting and assert both requirements.”
That comment names the trigger, consequence, and required behavior. It gives the author enough information to decide on a fix without asking them to decipher “improve edge-case handling.”
If the problem is missing test coverage rather than an identified defect, the ChatGPT unit-test workflow starts from the function contract. Finish this review by verifying the actual changed revision and resolving the concrete findings in the team's normal review process.