Make the service description concrete
Write a short statement a reader can understand:
This companion helps you apply the newsletter planning method to your own draft. It can ask questions, suggest an issue outline, and review that outline against the method. Responses are generated by AI. They are not personal messages or approvals from the author.
This fictional description makes no promise of a human response. If you actually offer personal review, describe its separate route and terms where readers can find them. Do not let the skill improvise that offer.
People bring different assumptions to a chat interface. In a discussion about chatbot labeling, u/IniNew wrote:
“I assume any chat is a bot unless it specifically says it’s an agent.”
That is one person's expectation, not a naming standard. In an author product, avoid relying on a word such as “agent” or a familiar author photo to explain who is responding. State the relationship directly.
Use a proceed, clarify, and refer table
The following example is a proposed boundary specification for a fictional newsletter companion. It is not an observed product workflow or a guarantee that instructions will always be followed.
| Reader request | Action | Boundary and useful next step |
|---|---|---|
| “Help me choose between these two themes for our monthly issue.” | Proceed | Apply the book's audience and purpose criteria to the supplied options |
| “Which theme should we use?” with no audience or purpose | Clarify | Ask who the issue serves and what readers should be able to do afterward |
| “Our editor and sponsor want different themes. Decide who is right.” | Refer the decision | Compare the options against stated criteria, but leave approval to the organization's decision owner |
| “Tell me what the author privately thinks of our organization.” | Decline that claim | Explain that private opinions are unavailable; offer to apply the published method |
| “Send this to the author and tell me when they will reply.” | Check the actual service | Use only a configured, verified route; otherwise say that no submission has been made |
The third row is especially useful. Referral does not require abandoning every helpful part of the request. The skill can organize the competing criteria while declining to assume authority over the final choice.
Clarification is different. If the missing audience description would let the skill continue within its role, ask for that description. Do not refer routine uncertainty to the author and create a support obligation you never intended to offer.
Write the dialogue at the boundary
Here is a fictional reader request:
Our editor wants a volunteer spotlight. The sponsor wants a fundraising issue. Use your expertise and tell us which one we must publish.
A proposed response:
I can compare those options using the newsletter method, but I cannot approve an issue for your organization. Who owns that decision, and what is this month's main reader outcome? If the outcome is volunteer recruitment, we can assess how each option supports it. If your team has not agreed on the outcome, I can help you prepare a short decision note for the editor and sponsor.
The response names the limit, identifies the missing information, and offers an in-scope next step. It does not claim that an AI recommendation becomes binding because it comes from an author's framework.
If the reader answers, “The editor owns the decision, and the goal is recruitment,” the skill can continue the comparison. If the reader answers, “Just overrule the editor,” it should maintain the boundary without repeating the whole introduction.
Write both turns into your examples. A boundary that disappears after one pushback is not the behavior you intended to publish.
Do not promise a handoff you cannot complete
A referral can be a useful suggestion: contact your newsletter's editor with a decision note. A handoff is an actual transfer through a working route. Keep those separate.
In the same chatbot discussion, u/MyNameIsNotMarcos wrote:
“Chatbots can be useful in some cases. But they are rarely useful when one needs to chat with a person.”
That expresses a user's frustration, not evidence about all chatbots. It points to a practical design question for authors: when someone asks for a person, what can your service honestly offer?
If there is no personal-review channel, the response should say so. It can still prepare a note containing the reader's goal, relevant facts, competing options, and unresolved decision. Let the reader review that note before sharing it themselves.
If a real handoff exists, verify the destination and explain what was actually submitted. Do not invent a reply time, claim the author has read the conversation, or describe a failed submission as successful. Only include information needed for the decision, following the service's actual sharing arrangements.
Test both sides of the boundary
Try a normal planning request, a missing-context request, an authority request, a request for personal author access, and a repeated demand after referral. Keep the resulting conversations and compare them with your intended responses.
Microsoft's agent evaluation scenarios include both limitation checks and checks against unnecessary escalation. That is a useful balance: your companion should handle its core task while recognizing requests outside its information or authority.
For each test, ask whether the skill identified the right limit, offered a useful next step, and accurately described any action it took. The agent skill testing guide explains how to make those expectations repeatable.
Bring your one-sentence service description and completed boundary table to Skillfully and choose Book onboarding. They make it easier to discuss a companion that helps readers apply your method while setting a clear expectation about access to you.