Prompts for Rewriting and Editing

How to Use This Lesson Rewriting and editing are among the most common everyday uses of language models: fixing grammar, changing tone, simplifying explanations, shortening text, or adapting a message for another channel. They are also tasks where models often do too much: they rewrite text that only needed small corrections, change the author's voice, or quietly drop or change facts.

This lesson is a practical collection of rewriting and editing prompts, each designed to control what may change and what must stay. It ends with code that shows exactly what changed and checks that facts survived the edit.

Every recipe below follows two rules:

1. State exactly what may change.
2. State exactly what must not change (facts, numbers, names, meaning). Recipe Changes
3. Proofread with a change list Only spelling, grammar, punctuation
4. Change tone Tone, not facts
5. Simplify Vocabulary and sentence length
6. Shorten to a limit Length
7. Expand notes into prose Form, without adding facts
8. Adapt for a channel Format and length for email, SMS, or chat
9. Apply a style guide Terminology and conventions
10. Neutral and inclusive language Wording that excludes or stereotypes
11. Edit with tracked changes Any edit, with every change shown Recipe 1: Proofread With a Change List Use it when: the text is yours or someone else's, and only mistakes should be corrected.

Prompt Proofread the text in .

• Fix only spelling, grammar, and punctuation errors.
• Do not change wording, tone, or sentence structure unless a sentence is grammatically incorrect.
• After the corrected text, list each change as: original → corrected
• If there are no errors, return the text unchanged and write "No changes".

{text} Why It Works A narrow scope protects the author's voice (Lesson 17). The change list lets the author review every edit quickly. "No changes" prevents the model from making unnecessary edits just to show it did something. Recipe 2: Change Tone While Keeping Facts Use it when: a message is correct but sounds wrong for its audience: too harsh, too casual, or too formal.

Prompt Rewrite the message in for {audience}.

Target tone: {tone}

Must stay exactly the same:

• All facts, numbers, dates, amounts, and names
• Every requirement or consequence stated in the message

Do not add promises, apologies for things not mentioned, or new information. Keep it under {max_words} words. Return only the rewritten message.

{text} Example Input:

your payment of 4999 didnt go through, pay again before 30 Nov or your course will be blocked Settings: audience = a student; tone = polite and reassuring; max_words = 40

Possible output:

Your payment of 4999 didn't go through. Please try again before 30 Nov so your course stays active. Why It Works "Must stay exactly the same" names the facts that tone changes often damage: amounts, deadlines, and consequences. "Do not add promises" stops a friendly rewrite from inventing commitments, such as "we will extend your deadline". Notice that the output kept the consequence (the course stays active only if the payment is made) but expressed it positively. That is a tone change, not a fact change. Code can check that the numbers survived (see "Checking Edits in Code" below).

Recipe 3: Simplify Use it when: content must be understood by beginners, younger readers, or readers using English as a second language.

Prompt Rewrite the text in so that {reader} can understand it.

• Use short sentences of about 15 words or fewer.
• Use common words. If a technical term is necessary, keep it and explain it in a few simple words the first time it appears.
• Keep every fact and every step. Do not remove information to make the text simpler.
• Keep the same order of ideas.

{text} Why It Works Measurable guidance ("about 15 words") is clearer than "make it simple" (Lesson 14). Keeping technical terms with explanations teaches the term instead of hiding it, which matters for learners who will meet the term again. "Do not remove information" prevents simplification from becoming summarization. Recipe 4: Shorten to a Limit Use it when: text must fit a strict space, such as a meta description, an SMS, or a form field.

Prompt Shorten the text in to at most {max_chars} characters.

Keep, in this order of priority:

1. {must_keep}
2. The main action the reader should take
3. Any deadline or date

Remove greetings, filler, and repeated information first. Return only the shortened text.

{text} Check the Length in Code Models count characters approximately (Lesson 8). Always check the result:

def fits(text: str, max_chars: int) -> bool: return len(text) <= max_chars If the result is too long, send it back with the actual length: Your version is 187 characters; the limit is 160. Shorten it further.

