Tips for Asking

Give the assistant a specific item and a clear outcome. A short request can be enough when the context is clear, but check which project and post it is using before asking for a change. Review the saved result as well as the chat response.

​

Keep it short

Include the detail that determines a useful answer. These are example requests, not promises that every action is available in every context:

• “Shorten this introduction while keeping the eligibility requirements.”
• “Suggest a clearer title for this draft before changing it.”
• “Explain the reported error on this post.”

If you want suggestions only, say so. If the assistant misunderstands, restate the intended result and name what must remain unchanged. Check the item before repeating a request that could already have changed it.

​

The open post is the default

The assistant receives context from recognized pages and open items. Its instructions use the open post as the subject of short requests such as “make this shorter.” Check the item identified in its response; an intended default does not guarantee that every request has the right context. On a list page, or when switching between posts, name the intended item. Include the selected project when there could be confusion. See the assistant overview for how page context and actions work together.

​

You can ask for more than one thing

Separate the requested outcomes so you can check them individually. For example: “Suggest a clearer title and identify any unsupported claims in the introduction. Do not publish.” For a request that combines editing and scheduling, specify the item, date and time zone. Check each result rather than treating one successful action as proof that the whole request finished. Some edits can save directly; a combined request is not necessarily one preview followed by one approval.

​

Resolve ambiguity before continuing

The assistant is instructed to ask a short question when a request is too vague to act on safely. Help it by naming the post, requested change or intended option. Do not rely on it always detecting an ambiguity: if the response points to the wrong item, correct the context and inspect that item’s state.

​

Approving changes

Some actions use a confirmation card; some requested edits can apply directly. When a card appears, read the action and target before using its approval or cancellation control. Use the card to answer that request rather than treating a conversational “yes” as a substitute. After an action, open the affected item and check the change. If an Undo option is offered, read what it covers before using it. Approval of an action is also different from checking that a published page is correct; see the publishing guide for the publication workflow.

​

Keep responsibility for the content

Check business facts, names, services, prices and supporting sources before accepting a draft. A fluent answer can still contain an unsupported statement. Supply the missing fact or remove the claim rather than relying on a general promise that the assistant never invents information. State whether you want an explanation, suggestions or an actual change. Keep publishing instructions explicit and verify the resulting item. These habits help you review the work; they are not a guarantee against every mistaken action.

​

Things to know

Allow the current request to finish before starting it again. If it fails or the response is unclear, inspect the post or job first: a missing response does not prove that nothing happened. Follow the reported error and avoid repeatedly submitting the same change without checking its result. Use New chat for a fresh conversation, or history to reopen an earlier conversation for the selected project. Starting a new conversation is separate from reversing an earlier edit.

​

Good things to try first

Begin with a small request whose result you can inspect: explain a post’s error, suggest an alternative title, or shorten one paragraph with its required facts preserved. Once the result matches your intent, decide whether to request the next change. Keep the original requirements visible when the work spans several requests.