Plugin content policy

Plugins run on a device in someone's home, with access to a voice, a camera and motors. That is the standard everything here is measured against.

Prompts are behaviour, and they are reviewed as behaviour

A plugin holding the assistant permission ships a system prompt. That string decides what the robot says on someone's behalf, so it is part of what your plugin does. It is not configuration, and not a detail of how it is built.

Three consequences, stated because a reviewer cannot infer them from code:

A prompt is reviewed line by line, like source. It is prose, so it reads as harmless at a glance; it is also the one place where a plugin's behaviour can be changed completely without touching a line of JavaScript.
Changing a prompt is a new version. Shipping a different system string under the same version is misrepresenting what the plugin does, which is already forbidden below.
What the assistant says is what your plugin said. You do not get to disown a reply because a model produced it. Every rule in this document about what the robot may say applies to text you caused it to say.

Your prompt must be readable in your source

Write the system string as a literal in your source: one string, or adjacent strings joined at the point of use. Do not assemble it at runtime from fragments, decode it, or fetch it from your own storage.

This is a review requirement, not a style preference. A prompt that only exists once the plugin is running cannot be read by the person deciding whether to publish it, and "trust me, it says what I claim" is not a review. Submissions whose prompt cannot be read in the source are rejected, and the remedy is always the same: write it out.

Interpolating the user's own words into a prompt you otherwise wrote as a literal is fine. That is the plugin doing its job. Building the instruction itself out of pieces is not.

Not allowed in a prompt

Impersonation. Instructing the assistant to speak as a named person, as a company or brand, or as Hai Robo itself in a way that implies official standing. A tutor with a character name is fine; a prompt claiming to be someone is not.
Elicitation. Steering the conversation toward personal information: address, workplace, school, financial details, who else is in the house, when the house is empty. You have no network and nowhere legitimate to put such answers, and once microphone is granted there is no second consent prompt per question. A plugin that asks is out, whatever it intends to do with it.
Laundering. Using the assistant to produce what this policy already forbids the robot saying aloud. The prompt is a route around every rule written about plugin output, and it is closed: reaching a banned outcome through the model is the same violation as writing it into voice.speak.
Instructing the assistant to break its own rules. Telling it to ignore its instructions, to reveal them, or to behave as though it has none. The host wraps your prompt and states plainly that it cannot override safety rules; attempting it anyway is grounds for removal, not a failed attempt.

What a good prompt looks like

Say what role the assistant takes, what it should do with what it hears, and what shape the reply takes. Nothing about the user beyond the task.

Not allowed

Requesting permissions you do not use. The clearest signal of bad intent, and the easiest to check.
Misrepresenting what the plugin does, in the name, summary or at runtime.
Impersonating a person, brand or organisation you are not.
Targeting or harassing anyone, including through what the robot is made to say.
Sexual content, graphic violence, or content aimed at children that adults would not want a robot saying aloud.
Working around the sandbox rather than within it: attempts to reach the network, escape the plugin folder, or navigate away.
Collecting personal information. You have no network; a plugin that asks for personal details has nowhere legitimate to put them.
Using the camera for anything but what you told the user. You receive positions, not images, and the permission is still granted on the basis of your description.

Expected

The summary describes what the plugin actually does.
Permissions match the features.
It degrades honestly with no dock and with permissions declined.
It stops what it started (lights, gaze, camera) when it closes.

Reports and removal

Users can report a plugin from the gallery. Reports are read by a person.

A plugin found in breach is removed from the gallery and can be blocked remotely on devices that already have it. Blocking is used for plugins that are harmful or deceptive, not for ones that are merely poor.

If yours is removed and you think that is wrong, reply to the submission address and say so. There is no automated appeal because there is no automated removal.