On this page
Forbes called vibe coding "the biggest unlock for non-technical founders right now" (Forbes, March 2026) — describing software you build by talking to it. The same idea works on the thing that talks to your customers: you can set your assistant up by chatting to it, and never open a settings panel.
These ten prompts are not aspirational. Each maps to a management tool a workspace admin actually holds, reached over the open Model Context Protocol.
The rule that makes this safe
Two behaviours, always:
- Look-ups run immediately. Asking a question costs you nothing and changes nothing.
- Changes show their payload and wait. Before anything is written, your mate prints the exact action and waits for your yes.
And your authority comes from your verified sign-in, not from what you type. A workspace id in a prompt grants nothing; membership is re-checked when the tool runs. The full contract is in managing from chat.
The 10 prompts
Paste them one at a time. Replace the bracketed parts.
1. Add https://[your-site] as a knowledge source and index it.
2. Search my knowledge for "[refund window]" and show me what you would answer.
3. List my knowledge sources and turn off the outdated [price list] one.
4. Set my brand name to [Business name], the logo to [logo URL], and the
welcome message to "[one friendly sentence]".
5. Add my MCP server at https://[your-site]/mcp as a connection. Show me every
tool it exposes and its access level before you save anything.
6. Publish the workspace so customers see these changes.
7. Show me last week's conversations, and the transcript of any where you
could not answer.
8. Run an insight audit and list the top gaps in my knowledge.
9. Show me the open handoff requests, then reply to the oldest one with
"[a sentence in your voice]".
10. Show my usage for the last 30 days by provider, and how it compares to my
limit.What each one is doing, in order: teaching the assistant your site and indexing it; dry-running an answer before a customer sees it; retiring a source that has gone stale; branding it as yours; connecting your own systems as tools; freezing a version so the change goes live; reading the week; finding what customers ask that you do not answer; working the human handoff inbox; and watching the bill on usage.
Prompts 1–3 are the ones to run first — an assistant is only as good as what it knows, which is why the knowledge guide is the first thing most owners read. Prompt 5 has a companion: the connect an MCP server guide walks through access levels, and MCP check tests a server before you attach it.
The one you write yourself
The prompts above configure the plumbing. This one sets the voice, and it is worth writing by hand once:
You answer for [Business name], a [what you do] in [city].
Only answer from our published pages and knowledge sources. If the answer is
not there, say so and offer a human.
Hand off to a person when: the customer asks for one, the question is about
[billing / legal / a complaint], you have failed twice, or the customer is upset.
Never invent prices, stock, delivery dates or policies. Mark anything you are
unsure of with [CHECK] rather than guessing.
Tone: [warm and brief]. Reply in the customer's own language.Paste it as your assistant's instructions, then test it with three real customer questions before you publish.
What chat will not do for you
Honesty matters more than a longer list. Reading your model policy and limits works conversationally; the plan ceiling itself is not a chat-side change. Feature switches — guest access, whether actions are on — live in the Console governance panel. And a change to somebody else's workspace is structurally impossible, which is the point.
Where this goes next
Configuring by chat is the owner-facing half of a larger shift: assistants that act rather than describe. On the visitor-facing side, WebMCP lets a page publish its own actions — book, check an order, start a return — for an agent to call with the visitor confirming each one; the page tools guide is the setup. Machine-readable context helps too, which is why we publish our own /llms.txt.
The fastest way to see whether these prompts do anything useful for you is to have something to run them against: build an assistant from your URL first, then work down the list. Pricing starts where a small site starts.
Questions
Do I need to know how to code to use these prompts?
No. Each one is a sentence in plain English. The assistant turns it into a management action, shows you exactly what it will change, and waits for you to approve before anything happens.
What stops a prompt from changing the wrong account?
Your role comes from your verified sign-in, never from text in a chat. A workspace id typed into a prompt cannot cross that boundary, and your membership is checked again at the moment the action runs.
Can I do all of this in the Console instead?
Yes — chat and the Console drive the same management tools, so it is a matter of preference. Chat is faster for a known change; the Console is better for browsing what exists and comparing settings.
Which changes still need the Console?
Reading your model policy and limits works from chat, but the plan ceiling itself is not something an admin moves conversationally. Feature switches such as guest access live in the Console governance panel.
What happens if a prompt asks for something the assistant cannot do?
It is refused by name rather than improvised. The tool list is a closed allowlist per role, so anything outside it is simply not available — you get a clear no instead of a wrong action.