Why It Works A priority list tells the model what to sacrifice first when space is limited, so the most important information survives.

Recipe 5: Expand Notes Into Prose Use it when: turning bullet notes into an email, a paragraph, or a document section.

Prompt Turn the notes in into {output_type} for {audience}.

• Use every point in the notes, in a natural order.
• Do not add facts, numbers, reasons, or promises that are not in the notes.
• Where the notes are incomplete, keep the gap visible, for example "[date to be confirmed]", instead of inventing a detail.

{text} Why It Works Expansion is where invented details appear most often, because the model fills gaps to make the text flow. Visible placeholders for missing information are better than plausible inventions, and they are easy to find and fill before sending.

Recipe 6: Adapt for a Channel Use it when: the same message must be sent by email, SMS, WhatsApp, or an in-app notification.

Prompt Adapt the message in for {channel}.

Channel rules: {channel_rules}

Keep all facts, dates, and the required action. Return only the adapted message.

{text} Example Channel Rules Channel Rules Email Subject line under 60 characters; greeting; up to 3 short paragraphs; sign-off SMS Plain text only; under 160 characters; no emojis; include the key date In-app notification Under 90 characters; start with the action; no greeting WhatsApp Friendly and short; up to 2 short paragraphs; at most one emoji Why It Works Each channel has different length limits and conventions. Putting the rules in a variable lets one prompt serve all channels, while the facts stay identical across them (Lesson 8, formatting by destination).

Recipe 7: Apply a Style Guide Use it when: content from different writers must follow consistent organizational conventions.

Prompt Edit the text in to follow the style guide in .

• Change only what the style guide requires. Do not rewrite for any other reason.
• After the edited text, list each change and the style rule it follows.

• Write "GOCOURSE" in capital letters.
• Use "learners" instead of "users" when referring to students.
• Write dates as "15 November 2026", not "15/11/26" or "Nov 15".
• Use the rupee symbol for prices: ₹4,999.
• Use "sign in", not "login" or "log-in", as a verb.

{text} Why It Works Rules as explicit context ensure your conventions are followed, not the model's own preferences. "Change only what the style guide requires" prevents general rewriting. Listing the rule for each change makes edits easy to review and helps writers learn the style guide. Recipe 8: Neutral and Inclusive Language Use it when: reviewing public text, such as course descriptions, job posts, or announcements, for wording that may exclude or stereotype people.

Prompt Review the text in for wording that assumes or excludes a group of people, for example by gender, age, background, or ability, when that is not relevant.

For each issue, return:

• the original phrase
• why it may exclude or stereotype
• a neutral alternative

If there are no issues, reply "No issues found". Do not change anything else.

{text} Example Input: Every student should bring his laptop. This course is perfect for young freshers.

Possible output:

• "his laptop" — assumes all students are male. Alternative: "their laptop".
• "young freshers" — implies the course is only for young people, which is not a course requirement. Alternative: "freshers" or "beginners". Why It Works The prompt asks for suggestions with reasons, not an automatic rewrite. A person makes the final decision, which is appropriate because context determines whether a phrase is relevant or exclusionary.

Recipe 9: Edit With Tracked Changes Use it when: a person must approve every change, as with official documents, policies, or published content.

Instead of asking the model to describe its changes, let code compute exactly what changed between the original and the edited text. This is reliable, because it does not depend on the model reporting its own edits accurately.

Showing Word-Level Changes import difflib

def word_diff(original: str, revised: str) -> list[str]: """List the word-level changes between two texts.""" a, b = original.split(), revised.split() changes = [] for op, i1, i2, j1, j2 in difflib.SequenceMatcher(None, a, b).get_opcodes(): if op != "equal": changes.append(f"{op}: '{' '.join(a[i1:i2])}' → '{' '.join(b[j1:j2])}'") return changes

original = "your payment of 4999 didnt go through, pay again before 30 Nov or your course will be blocked" revised = "Your payment of 4999 didn't go through. Please try again before 30 Nov so your course stays active."

