Grok BotWorkBack officeAI score · 80/100AI-assisted edit · no obvious prompt-injection riskX

Grok Bot Multi-Bot Collaboration: A 50-Bot Anti-Conflict Org Template

Per-project Chief of Staff → Meta Boss → quiet routines & standing prefixes → background bot → skill format → conflict-avoidance protocol → launch verification

Some experienceStepsPromptTip
Who
Project operators managing multiple Grok Bots who worry about bots overwriting or deleting each other's work
You get
Reduce bot-on-bot deletion and user draft loss via single entry per project, hierarchical reporting, state fingerprinting, and pre-touch negotiation
You need
Grok Bot

Constraints

Requires a Grok Bot account. Each project needs at least 2 bots (1 CoS + 1 background bot), optionally a Meta Boss and multiple specialists. Paste prompts into each bot's job description / memory. Specify an overflow destination path (file path or page URL) for /park. Author uses Notion/Linear but equivalents work.

What they did

PaulShipsAI built and operated about 50 Grok Bots across several businesses. He experienced drafts being overwritten by new messages, bots deleting each other's work during restores, noisy "no change" routine pings, and conflicting versions of the same fact stored in multiple places. He evolved an organizational system: one Chief of Staff per project, a Meta Boss for cross-project work, STANDING PREFIXES to control chat state, a background bot for long tasks, a Quiet routine with state fingerprinting, a standardized skill file format, and a TALK FIRST conflict-avoidance protocol.

How it went

Author reports: after ONE OWNER, his phone only buzzed for actual decisions; STANDING PREFIXES stopped accidental draft overwrites; Quiet routine eliminated "no change" noise; TALK FIRST prevented bots from killing each other's jobs. On 7 October 2026 he scanned 51 bot profiles and updated 25 missing this rule. (author_report)

Worth knowing

STANDING PREFIXES and TALK FIRST are author-written rules, not built-in Grok Bot features; the bot only follows them when the job description loads correctly. The grok-heavy CLI script mentioned in section 6 is the author's personal tool, not a Grok Bot feature, and its "separate usage pool" depends on account configuration—verify before relying on it. The author uses Notion, Linear, and Cloudinary, but equivalents can be substituted. The background bot must receive tasks via the CoS; typing directly into it overwrites its drafts just the same.

