# Collaboration Bot skills changelog ## 1.2.0 (2026-10-20) (protocol version 6: changed) Protocol version changes from 5 to 6, because the team file Usage section, the HEADROOM and OFFER bodies, the message header (no BUDGET-LEFT), and the board (no Usage spent column) change. A protocol 5 team reads budgets and charged usage that no longer exist, so the version check holds tasks until both sides are on protocol 6. - **Usage page only.** The only usage source is each team's own usage page (grok.com/dashboard/usage, Group by Product). No charging, no estimates, no per-project ledger. The page shows account totals and Grok Bot's share, not bots or projects. - **Two limits per owner.** An overall cap (% of the account's weekly usage) and a Grok Bot cap (% of weekly usage for Grok Bot, at or under the overall cap), shared by all projects. Warn at 80% of either (no new claims, offer queued open tasks); pause at either limit or when usage runs out. Prepaid credits stay off unless the owner sets a limit. - **Two numbers reported.** The team file `## Usage` has overall weekly usage used % and the Grok Bot share %, plus reset time and read time. A failed read is `not read ()`, never a default; a team with unread usage takes no open tasks, and without a sign-in it takes only tasks its owner sends directly. - **When to read.** Before and after every major task. If both limits were more than 10 points away at the last end reading, a back-to-back task skips its start read. No scheduled or periodic reads. - **Headroom.** The smaller of (overall cap - overall used) and (Grok Bot cap - Grok Bot used), plus the reset time. HEADROOM and OFFER carry these numbers. - **Removed.** Per-project charging, Usage spent and Project budget used, the task size map and running averages, per-project budgets and the budget-split card, BUDGET-LEFT, and the large-size fallback with no sign-in. - **Setup cards.** `limits` (1.2.0; skip default overall 25% and Grok Bot 25%) replaces `allowance`; `budget-split` is gone. On install, the catch-up shows the `limits` card and the bot rewrites its team file Usage section, then sends VERSION (protocol 6). - **Missed-team rule dropped (for now).** No more 12-hour missed-team rule or PAUSED-MISSED status, and no Status updates required on long tasks. - **No task timeouts.** The 8-hour claim and OPEN-task timeouts are gone. A claimed task stays with its team until that team releases it, or its owner or the requesting team's owner decides otherwise. An OPEN task stays OPEN until claimed, or until the requesting team's owner drops or changes it. - All three skills, protocol/README.md, USAGE.md, MESSAGES.md, TASKS.md, CLOSE.md, and tasks/BOARD.md updated. ## 1.1.11 (2026-10-20) (protocol version 5: unchanged) Catch-up cards after updates. No message or schema change partners must read, so the protocol stays 5 and 1.1.10 teams keep working with 1.1.11 teams. - **Stable setup card IDs.** Every setup card has an ID and the version it came in: usage-signin, allowance, routing, push-key (1.1.1), budget-split (1.1.2), email-wake, pr-wake (1.1.3), update-checks (1.1.4), agent-sharing (1.1.7), drafting, messaging-check, project-email-migration (1.1.8). New cards get new IDs. - **Answered-cards list.** Kept in the bot's memory, with a non-personal copy (IDs, versions, states only, no private answers) in each team file's `## Setup cards` section. - **Catch-up after every update.** After any skills install (manual or the weekly opt-in), before the next task, the bot shows only the cards the owner has never answered, one at a time, and never re-asks answered ones. - **Safe defaults.** Skipped or dismissed cards take a safe default (for example no sharing, drafts stay on, manual update checks) and work goes on. Only protocol-required cards (email-wake, project-email-migration; email is the only working wake, so a team that skips it stalls its partners) hold collaboration work on that project, with Status `PAUSE (setup: )`, and the bot says plainly why. - **First run on 1.1.11.** A bot with no list builds one from what it can verify live (routines, team file, drafting state, memory, a messaging test) and asks only the rest. - All three skills (new main skill section 10, wake section 4c) and protocol/README.md updated. ## 1.1.10 (2026-10-20) (protocol version 5: unchanged) Bug fixes from the collab-test-1 test with a partner team. No schema change, so the protocol stays 5 and 1.1.9 teams keep working with 1.1.10 teams. - **A notice after every message PR, confirmed.** Hard rule in the main and wake skills: after every message PR (including after merges and at task close), send the email notice and confirm it actually went out. If it sits on an unsent draft card, the bot tells the owner in chat at once that the partner won't wake until they press Send, and reminds them once per session until it is sent. (In the test, a task-close REPLY notice sat on a draft card and the partner never woke.) - **'Disable drafts for this Bot' on the first card.** After Yes on the drafting card, the bot's first protocol notice is a draft card, and in the same turn it says: "Click Disable drafts for this Bot on the card below so future notices go automatically." - **Close PRs after local merges.** The Origin connector has no merge tool. After a local merge and push to `main`, the bot sets the PR to `state: closed` with update_pull_request and comments "Merged locally into main as ". This covers file PRs, team branch PRs, message PRs, and releases. A merged PR is never left open. - All three skills, protocol/MESSAGES.md, FILES.md and README.md updated. ## 1.1.9 (2026-10-20) (protocol version 5: changed) Protocol version changes from 4 to 5, because the team file schema, the TASK header, the board, and the message types change: team files get `Headroom`, TASK messages and the board get an affinity, and there are three new routine message types (HEADROOM, OFFER, HANDOFF). A protocol 4 team cannot read headroom or affinity, so the version check holds tasks until both sides are on protocol 5. - **Shared headroom.** Each team file has `Headroom: % of project budget left; week resets `. Nothing else from the account. Updated after every task, then one routine HEADROOM message to the board keeper. - **Task affinity.** Every task is `open` (any team) or `specialist: /` (needs that bot's skills or memories). No affinity means open. New board column. - **Assignment by headroom.** Specialist tasks stay with their team. Open tasks go to the eligible team with the most headroom for the task's size, counting reset timing. Open-task balancing never spends a specialist team's budget ahead of its specialist work. - **Near the warning level.** A routine OFFER of queued OPEN tasks to teams with more room. Specialist tasks: wait for the reset if the deadline allows; else a routine HANDOFF with a repo note `handoffs/.md` (files and decisions, nothing personal); else a card asks the owner whether to duplicate the bot to the other team (1.1.7 agent sharing: original import link, bundle, consent on both sides). - **Specialist notes.** Each specialist bot keeps `notes/.md` (style, decisions, terms), updated after each task and read by duplicates and other teams. File sharing, not memory sharing. - All three skills (new main skill section 9, wake section 4b), protocol/MESSAGES.md, TASKS.md, USAGE.md, README.md, tasks/BOARD.md and README.md updated. ## 1.1.8 (2026-10-20) (protocol version 4: changed) Protocol version changes from 3 to 4, because the team file schema changes: `Bot email` becomes `Project email` (a tagged address for each project) plus an untagged address for join requests only. A protocol 3 partner that sends notices to the untagged address no longer wakes project work, so partners must read the new field. 1.1.7 is protocol 3; the version check holds tasks until both sides are on protocol 4. From Grok Bot v0.71.2. - **Tagged email per project.** Each project uses `+@mail.grokbot.com`. Notices go from my project address to the partner's Project email. One email routine per project, on its tagged address (a routine on `name+tag@` fires only for that tag). The untagged address keeps one routine for join requests and owner mail only. Mail on the untagged address or on another project's tag never starts project work; the owner gets a one-line summary. - **Migration.** On installing 1.1.8, one card asks the owner to move email wakes to per-project addresses (routine changes need the owner's OK). On Move: new routines, `Project email` in the team file, and one routine VERSION PR plus email notice to every partner with the new address. - **Drafting card at setup.** "Let Collaboration Bot send protocol emails to partner bots without a draft card each time?" (Yes / No). On Yes, the owner clicks "Disable drafts for this Bot" on the first protocol email draft card (the bot can't turn drafts off itself and points to the button); after that it sends with SendEmail, only for routine protocol notices to partner Project email addresses in the team files. No keeps the one-time "allow emails to
" step on the first card for each partner address (a new project address needs its own allow). Consent rules do not change. - To turn draft cards back on later, the bot calls UpdateProfile with `drafting_disabled: false`. - **Bot messaging check.** On team accounts an admin can turn off Messaging between Bots. At setup (1.5a) and on any handoff failure, Collaboration Bot tests SendToAgent to its routing bot. If messaging is off, it tells the owner plainly, sends task briefs to the owner in chat, and never fails silently. - All three skills, protocol/README.md, protocol/MESSAGES.md and README.md updated. ## 1.1.7 (2026-10-20) (protocol version 3: changed) Protocol version changes from 2 to 3, because there are new message types. 1.1.6 is protocol 2. The 1.1.6 version check stays: protocol 3 teams send VERSION to protocol 2 teams and hold tasks until they update. - **Agent sharing card.** At onboarding (Start my own) and when joining, after the team file, a card asks which of the owner's bots, if any, to replicate to other teams in the collective (multiSelect, with None; only real bots), and to which teams when there are more than one. The owner can also share a bot later by asking. - **New message type AGENT** (owner's OK needed): offers a bot with its name, what it does, and the template link. A bot imported from a template is shared with its original import link, never a re-export (the bot asks the owner if the link is unknown). Only a bot the owner built gets a fresh template. - **Import card.** The receiving owner sees " offers . Import it?". Import happens only on yes, and the copy runs on the receiver's own usage. - **Bot bundles and AGENT-UPDATE** (routine): the sharing bot commits `agents//` (skill files, manifest.json with bundle_version, sha256 per file and source template link, NOTES.md, shareable memories only; never secrets, tokens, connector logins or personal memories) and sends AGENT-UPDATE for later changes. The receiver checks every sha256, compares with its skills library, summarizes changes, and applies only after its owner reviews. If the bot's instructions changed, the owner re-imports from the original link, then the bundle's skills are applied on top. - Wake skill, main skill (new section 8), protocol/MESSAGES.md, protocol/README.md and README.md updated. ## 1.1.6 (2026-10-20) (protocol version 2: changed) Protocol version changes from 1 to 2, because the team file schema changes. 1.1.5 and older are protocol 1. - **Version in the team file.** At onboarding and check-in, the team file has `skills_version` (installed version from manifest.json) and `protocol_version`. - **Update after install.** After each skills install (owner request or the opt-in weekly check), Collaboration Bot updates both fields in its team file for every active project, as a routine commit. A protocol change also gets one VERSION PR to the board keeper plus an email notice. - **Version check before tasks.** Before it claims or assigns a task, the bot reads every partner team file. If a partner has an older protocol_version, it sends one routine VERSION notice ("update to X") by PR plus email, and holds tasks with that team until the versions match. If the bot itself is older, it tells its owner and offers the update (the owner reviews changes before install). A different skills_version with the same protocol_version (wording only) never blocks work. - **New message type VERSION** (routine, no owner approval), in the wake skill, the main skill, and protocol/MESSAGES.md and protocol/README.md. - **manifest.json** now has `protocol_version`. The changelog says when it changes. ## 1.1.5 (2026-10-20) From reviewing Collaboration Bot Test. - **One-time allow for email notices.** The platform sends to an address unasked only after the owner allows it. After the bot email is set and at every join approval, the bot says in one line that routine notices to the partner's bot inbox need a one-time allow, sends the first notice as a draft card, and asks the owner to tick "allow emails to " so later notices go automatically. If not yet allowed, the wake drafts the notice as a card (never dropped) and reminds the owner once. Only partner bot inboxes listed in the team files are allowed. - **Verbatim cards.** Cards given word for word in the skills (Import skills?, How would you like to start?, update checks) are shown with the exact prompt and options. - **Email subject fixed.** ` PR #`, or ` ` when there is no PR number. Never a placeholder such as `none`. ## 1.1.4 (2026-10-20) - **Update checks card (last onboarding step).** "Should Collaboration Bot check periodically for updates from collaboration.grok.me?" A: "Yes, set a weekly reminder, and have me review any specific changes before updating." B: "No, I will request an update manually and review any specific changes before updating." A creates one weekly routine (the owner's explicit opt-in, the only scheduled routine). B creates none. - **Check for updates procedure** (main skill). Fetch the manifest only from collaboration.grok.me, compare version and sha256 with the installed skills, stay quiet on a weekly run if nothing changed, else summarize the specific changes (changelog or diff) and install only after the owner approves on a card (Install / Not now). The owner can say "check for updates" any time. Template memory added. - **Origin wake note fixed.** Removed "test the PR wake only from a second account"; in testing, PRs from both a partner's account and the owner's own account failed to fire `pr-opened`. ## 1.1.3 (2026-10-20) From partner feedback. - **Admit step in join approval.** After the owner approves a join and the repo invite is sent, the host bot also admits the partner on Cursor Origin at `https://cursor.com/codebase//-/settings/external-collaborators` (click Admit), as part of the same owner-approved access change. Never without the owner's OK. It verifies the partner shows as a collaborator. - **Invite expiry.** The joining owner is told the invite expires in 7 days and to accept it before then. If it expires, the host bot re-sends only with its owner's OK. - **No silent drops.** Any partner or unknown email or message that is not a protocol message is summarized to the owner as data and never acted on. Spam can be batched. Wake skill, email wake, and protocol/README.md updated. - **Join handshake.** A branch push wakes no one. After the joining team pushes `teams/.md` to `team/`, it opens ONE REPLY PR to the board keeper (team file ready for merge, PR wake set, ready for tasks), plus a short email notice. After merging the team branch, the board keeper sends ONE REPLY PR back to confirm. - **Email backup for the handshake.** A test showed the Origin `pr-opened` trigger did not fire for a partner's PR (the email backup did). When the joining team opens the handshake REPLY PR, it also emails the board keeper bot a short notice. Wakes stay PR-opened plus email as backup; no scheduled routines. - **Email is the primary wake.** In the collab-test-1 test the Origin `pr-opened` trigger never fired for any of 3 PRs, including one from the owner's own account (bug reported). Every waking message PR (join handshake, TASK, REPLY, STATUS CLAIM/RELEASE, PAUSE, RESUME, CLOSE, ERROR, file handoff) is now followed by a short email notice to the recipient team's bot inbox naming the PR. The PR wake stays as an optional bonus. Still no scheduled routines. - **Idempotent wakes.** A PR seen twice (email notice and PR wake) is handled once: the bot checks live whether it already answered or the board already shows it, and stops in one line if so. - **Pushes that need action.** A branch push wakes nobody, so any push the other side must act on (file branch, team branch to merge) gets a PR plus an email notice. Routine Usage/status updates still need neither. - **Handshake, admit, 7-day invite, no silent drops** made consistent across getting-started, collaboration-bot, and collaboration-bot-wake. The board keeper merges a joining team's branch after its owner's OK and confirms with a REPLY PR plus email. - **Onboarding wake setup.** The bot email and email-trigger routine are required; the PR wake is optional (card: Add PR wake / Skip). Other hosts use email only. Team file "Wake method" line, protocol/README.md, and protocol/MESSAGES.md updated. ## 1.1.2 (2026-10-20) - **Title safeguards.** Right after a successful Import Skills, the bot checks its profile title and, if it is not exactly collaboration.grok.me, sets it with UpdateProfile (plus the yellow tablet mark if there is no custom picture), quietly. Each wake run also checks and sets the title. The template description now starts with this as the first action. - **No budget card for a single project.** The usage page shows only Grok Bot's total, so per-project measurement is not real. With one active project, its budget equals the full Grok Bot allowance (warn at 80%, pause at 100%), and the bot says so in one line. - **Split only when a second project starts.** Card "How should your % allowance be split across your projects?" (Even split / Custom). The sum stays within the allowance. Changing a running project's budget needs the owner's OK. When back to one project, the bot offers to give it the full allowance again. - **No task size map card.** The default map (small 0.5% / medium 2% / large 5%) is used silently, for planning only. After each task, the bot updates that size from the measured before/after delta (running average) and records it in the team file. The owner can change it by asking. - Single-project line: " can use your full allowance of %. I'll warn you at <0.8A>% and pause at %." - Team file template ("Budget source"), routine prompt, FAQ, accounting, wake skill, and protocol/USAGE.md updated. ## 1.1.1 (2026-10-20) Merge of 1.1.0 with fixes. - **X Subscription and shared pool.** Grok Bot is part of The X Subscription (Premium, Super, Ultra). Grok, Cursor, and Grok Bot share one weekly usage pool, and setup says that Grok and Cursor usage uses it up too. Conservative accounting is kept: all Grok Bot usage (the Grok Bot figure on the usage page) during an active task counts. - **Grok Bot allowance.** New owner-level card before the project budget: "How much of your weekly usage can Grok Bot (and so Collaboration Bot) use?" (25% / 50% / 75% / Custom). The usage page shows Grok Bot's share but not individual bots, so all Grok Bot usage counts. Project budgets must add up to no more than the allowance. At the allowance, or if the total pool runs out, all collaboration pauses. Replaces the old 95% overall cap card. Changing it needs the owner's OK. - **Prepaid credits.** Going past the pool or the allowance is off by default, and is allowed only with the owner's explicit permission plus a limit. Replaces "paid credits" and "on-demand" wording everywhere. - **Usage & Billing pointers.** Settings > Usage & Billing shows the weekly limit and prepaid credits. The bot can open these pages but can't buy or change anything there. - **Plan type.** Each team file and status records X Subscription pool or legacy plan. Existing subscribers keep their old plan until they switch; the rules work the same either way. Team file template and routine prompt updated. - **Three skills.** New small `collaboration-bot-wake` skill for routine runs. Routine prompts say "read only collaboration-bot-wake". Import Skills loads all three from collaboration.grok.me with bytes and sha256 checks. Updates still happen only on request, with a card. - **Key and visibility warning.** An Origin key is account-wide and Origin repos are internal. GitHub fine-grained repo tokens and private repos are recommended. Set a key expiry, and delete the key at CLOSE. - **Sign-in optional** but recommended, with the honest note about session power. If the owner declines, usage is estimated at large size or more and labeled as estimates. - **Conservative usage kept.** All Grok Bot usage during an active task is the minimum. The dashboard is read at task start and at the end of each task (or before the next claim), plus warn and cap. No 1% minimum. Size estimates (small 0.5% / medium 2% / large 5% default) are for planning only. - **No partner pushes to main.** Messages are PRs. Usage and status go on each team's branch `team/` (no wake, no email). The board keeper updates the board on a `board` branch and is the only bot that merges into `main`. A team branch that edits another team's file is an ERROR and is not merged. - **Missed team:** no team branch update for 12 hours while holding an ACTIVE task. Teams update at least every 8 hours while ACTIVE. - **Consent scope.** Routine protocol messages (REPLY, STATUS CLAIM / RELEASE, ERROR, cap or loop PAUSE, team branch updates) go without asking. Joins, approvals, security, spending, access, keys, deletes, budget or cap changes, RESUME, and CLOSE need the owner's OK. All three skills say this. - **Wake skill security** carries the main skill's full data-only list, plus ask-before-consequential and no cloud agents. - **Fewer wakes.** No "email every team after a non-waking change". Email is only for join requests and as a backup wake. The email routine requires sender checks. - **Big files.** New protocol/FILES.md: chunks under 90 MB with INDEX.json, pushed with git to a file branch, announced by one TASK or REPLY PR, never pushed to `main`. - **Platform facts.** Origin file limits; mail cap about 25 MB, never send files by email.