for change in word_diff(original, revised): print(change) Output:

replace: 'your' → 'Your' replace: 'didnt' → 'didn't' replace: 'through, pay' → 'through. Please try' replace: 'or' → 'so' replace: 'will be blocked' → 'stays active.' Code Explanation split() breaks each text into words, so the comparison works word by word rather than character by character. SequenceMatcher(...).get_opcodes() describes how to turn the original into the revision: equal parts are unchanged, while replace, delete, and insert parts are edits. Only edits are listed, with the original words and the new words. Checking That Facts Survived import re

NUMBER = re.compile(r"\d+(?:[.,]\d+)*")

def lost_numbers(original: str, revised: str) -> list[str]: """Numbers present in the original but missing from the revision.""" return sorted(set(NUMBER.findall(original)) - set(NUMBER.findall(revised)))

print(lost_numbers(original, revised)) print(lost_numbers(original, "Your payment didn't go through. Please try again soon.")) Output:

[] ['30', '4999'] Code Explanation The pattern finds numbers, including those with commas or decimals. Set subtraction finds numbers that appear in the original but not in the revision. The first revision kept both the amount and the date. The second revision, a plausible "friendlier" rewrite, dropped the amount and the deadline. The check catches this immediately. For other facts, such as names or course titles, check that each required phrase appears in the revision.

Choosing a Recipe Need Recipe Fix mistakes only 1 Make a message kinder or more professional 2 Make content easier to read 3 Fit a strict length 4 Turn notes into a message 5 Send the same message on several channels 6 Enforce organizational conventions 7 Review public text for exclusionary wording 8 Approve every change 9, combined with any recipe Common Mistakes Mistake 1: "Improve This" Without Limits What it is: Asking to "improve" or "make better" without saying what may change.

Why it happens: The goal feels obvious.

What it causes: Full rewrites that change voice, structure, and sometimes meaning.

How to fix it: State the scope of changes and what must stay.

Mistake 2: Facts Lost During Tone Changes What it is: Friendlier rewrites that drop deadlines, amounts, or consequences.

Why it happens: The model prioritizes tone over information.

What it causes: Messages that sound better but are no longer accurate or complete.

How to fix it: List the facts that must stay, and check numbers and key phrases in code.

Mistake 3: Invented Details When Expanding What it is: Adding dates, reasons, or promises when turning notes into prose.

Why it happens: The model fills gaps to make text flow.

What it causes: False commitments in official communication.

How to fix it: Forbid additions and require visible placeholders for missing details.

Mistake 4: Trusting the Model's Description of Its Own Changes What it is: Relying on the model's change list as a complete record.

Why it happens: The list looks thorough.

What it causes: Unlisted changes go unnoticed.

How to fix it: Compute differences in code with difflib.

Best Practices Always define what may change and what must stay. This is the core of every editing prompt.

Protect facts explicitly. Name numbers, dates, names, and consequences that must survive.

Use measurable guidance. Sentence length, character limits, and channel rules.

Make gaps visible instead of filling them. Placeholders are safer than inventions.

Compute changes and check facts in code. Do not rely on self-reported edits.

Keep people in charge of sensitive edits. Suggestions for inclusive language and approval for official documents.

Try It Yourself Exercise 1: Tone Change With Fact Checks Write three short, harsh messages that each contain an amount and a date. Rewrite each with Recipe 2 for a polite tone. Use lost_numbers() to confirm that no amount or date was lost, and word_diff() to review every change.

Exercise 2: One Message, Four Channels Write an announcement about a class schedule change. Use Recipe 6 to adapt it for email, SMS, in-app notification, and WhatsApp. Check each result against its channel rules in code (length limits) and by reading (format), and confirm all versions contain the same date.

Exercise 3: Style Guide Editor Write a paragraph that breaks at least four rules of the style guide in Recipe 7. Run the recipe, then use word_diff() to compare the original and edited text. Check whether every change in the diff matches a rule in the model's change list, and whether any unlisted change was made.