Iterating on a draft

Most of the value is in the second pass. Ask for a change to an existing document and the edits come back as tracked suggestions you accept or reject.

Asking for a change

Open the document, describe what you want. It works on what is there rather than starting over, so the parts you liked survive.

Useful instructions are specific about the problem, not just the target:

“The opening buries the point — lead with the failure it prevents.”
“Cut this to about 600 words. Lose the history section, keep the examples.”
“The API section assumes people know what a webhook is. They don’t.”
“Too salesy from ‘Why teams choose us’ onwards. Make it factual.”

Vague instructions (“make it better”, “improve the flow”) produce vague edits.

Reviewing what comes back

Changes arrive as suggestions: added text underlined, removed text struck through, attributed. Nothing is applied until you accept.

Accept or reject individually — this is usually right, because a revision is rarely wholly good or wholly bad — or take everything at once from the review bar.

Rejecting everything costs nothing. The document is untouched, so a revision that misses is a dead end rather than damage.

Changing part of a document

Select a paragraph or section first and the revision is scoped to it. Better for a targeted fix: the model has less room to “improve” things you did not ask about, and the diff is small enough to actually read.

When to start over instead

If two rounds have not moved it, the brief was wrong rather than the draft. Go back to the brief and restate the audience and the outcome — that is usually what was missing.

Publishing

You cannot publish while suggestions are unresolved. The WP panel says so, and the reason is worth stating: publishing would put the tracked changes — including the text marked for removal — on your live site. Accept or reject first.