Rewrite one knowledge base article without losing its instructions

Give the article one reader and one job

An article about changing notification settings may currently mix account setup, permissions and troubleshooting. Before rewriting, state the reader's starting point and the result they should achieve. Put everything else in prerequisites, related links or a separate article. This editorial choice often matters more than changing the tone.

Create a task card: article identifier, audience, supported product version, required role, exact interface labels, expected result, known exceptions and owner. Only use approved material. If a step is uncertain, label it for verification rather than asking a model to fill the gap from memory. Google’s procedure guidance supports action-focused steps and enough context to locate the action.

A fictional rewrite with fixed product facts

Consider a fictional workspace tool. Members can mute personal email notifications in Settings → Notifications. Only an owner can change organization-wide defaults. The saved setting affects future emails; it does not remove messages already queued. These are invented inputs for the example, not Colay features.

Ask for distinct structures using the same facts. A procedure helps someone complete the task immediately; a troubleshooting version helps someone who cannot find the control. An FAQ can explain the queued-email exception. Eight requested approaches are possible, but they should address eight reading situations rather than multiply the same sentences.

A prompt that separates wording from product truth

Use Ask separately in Colay to see how selected agents interpret the task. Compare their outlines before refining entire articles. If one answer removes the permission requirement while others retain it, inspect the approved source. Agreement is not a substitute for testing the documented workflow.

Rewrite this approved knowledge base article: [text]. Task card: [audience, product version, role, exact UI labels, expected result, exceptions]. Produce a numbered how-to, a troubleshooting version and a short FAQ version. Preserve every condition, permission and exception. Do not invent controls or behavior. For each version, list the source sentence supporting each instruction. Put unclear or conflicting source material in a separate questions list. Recommend one structure for [reader situation] and explain the choice. Do not silently combine facts from different product versions.

Turn the best draft into a publishable revision

The final artifact can be small: approved title, prerequisites, procedure, expected result, exceptions and one relevant next link. Keep the source-to-instruction mapping with the editorial notes. Colay helps draft and compare; this workflow does not imply that it can connect to your knowledge base or publish changes automatically.

1. Choose the structure that matches the task card. Keep useful sentences from other drafts only after checking their meaning.
2. Walk through every step in the supported product version with the stated role. Verify labels, order, result and the documented exception.
3. Read the article as a new user: prerequisites should appear before they are needed, and a failed step should have an available next action.
4. Record the reviewer, article version and changed sections. Publish through your existing knowledge base workflow, retaining the previous version for comparison.

Judge the rewrite by what a reader can do

Ask a colleague unfamiliar with the draft to find the starting point, identify their permission requirement and explain what happens after the last step. Record misunderstandings as editing issues. If you have feedback or search data for that article, compare the same signals after publication without attributing every change to AI. Stop generating when the remaining work is a missing product fact, not a wording choice.

Questions, answered