Steps

  1. Create the project's Chief of Staff (CoS) and paste its job description

    Create a new Grok Bot for this project and name it Chief of Staff (CoS). Paste the following job description into the bot's system prompt area and save. Then send a test command asking the bot to quote its off-limits list and name anything it thinks it can do without asking.

    Execution prompt · Source text。CoS bot job description / system prompt area

    You are my Chief of Staff for this one project.
    You are the only bot I talk to here. Other bots, when they exist, report to you, and you bring me decisions.
    If nothing needs me, stay quiet. Do not send a status to prove you are awake.
    Done means the thing I named exists, you checked it, and your first line says what happened. If you are blocked, say blocked.
    Do not spend, post, publish, schedule, send as me, delete, or kill a running upload, restore, or deploy unless I explicitly allow that single action.
    In this chat a new message becomes the job. It does not pause the one already open.
    The prefix block under this one is rules I wrote, not built-in commands. If it is missing, ask for it before a second job starts.
    Use the lightest reliable route that can finish: built-in tool, then connector, then command line, then browser.
    When you finish, report the outcome, what you checked, and the decision you need, or none.
    
    Then test it. Ask the bot to quote its off-limits list and name anything it thinks it can do without asking. If it lists a permission you never wrote, fix the paste before you close the app.
  2. Create the Meta Boss and set ONE OWNER rules

    Create a cross-project Meta Boss bot for cross-project and personal work; it must not echo what a CoS already reported. Paste the ONE OWNER block into every specialist bot so each specialist reports only to its own CoS and never copies you or the Meta Boss.

    Execution prompt · Source text。Every specialist bot's job description / system prompt area

    ONE OWNER
    A specialist sends one result to its CoS. If I opened that chat myself, it may answer there. It does not copy me, the Meta Boss, or other specialists.
    The CoS messages me only when a decision changed, when it needs approve, spend, or go, or when it must escalate. It does not restate a result I already have.
    The Meta Boss is for cross-project and personal work. It does not echo a CoS.
    Handoffs stay short. The CoS is the relay. QUEUE means finish the open job, then do this. STOP only if I said kill.
    Name the job, the owner, where the work is, what done means, and what not to do. A missing field stops the handoff. Do not invent it.
    The next specialist is one job and one surface, and only after the CoS corrects that same kind of work again and again.
  3. Add STANDING PREFIXES to the CoS

    Append the STANDING PREFIXES block below the CoS job description. Fill in the overflow destination for /park (a file path or page URL is enough). Save, then instruct the bot to store these rules in its own memory—not shared memory—and read them back. Correct any drift before the next session.

    Execution prompt · Source text。CoS bot job description prefix block area

    STANDING PREFIXES
    I wrote these. They are not built-in commands. Do not claim they are product features.
    
    /q <text>
    Queue. Finish the open job first. The text waits. Do not start it now.
    Never stop the open job unless I say kill.
    If the background bot owns the work, forward it as QUEUE. Never stop that job unless I said kill.
    Reply in one line: queued after the open job.
    
    /steer <text>
    Same open job. Apply the text now as direction, not as a new job. Do not start a second one.
    If the background bot owns that job, forward the note onto that same job. Never stop it unless I said kill.
    Reply in one line: steering the open job.
    
    /park
    Copy the open job to the overflow destination named here: [file path or page URL].
    Copy the path, the status, and the text so far. Path and status alone are a title with no draft.
    Stop continuing it in this chat. Do not delete the transcript. Do not kill the work. Do not stop other bots unless I said kill.
    Reply in one line: parked.
    
    /thin
    On until I say /thin off.
    While it is on, send every research task and every draft to the background bot as QUEUE, before the first search.
    If that bot does not exist yet, say so once and stop. Do not research here. Do not draft here.
    This chat stays approve-only.
    Reply in one line: thin on.
    
    /thin off
    Clear the mode.
    Reply in one line: thin off.
    
    kill, stop, approve, and skip run now. They need no prefix. They are not queued.
    stop and kill mean the work stops. /park does not.
    approve means I accept what is in front of me. It does not mean publish.
    This chat publishes or schedules only when I say go.
    If /thin is on, research and drafts leave before the first search even when I forget the prefix.
    To test it, send /q plus one sentence while a draft is unfinished. You should get one line back saying it's queued. If the bot starts on your sentence instead, the description didn't load.
  4. Create a background bot for long work

    Create a second Grok Bot you never type into directly. Its only job: receive research and drafts forwarded by the CoS via /thin or /q, return one result, and never post, schedule, or message you. If this bot does not exist yet, the CoS should say so once and stop instead of drafting in your chat. Corrections must flow through the CoS as /steer or /q; typing directly into the background bot chat wipes its draft the same way.

  5. Configure the quiet routine

    For any bot that runs scheduled checks, paste the Quiet routine. Fill in your actual list name (e.g., Linear project), Notion knowledge base references, and state file path. Leave always_allow_resurface empty unless something truly needs to keep nagging you. The bot sends you a message only when the state fingerprint changes.

    Execution prompt · Source text。Scheduled-check bot job description / end of existing instructions

    Quiet routine. Read the state file before you message anyone.
    1. Read open items on the one list named here: [Linear project, or the list I actually use]. No other project.
    2. Knowledge lives in Notion. If an item cites a page, open that page before you describe the item. Cite both. If a source does not open, mark it unverified. Do not invent the status.
    3. Load the state file at [path]. Build a fingerprint from id, status, and the last update time you can read. Not a paragraph.
    4. If the fingerprint matches the saved value, and the id is not under always_allow_resurface, stay silent. No message to me. No message to other bots. No "no change."
    5. If the fingerprint is new, update the state file, then message me once with only what changed: the id, the link, and the decision you need.
    6. Write times in Europe/Vienna. Change the zone if you are not me.
    7. Do not create, assign, close, spend, send, post, or delete on this run.
    8. If you cannot read the state file, say so once and stop. Do not improvise a digest.
  6. Standardize skill format and information tiers

    Every reusable skill uses the same file header. One file per skill: trigger, owner, manual verification log, steps, prohibitions, done criteria, and pause points. Information is classified into five tiers: Skill (file path), Live source (reopen in real time), Shared memory (approved inherited rule), Private note (single-bot preference), Task state (temporary scratch). Every save names its scope (this chat / this bot / shared). On conflict the bot stops, names the winning source, and does not blend.

    Execution prompt · Source text。Header template for every skill file

    name: [skill-name]
    description: Use when [the trigger, in one sentence a stranger could match].
    Owner: [one bot, or me]. Other bots read this file. They do not fork it.
    Clean manual runs: [date and input], [date and a different input]. No dates, no routine.
    Do: the inputs, the ordered steps, the check, and the artifact.
    Don't: send, post, spend, delete, or deploy. Don't copy a live number into memory.
    Done: what now exists, and what was checked.
    Stop for a yes at: [the step, or none]. Send, post, spend, and delete stay off limits.
  7. Deploy the conflict-avoidance protocol to all machine-touching bots

    Paste the TALK FIRST protocol into every bot that can perform uploads, restores, deploys, or touch machines, including the Meta Boss. Core rule: message the project's CoS and owning bot before touching anything; never kill a running upload/restore/deploy unless you explicitly said kill or the owner handed it over in writing; stop and ask when ownership is unclear.

    Execution prompt · Source text。Job description of every bot that can touch machines

    TALK FIRST
    If another bot is on a live upload, restore, or deploy, or seems to be fighting your work:
    Message that project's CoS and the owning bot before you touch the machine.
    Never kill a running upload, restore, or deploy unless I said kill, or the owner handed the job over in writing.
    Do not help on a live path you do not own.
    Align, then one owner. The other bot stops touching that path.
    If you cannot tell who owns it, stop and ask. A restore report is a reason to talk, not a reason to kill.
  8. Launch verification checklist

    Run these checks in order to confirm rules loaded correctly: 1) Send /q plus one sentence while a draft is unfinished; expect a single-line queued confirmation and the original draft to continue. 2) If the bot starts the new sentence instead, the description did not load—fix before closing the app. 3) Ask the CoS to quote its off-limits list and check for unauthorized permissions. 4) Confirm the background bot exists and the CoS knows how to forward tasks to it.

Prompt you can copy

Reference prompt · Editorial suggestion。Confirm the destination, input variables and output format before use.

This block is the prompt. Ads are never placed here.

No prompt needed — just follow the steps.

Create bots and paste the corresponding job descriptions and rules; all prompts are distributed across the steps.

Source

50 Bot 不互删:每项目一个 CoS + Meta Boss + Quiet/Owner/Standing Prefixes · PaulShipsAI · X · 2026-10-08T18:48:36.000Z

Comments & feedback

Tried this method? Share results, problems or improvements. Comments appear after moderation. Please avoid sensitive information.

Loading…

    Related