AfieldChoose the output before asking for prose
Continue from a topic, company or research result in the assistant. Name the reader, format and material to use. Request the finished text rather than an outline:
Write a complete article for an implementation manager deciding which
onboarding-checklist fields can be reused. Use the approved template
above. Include a filled example, customer-specific fields and a short
review checklist. Return the title and full body.For an email, request the recipient context, subject and body. For a social post, specify the platform, audience and the selected source. A multi-part request should name each desired output.
Read the example before polishing the style
Look for the part that does the teaching: the completed record, the changed paragraph or the worked decision. If the draft says “include examples” but contains none, request the missing example and the revised full text.
Check whether the example uses supported product details. A hypothetical example can be useful, but should be identified as such. An invented customer outcome should not be left in the draft as proof.
Replace the generic paragraph with a finished example
Editing demonstration: the onboarding record below is fictional. It shows the level of detail to request in an article about implementation checklists.
Weak draft: A streamlined onboarding checklist aligns stakeholders, improves efficiency and ensures a seamless customer experience.
That sentence gives an implementation manager nothing to use. A replacement can explain a real decision inside the workflow:
Revised passage: Keep the data-import task in the shared checklist, but confirm its owner and acceptance check for each customer. In this example, Demo Co's administrator exports the current account list by Tuesday. The implementation lead maps its fields and returns rejected rows for correction. The import is complete only when the customer checks five agreed sample accounts and confirms their owners and contact fields. Uploading the file is an intermediate step.
The article can now show three customer-specific fields: the export owner, the mapping rules and the sample used for acceptance. Those details explain how the reader should adapt a checklist. Replace the fictional details with a permitted, verified example if you have one; do not turn this demonstration into a claimed customer result.
For a source-based article, keep the reference beside the statement it supports. A vendor announcement can establish that the vendor announced a feature; it cannot by itself establish a customer's outcome. The claim-level editing walkthrough shows how to make that distinction in a full draft.
Make a concrete revision
Keep this draft. Replace the general efficiency paragraph with the
completed checklist example. Explain the two fields that change for
each customer. Return the full revised article with its source links.When an editable draft card is available, edit its title and body there. The topic-to-post walkthrough shows those fields. Reopen the saved result in the original conversation or Tasks → History and check that it contains the complete selected version.
Add a picture only when it explains something
A screenshot should show the control or output discussed nearby. A diagram should clarify a relationship that prose makes hard to follow. For a tutorial, avoid a generated interface that changes labels or invents buttons.
Once the draft is ready, choose whether to keep it, save it to a connected site or publish. Use the channel-action guide to check the exact destination and result.