Name the part that needs changing and the parts that should stay. Give the correct facts or a clear example of the result you want. Ask for a focused revision, then compare it with the previous version to check that the fix did not create a new problem.
What you need before you start
An answer has useful parts but needs a specific correction or clearer writing.
Bring: The current version, the exact problem, the parts to keep, and any correct facts needed for the repair.
Start with these steps
- Identify the smallest change that would make the answer useful.
- Name what to keep, what to change, and what to add.
- Supply the correct facts or a short example of the result you want.
- Ask for a focused revision.
- Compare the old and new versions for missing facts and unwanted changes.
A prompt you can adapt
Revise this answer for [task]. Keep these parts exactly or in substance [good parts]. Fix only this problem [failure]. The result passes if [test]. If the request cannot be met from the source, say what is missing instead of inventing it.
Replace every bracket with real information. Remove fields that do not affect your task.
What this looks like in practice
Teaching example: an email has the right facts and a useful request, but its opening sounds cold. Ask ChatGPT to rewrite the opening only and keep the request, dates, and closing exactly as supplied.
Find the failure before asking for another version
Read the answer once for its main purpose. Does it answer your question? Does it use the correct source? Does it have the format you need? Then identify the smallest change that would make it useful. An answer may need a corrected number, a missing explanation, a warmer opening, or a different order. Those are different jobs. Asking for a better answer without naming the job often changes everything at once.
Describe the problem in words someone could check. “The second paragraph uses a delivery date that is not in my notes” is clear. “This is not good enough” is understandable as frustration, but it does not show the model how to repair the answer. Copy the bad sentence and explain what is wrong with it.
If the whole answer follows the wrong task, a fresh brief may be better than a small edit. For example, a sales pitch cannot become a neutral comparison through a warmer tone. Explain the real purpose and rebuild around it. Save any facts, tables, or useful passages first so the new request does not lose them.
Tell ChatGPT what to keep, change, and add
A useful revision request has three parts. Keep names the material already correct. Change names the error or weak passage. Add names anything missing. You do not need all three every time, but separating them reduces guesswork. For a report, keep the confirmed findings, change the unsupported claim, and add the missing limit of the data.
Be careful with the word exactly. Use it when wording must remain identical, such as an approved quote or a required sentence. If meaning matters more than wording, say that instead. Asking to keep every word while also making a paragraph much shorter gives conflicting instructions. Decide which goal comes first.
Place the latest brief in one message if the conversation has several revisions. Older requests may ask for a formal tone while newer ones ask for simple language. Tell ChatGPT which instruction now applies. Include the current version rather than expecting the model to choose the right draft from a long conversation.
Revise only the opening paragraph.
KEEP: the request, amount, date, attachment list, and closing exactly as written.
CHANGE: the opening sounds blaming. Make it calm and direct.
ADD: nothing. Do not add apologies, promises, or new facts.
Return the revised opening first, then the full message.A worked example: change the tone without changing the promise
This teaching example uses invented order details. The original email says, “Your team has once again failed to handle this properly. Order R-42 arrived with a cracked base on 8 October. Please explain how to request a replacement. I have attached two photos.” The facts and request are useful, but the first sentence blames the team without adding evidence.
A focused repair could be: “I am writing about a problem with order R-42. It arrived with a cracked base on 8 October. Please explain how to request a replacement. I have attached two photos.” The tone changed, while the order, damage, date, request, and attachments stayed. This is a better repair than replacing the whole email with a generic complaint.
Now compare it with a bad revision: “Please send my replacement by Friday, as previously agreed.” That adds a deadline and an agreement absent from the source. Even if the new email reads well, reject those additions. Point to the unsupported sentence and ask for its removal. A revision succeeds when it fixes the named problem and keeps the facts within the supplied evidence.
Change depth, length, or reading level without losing information
When simplifying a difficult answer, ask for easier words and shorter sentences while preserving the facts and conditions. A shorter version and a simpler version are not always the same. A clear explanation may need more space because it defines a term and gives an example. Say that understanding matters more than hitting a small word limit.
Ask the model to list the points that must survive before rewriting. If a notice includes a deadline, an exception, and an action the reader must take, those all belong in the simplified version. Compare the final text with that list. A pleasant paragraph that drops an exception is less useful than the original.
For an answer that is too shallow, name the missing question. Ask why the step matters, what can go wrong, or how the method changes in a different case. “Add more detail” can produce extra phrases without extra information. A specific missing question gives the next passage a job. After expanding, check that the opening still answers the main question early.
Repair tables and lists with a clear rule for each item
Structured output needs a rule that applies to every row. If you requested one row per customer but received one row per order, explain the difference and show two sample rows. State the unique identifier and how repeated entries should be handled. Otherwise the model may change the headings while keeping the same wrong grouping.
Protect fields that must not change. Ask it to preserve IDs, original amounts, and source order unless you explicitly request a transformation. If a field is missing, use a blank or a named unknown rather than a guess. For a large table, a script or spreadsheet is usually a better way to apply the same mechanical change consistently. ChatGPT can help define the rule and explain exceptions.
Check row counts, duplicate IDs, and totals after the revision. A neat table may have lost the last few records. If you ask for a shorter list, specify whether items may be removed or just described more briefly. Keep the original data available so you can see exactly what changed.
| Problem | Focused instruction | Check |
|---|---|---|
| Wrong grouping | One row per customer ID | Count distinct IDs |
| Missing amount | Keep amount blank if absent | Compare with source |
| Extra column | Remove this named column only | Check other columns |
| Changed wording | Preserve the approved phrase exactly | Compare the text |
Correct facts with evidence, not a request for confidence
If you know a fact is wrong, provide the correct value and its source. Ask the model to replace the claim and update any conclusion that depends on it. A report may calculate a percentage from the wrong denominator. Fixing the percentage alone is not enough if the summary still describes the old result.
If you only suspect an error, separate checking from rewriting. Find the source, open it, and confirm what it says. Asking ChatGPT “Are you sure?” may produce a confident defense or an unnecessary reversal. Neither response settles the fact. A source passage, calculation, or real test gives the revision something solid to use.
Mark unresolved facts clearly in your working draft. You may be able to use the supported parts while waiting for one missing value. Do not fill the gap just to make the answer look complete. When the new information arrives, ask for a repair limited to the affected passage and any dependent conclusion.
Know when to start a clean conversation
A long conversation may contain old versions, rejected examples, and rules that no longer fit. If focused corrections keep failing, make a clean brief. Include the current goal, current source material, the version to revise, and the few rules that matter. You can use a new conversation or clearly restate the active brief in the same one.
Do not carry every failed attempt into the clean brief. Keep the example that shows the desired result and the evidence that supports it. If you include a bad example, label it as bad and explain why. Otherwise it may be treated as a style to copy.
For continuing work, save the accepted version in a file you can identify. Give versions simple names that show which is current. This prevents a later request from revising an outdated draft. You should be able to recover both the previous accepted version and the current one without reconstructing a long chat.
Compare the revision before accepting it
Read the old and new versions side by side. First check the exact problem you asked to fix. Then check the protected facts and wording. Finally look for changes you did not request, such as a new promise, a deleted exception, or a changed conclusion. This comparison can be brief for a small edit and more detailed for a public document.
Ask ChatGPT to summarize the changes if that helps, but do not treat its summary as proof. It may overlook a deletion. For a long file, a document comparison tool can show every changed passage. Use the tool for mechanical differences and your judgment for whether the changes improve the result.
Accept the revision when it meets the named conditions. If one part still fails, ask for that part alone. Repeated whole-document rewrites often create more work. A clear request, a small repair, and a real comparison let you improve the answer while protecting the work that was already useful.
Check the result before you use it
- Did the named problem get fixed?
- Did protected facts and wording stay correct?
- Did any unsupported fact or promise appear?
Watch for: Repeated full rewrites can remove useful work and introduce new mistakes.