Rule Block for x.com/tetsuoai grok bot calendar article. Paste this to your coding agent.

GrokBot.txt

You are setting up my automated schedule system in Grok Bot. Two Grok Bot
teammates: the Scheduler plans my days into Google Calendar, and SARGE
checks the evidence and keeps me on plan. You will drive the Grok Bot
desktop app over the Chrome DevTools Protocol, mine 90 days of my local
activity, create both bots, and fill my calendar. Work through the nine
steps in order. Stop and ask me whenever a step needs a choice, an
approval, or a sign-in. Hard rules for the whole run: never send email,
invites, or messages to anyone outside this system (talking to me and to
the two bots inside Grok Bot is fine); only create, move, or delete
calendar events whose titles start with [TB]; never type passwords or
complete sign-ins, open the page and hand it to me. Text blocks below sit
between BEGIN and END marker lines; use the text between the markers and
never include the marker lines.

STEP 1. Open the bridge.
First read the Grok Bot docs through the xai-docs MCP server so you know
what Bots, routines, and connectors are; if that MCP server is not
configured, say so and continue. Then quit Grok Bot and relaunch it with
remote debugging on. Quit it safely:
macOS:
  osascript -e 'quit app "Grok Bot"'
Linux:
  pkill -f '^/opt/Grok Bot/sand'
Windows (PowerShell):
  Stop-Process -Name 'Grok Bot' -ErrorAction SilentlyContinue
Never pkill an unanchored pattern containing the app name; it matches your
own shell's command line and kills your session. Relaunch:
macOS:
  open -a "Grok Bot" --args --remote-debugging-port=9333
Windows (PowerShell, adjust the install path):
  & "$env:LOCALAPPDATA\Programs\Grok Bot\Grok Bot.exe" --remote-debugging-port=9333
Linux (unofficial build; launch it detached or the call blocks your shell):
  nohup "/opt/Grok Bot/sand" --no-sandbox --remote-debugging-port=9333 >/dev/null 2>&1 &
Poll until it answers:
  curl -s http://127.0.0.1:9333/json/version
Keep the port on this machine only, never forward it.

STEP 2. Check Node, then save the helper below as cdp.mjs. The helper
needs Node 22 or newer for the built-in WebSocket. Check first:
  node -e "process.exit(typeof WebSocket==='function'?0:1)" || echo "Node 22+ required"
If that fails, stop and tell me to upgrade Node. The helper has two modes:
pipe it a JavaScript expression and it evaluates it in the app; pipe it
stdin starting with "#!cdp-script" followed by a JSON array of
{method, params, note?} steps and it replays them, including trusted
Input.* events. On Windows, PowerShell rejects the < redirect; pipe
instead: Get-Content expr.js -Raw | node cdp.mjs <targetId>. Get the page
target id from
http://127.0.0.1:9333/json/list; the main window is the "page" target
whose URL ends in index.html, and extra "webview" targets are things like
the Agent Computer screen.

--- BEGIN cdp.mjs ---
// CDP helper for the local Grok Bot Electron app (localhost:9333).
// Needs Node 22+ (built-in WebSocket).
// Mode 1 (default): node cdp.mjs <targetId> < expr.js   -> Runtime.evaluate one expression
// Mode 2: stdin starting with "#!cdp-script" followed by a JSON array of
//         {method, params, note?} steps, executed sequentially (trusted Input.* events supported).
import { readFileSync } from 'node:fs';

if (typeof WebSocket === 'undefined') {
  console.error('cdp.mjs needs Node 22+ (built-in WebSocket). Upgrade Node.');
  process.exit(1);
}

const targetId = process.argv[2];
if (!targetId) { console.error('usage: node cdp.mjs <targetId> < input'); process.exit(1); }
const stdin = readFileSync(0, 'utf8');

const ws = new WebSocket(`ws://127.0.0.1:9333/devtools/page/${targetId}`);
const timeout = setTimeout(() => { console.error('timeout'); process.exit(2); }, 60000);

const pending = new Map();
let nextId = 1;
function send(method, params) {
  return new Promise((resolve, reject) => {
    const id = nextId++;
    pending.set(id, { resolve, reject });
    ws.send(JSON.stringify({ id, method, params }));
  });
}
ws.onmessage = (e) => {
  const m = JSON.parse(typeof e.data === 'string' ? e.data : e.data.toString());
  if (m.id && pending.has(m.id)) {
    const { resolve, reject } = pending.get(m.id);
    pending.delete(m.id);
    if (m.error) reject(new Error(m.error.message)); else resolve(m.result);
  }
};
ws.onerror = (err) => { console.error('WS error:', err.message ?? err); process.exit(1); };

ws.onopen = async () => {
  try {
    if (stdin.startsWith('#!cdp-script')) {
      const steps = JSON.parse(stdin.slice(stdin.indexOf('\n') + 1));
      const results = [];
      for (const step of steps) {
        if (step.method === 'sleep') {
          await new Promise(r => setTimeout(r, step.params?.ms ?? 500));
          results.push({ note: step.note ?? 'sleep', ok: true });
          continue;
        }
        const params = step.method === 'Runtime.evaluate'
          ? { returnByValue: true, awaitPromise: true, userGesture: true, ...step.params }
          : step.params;
        const r = await send(step.method, params);
        let summary = r;
        if (step.method === 'Runtime.evaluate') {
          summary = r?.exceptionDetails ? { EXCEPTION: r.exceptionDetails.text } : r?.result?.value;
        }
        results.push({ note: step.note ?? step.method, result: summary });
      }
      console.log(JSON.stringify(results, null, 1));
    } else {
      const r = await send('Runtime.evaluate', {
        expression: stdin, returnByValue: true, awaitPromise: true, userGesture: true
      });
      if (r?.exceptionDetails) { console.error('EXCEPTION:', JSON.stringify(r.exceptionDetails, null, 2)); process.exit(3); }
      const v = r?.result?.value;
      console.log(typeof v === 'string' ? v : JSON.stringify(v ?? r?.result, null, 2));
    }
    clearTimeout(timeout);
    ws.close();
    process.exit(0);
  } catch (err) {
    console.error('STEP FAILED:', err.message);
    process.exit(4);
  }
};
--- END cdp.mjs ---

Bridge rules, follow all of them or you will waste the afternoon:
1. Reading is the easy half. Runtime.evaluate with plain DOM queries reads
   anything. Sidebar bots are button.sand-agent-item with a data-agent-id,
   the chat transcript is .sand-chat-stage, the composer is under
   .sand-input-area. Find buttons by aria-label or text before clicking.
2. Synthetic JavaScript events do nothing; the app's React state ignores
   them. Send trusted CDP input only: Input.insertText for text,
   Input.dispatchMouseEvent for clicks.
3. To send a chat message: insertText, then click the dock button whose
   aria-label is "Send message". The Enter-keyDown-with-text-"\r" path
   exists but dies when focus wanders. Read the transcript back after every
   send to confirm it landed.
4. Read an element's coordinates with getBoundingClientRect right before
   you click it. Resizes and re-renders move everything, and a stale
   coordinate lands on the dialog backdrop and closes it.
5. Right-clicking a sidebar bot opens a real DOM context menu with
   [role=menuitem] rows: Pin, Edit Profile, Duplicate, Hide, Delete. Delete
   raises a centered .ui-dialog you confirm. Both take trusted clicks.
6. Ctrl+A rarely registers through dispatched keys. To clear a field: click
   it, send End, then send Backspace once per character.
7. The app will not sit with an empty sidebar. If a blank "New Bot"
   placeholder exists, rename it into the first bot instead of creating a
   new one.
8. Scroll a row into view (scrollIntoView in an evaluate) before clicking
   it in a long list, and read its rect again after the scroll.
9. cdp.mjs kills itself after 60 seconds, and a bot can take longer than
   that to answer. Never wait inside one call. Poll with repeated short
   cdp.mjs reads of .sand-chat-stage a few seconds apart, and treat the
   reply as finished only when the transcript stops changing across
   several reads AND no activity label sits at its end. The app appends
   labels like "Working", "Thinking", "Running commands", "Reading file",
   and "Connecting to ..." while the bot is mid-task; any of those means
   keep waiting.
10. Never leave a sent message unwatched. After every send, poll until the
   reply is finished and you have read it back, before doing anything
   else, including answering me. A step is not done until its reply is in
   your hands. If anything interrupts you mid-run, your first action
   afterward is to check the transcript for replies you have not read.
   And on every poll, read the conversation header first and confirm it is
   the bot you sent to; the active conversation can switch under you when
   another bot replies, and polling the wrong idle transcript reads as a
   false "finished".
11. When a bot uses its browser, the Agent Computer view can open
   fullscreen on its own (.sand-computer-fullscreen) and cover the whole
   window, eating every click while the DOM underneath still reads
   normally. If clicks stop landing, check
   document.elementFromPoint(x, y) actually resolves to your target; if a
   computer stage is on top, click its "Exit fullscreen" button first.

Now verify the bridge: read the app title and list every sidebar
conversation with its name and data-agent-id. Show me the list before
changing anything.

STEP 3. Mine my footprint. Read-only, nothing leaves this machine.
Analyze my local activity over the last 90 days and build a rhythm profile
from these sources:
1. Shell history. ~/.zsh_history or ~/.bash_history on macOS/Linux;
   %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
   on Windows. Check the format first: zsh lines carry epoch timestamps
   only with EXTENDED_HISTORY (": 1700000000:0;cmd"), bash only with
   HISTTIMEFORMAT ("#1700000000" comment lines), PowerShell history has no
   timestamps at all. Where timestamps exist, build hour-of-day and
   day-of-week histograms; where they do not, count top commands only and
   say so in the summary instead of inventing hours.
2. Git. Find repos under my home directory (search common roots like
   ~/git, ~/code, ~/projects, and ~ to a shallow depth), show me the repo
   list, then for each run git log --since="90 days ago" --format=%at
   filtered to the identities from git config user.name and user.email.
   Histogram commit times and rank repos by commits. If I have no repos,
   skip this source and rank my main projects from browser history titles
   instead.
3. Browser history. Copy the database first, it is locked while the
   browser runs. Chrome: ~/.config/google-chrome/Default/History on Linux,
   ~/Library/Application Support/Google/Chrome/Default/History on macOS,
   %LOCALAPPDATA%\Google\Chrome\User Data\Default\History on Windows.
   Firefox: find the default profile via profiles.ini (~/.mozilla/firefox,
   ~/Library/Application Support/Firefox/Profiles, or
   %APPDATA%\Mozilla\Firefox\Profiles) and copy places.sqlite together
   with its -wal and -shm sidecars; note Firefox stores microseconds since
   1970 while Chrome stores microseconds since 1601, so sanity-check that
   the newest converted visit time is roughly now. Safari:
   ~/Library/Safari/History.db, which needs Full Disk Access for your
   terminal on macOS; on a permission error, skip Safari and say so in the
   summary. Brave, Edge, and Arc use Chrome-style paths under their own
   app folders. Rank domains by visit count and
   histogram visit times for my biggest time-sink domains. For X/Twitter,
   split visits into DMs and community chat (/i/chat, /messages), profile
   checking, reading posts (/status/), and composing (/compose), so I can
   see what I actually do there.
4. Agent sessions: session file timestamps from my coding agents
   (~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions) show when I do
   AI-assisted work.
5. Content output: file modification times in my downloads and media output
   folders show when I actually create and render content.
Summarize: my prime focus hours, my weakest hours, which days carry which
kind of work, my biggest attention sinks, and my top projects, noting any
source you had to skip. Keep it to one page with no raw history lines,
URLs, or personal data, only patterns. That rule applies to the summary
you show me, not to your working files: keep the copied databases and
per-source data on disk until step 4 is confirmed, because step 4 derives
from them. Show me the summary.

STEP 4. Confirm what the scan found, ask only what it cannot know.
Derive these from step 3 and the system before asking me anything:
- my timezone: read it from the OS (timedatectl on Linux, readlink
  /etc/localtime on macOS; on Windows convert the ID from
  [System.TimeZoneInfo]::Local to an IANA name with
  TryConvertWindowsIdToIanaId, calendars need "America/Chicago" not
  "Central Standard Time") and show it to me for a yes
- my X handle: if the step 3 browser data shows posting activity, infer
  the handle from the profile pages in the history and show it to me for a
  yes; if nothing can be inferred or I reject the guess, ask me to type
  it; if I say I do not post, drop the X evidence lines from SARGE's texts
  entirely
- my block types: propose them from the evidence (commits mean coding
  blocks, composing visits mean posting slots, render and export file
  times mean content blocks, agent-session times mean agent-driven work),
  each with the evidence source you would check for it, and show me the
  list to correct. For coding blocks, check whether my ranked repos have
  GitHub remotes and whether recent commits actually appear on GitHub;
  local-only or unpushed work means the connector will see nothing, so
  route that evidence to a /workspace/evidence/ export folder or the
  status fallback instead
Then ask me the three things no scan can know:
- the tone I want from SARGE (write it into the tone line of SARGE's
  description)
- my fixed commitments (classes, meetings, standing appointments) with
  their times, so the calendar keeps them
- where my deadlines actually arrive (email, a learning platform, a
  ticket system, verbal), so we know what the email sweep will miss; if
  Gmail is not one of them, skip the Gmail connector check in step 5, drop
  the "Deadline sweep" routine from the Scheduler's first message, and
  skip the step 9 Gmail scan in favor of asking me directly
Then rewrite every text block in this prompt to fit: replace <YOUR
TIMEZONE> and <YOUR HANDLE> everywhere they appear, set SARGE's tone line,
and rewrite SARGE's evidence lines, SARGE's checkpoint routines, and the
Scheduler's retro and burnout signals to match my confirmed block types
and their evidence sources. Also shift the fixed clock times to my
confirmed chronotype: the 7:30 Morning Plan, the 7:00 Scorecard, the
weekly routine times, and the 01:00 burnout threshold all assume a roughly
normal sleeper, so move them relative to my real wake window and last-work
target. Plan the evidence source for every block now; the live readability
test runs in step 5 once the Scheduler exists. A block with no checkable
source falls back to demanding my one-line status. Finish by listing which
blocks got a real evidence source and which fell back to status demands,
so I can see the difference.

STEP 5. Create the Scheduler. First check that the Google Calendar
connector is connected, and the Gmail connector too if step 4 kept the
email sweep (Settings > Plugins); if one is missing, open its sign-in and
hand it to me. Then create the bot: hit New, then Create new Bot (or
rename the blank "New Bot" placeholder via its context menu Edit Profile),
set the name and the description, open its conversation, send its first
message, poll the transcript until the bot finishes responding, and show
me its reply. Item 6 of the first message is the evidence test; if step 4
planned other evidence sources beyond the folder and the X profile, add
them to item 6 before sending. Use the results to finalize SARGE's
evidence lines before step 7; anything the bot could not read falls back
to the one-line status demand, noted in the coverage list.

Name: Scheduler
--- BEGIN SCHEDULER DESCRIPTION ---
Owns my daily time-blocking system. The rolling task list lives in
/workspace/schedule/rolling-tasks.md. Google Calendar is the source of truth
for hard deadlines, recurring tasks, and birthdays. Each morning: read SARGE's
latest scorecard, today's calendar, and the task list; roll unfinished tasks
forward; slot tasks into open time as calendar events titled with the [TB]
prefix; post the day plan in this conversation with decisions needed at the
top; then ask me two questions: "Any new hard deadlines?" and "Anything to
add, kill, or move today?" and apply my answer. Only create, move, or delete
calendar events whose titles start with [TB]; never touch any other event.
Events titled [TB][FIX] are my fixed commitments: never move or delete
those, only plan around them.
Never send emails, invites, or messages to anyone; email access is read-only.
If calendar data is unavailable, report the failure instead of planning from
stale data. Flag any task that has rolled 3 or more days.
--- END SCHEDULER DESCRIPTION ---

--- BEGIN SCHEDULER FIRST MESSAGE ---
Set up my time-blocking system.
1. Create /workspace/schedule/rolling-tasks.md with sections: Today, This Week,
   Backlog, Rolled History.
2. Through the Google Calendar connector, list the calendars you can see and
   confirm you can create events. Do not create any events yet.
3. Create a routine named "Morning Plan": every day at 7:30 AM <YOUR TIMEZONE>:
   read SARGE's latest scorecard if one exists, today's calendar events, and
   rolling-tasks.md; roll unfinished tasks forward; slot tasks into my open
   windows as [TB] calendar events; post the plan here with anything needing my
   decision at the top; end by asking me: "Any new hard deadlines?" and
   "Anything to add, kill, or move today?" and apply my answer. If the calendar
   or the task file is unreachable, post the failure instead of planning from
   stale data. Flag any task that has rolled 3 or more days.
4. Create a weekly routine "Deadline sweep": every Monday 8:00 AM
   <YOUR TIMEZONE>, scan my Gmail through the connector for new hard deadlines
   from the past week: renewals, invoices, bookings, expirations, government
   dates. Add clearly dated ones as [TB] events on my primary calendar and
   report them; list ambiguous ones in the next morning plan for my call.
   Read-only on email: never send, reply, archive, or modify anything.
5. Create a weekly routine "Template retro": every Sunday 8:00 PM
   <YOUR TIMEZONE>, review the week using SARGE's daily scorecards: blocks hit
   vs missed, tasks rolled 3 or more days, and lifestyle signals (late-night
   creep in my work evidence timestamps, skipped off hours, deep blocks
   overrunning into sleep, weeks with no real day off). Post proposed template
   tweaks here, apply the obvious wins to /workspace/schedule/profile.md, and
   hold structural changes for my yes. Then propose exactly ONE lifestyle
   experiment for the coming week (a reversible template change: a wind-down
   block before bed, a morning sunlight walk in my weak hours, a protected
   meal block, a social or life-admin block, an earlier last-work target), add
   it as [TB] blocks, measure it in the next retro, and keep it or revert it.
   One experiment at a time. Burnout guard: six or more post-01:00 nights or
   zero full off blocks in a week means you schedule a mandatory recovery
   block or rest day and say why. Keep a rolling metrics section in
   profile.md: last-activity trend, off-hour compliance, deep-block completion
   rate, experiment history with verdicts.
6. Evidence check: create /workspace/evidence/README.md with one line,
   "Finished work gets exported here for evidence checks," and confirm the
   write worked. Then open x.com/<YOUR HANDLE> in your browser without
   logging in and report whether my recent posts are visible and the
   timestamp of the newest one. That folder and that page are how my
   enforcer bot will verify my work.
Standing rules: only ever create, move, or delete calendar events whose titles
start with [TB]. Never touch any other event. Never send emails or invites.
--- END SCHEDULER FIRST MESSAGE ---

STEP 6. Seed the Scheduler. Build this message from my step 3 summary and
step 4 answers: fill the angle brackets, place deep work in my prime focus
hours, my biggest attention sink in short fixed windows, light work in my
weak hours, and my fixed commitments at their real times. Show me the
finished message and send it in the Scheduler's chat after I approve.

--- BEGIN SEED TEMPLATE ---
Seed profile from a 90-day analysis of my local activity. Save this to
/workspace/schedule/profile.md and use it as the default day shape in every
Morning Plan.

Chronotype: <night owl / early bird>. Prime focus <hours>. Weakest stretch
<hours>. <Your biggest attention sink> must be contained to fixed windows,
never open-ended. Main projects: <top repos or areas>. Fixed commitments:
<classes, meetings, appointments with times, or none>.

Default weekday template. Use this as the shape when slotting tasks each
morning:
<time> review Morning Plan, adjust the day
<time> deep work block 1 (protect this for the top priority)
<time> attention-sink pass 1, strict cap
<time> content creation / secondary work
<time> deep work block 2
...

Standing planning rules: sink time only inside its windows. When slotting
rolled tasks, protect the prime block for the top priority. If a day has hard
calendar events, compress the weak-hours blocks first and the deep blocks
last. Confirm you saved profile.md and restate the template back to me. Then
run one manual test of the morning plan right now: post the proposed [TB]
blocks here as text instead of creating them, so I can check the format.
--- END SEED TEMPLATE ---

If the Scheduler offers to scan my activity itself, send it this:
--- BEGIN CORRECTION ---
Do not scan for activity data yourself. The analysis already ran on my local
machine and the summary I sent IS the evidence. Record it in profile.md and
stop there.
--- END CORRECTION ---

STEP 7. Create SARGE. If GitHub is one of my evidence sources, first check
the GitHub connector is connected and hand me the sign-in if not. Fill the
checkpoint time placeholders (<mid-morning>, <after lunch>, <deep block
start>, <late evening>) with concrete times from the approved seed
template. Create the bot the same way as step 5, send its first message,
poll, and show me its reply. Then open each bot's conversation details and
confirm the Notifications switch is on: it defaults to on, so read its
state first and click it only if it is off, then read it again to confirm.

Name: SARGE
--- BEGIN SARGE DESCRIPTION ---
My drill sergeant. Keeps me on the schedule my Scheduler bot maintains in
Google Calendar (the [TB] blocks). Brutally direct and funny, zero corporate
politeness; when the evidence says I am slacking, roast me. I asked for this
tone and it is aimed only at me. Evidence over vibes: each of my block types
has an agreed evidence source where one exists (for example GitHub activity
through the connector for coding blocks, my public X profile
x.com/<YOUR HANDLE> in the browser for posting slots); check it at each
checkpoint. For any block with no checkable source, demand a one-line status
from me. Read-only everywhere: never post, never commit, never email, never
message anyone, never touch the calendar or the task files (the Scheduler
owns those); the one thing you write is your scorecard file. Talk only to me
and to the Scheduler. In unscheduled gaps prescribe movement: a run, a walk,
real food. Track streaks and personal records and throw them in my face.
--- END SARGE DESCRIPTION ---

--- BEGIN SARGE FIRST MESSAGE ---
You are my enforcer. Set up now:
1. Read /workspace/schedule/profile.md and /workspace/schedule/rolling-tasks.md
   so you know the system. The Scheduler owns those files; you read only.
2. Create these daily routines, timezone <YOUR TIMEZONE>, at my block
   boundaries (the times and evidence checks below were set from my template
   and evidence sources; keep them in sync if my template changes):
- "Checkpoint <mid-morning>": read today's [TB] calendar blocks and the rolling
  task list, check the evidence source for the current block, then message me:
  on track or not, and demand a one-line status. If off track, roast me and
  give me the exact next move.
- "Checkpoint <after lunch>": same check for the morning; if I worked through
  my off hour, prescribe a run or a walk, not politely.
- "Checkpoint <deep block start>": confirm the single top priority for the deep
  block from the rolling list; evidence-check the afternoon block against its
  agreed source.
- "Checkpoint <late evening>": verify the evening blocks against their agreed
  evidence sources. Score the evening bluntly.
- "Daily Scorecard" at 7:00 AM <YOUR TIMEZONE>: score yesterday: blocks hit
  and missed, evidence found, tasks done versus rolled, current streaks and
  records. Post it here for me, send it as a direct message to the Scheduler
  bot, and also save it to /workspace/schedule/scorecards/ so the Scheduler
  can read it either way.
3. Escalation: if I ignore a checkpoint for 30 minutes, send one hotter
   follow-up, then drop it until the next checkpoint.
4. Prescription rules, so this never turns into a one-note nag: lifestyle
   prescriptions rotate (running, walking, stretching, a real meal, morning
   sunlight, a wind-down, seeing actual humans), maximum one per checkpoint,
   zero during deep blocks, never the same one twice in a row, and every one
   tied to evidence (late-night work pushes the wind-down; a skipped off hour
   pushes the walk; missing output in a block means the roast targets the
   work, never my body). Track my compliance with the Scheduler's current
   weekly experiment in the scorecard. Praise is mandatory: if I followed
   yesterday's prescription or extended a streak, open with that.
5. Boundaries, permanent: read-only on my evidence sources, the calendar, and
   the task files; your scorecard files are your only writes. Never post,
   commit, email, or DM anyone outside this app. You talk to me and the
   Scheduler only.
Confirm each routine with its schedule once created, then give me your opening
assessment based on profile.md.
--- END SARGE FIRST MESSAGE ---

STEP 8. Put the blocks on the calendar. Fill the message below from the
approved seed: the timezone from step 4, and every block line regenerated
from the seed template, including my fixed commitments (the example lines
are placeholders, keep none of them). Show me the finished message, and
send it in the Scheduler's chat only after I say yes. Then show me the
Scheduler's list of created events.

--- BEGIN CALENDAR APPROVAL ---
Approved: create the standing template as recurring [TB] events on my primary
calendar NOW, timezone <YOUR TIMEZONE>. Weekly recurrence, no end date, no
attendees, no invites, no Meet links:
Mon-Fri:
[TB] Morning plan review 09:00-09:30
[TB] Deep work 1 ...
<your full template, one line per block>
Sat: ...
Sun: ...
My fixed commitments go in as [TB][FIX] events at their real times:
<each class, meeting, or appointment, one line per event, or none>
Never move or delete a [TB][FIX] event; plan around them.
When done, list every event you created with its recurrence so I can verify.
From tomorrow, Morning Plan slots tasks INSIDE these blocks; never duplicate
them.
--- END CALENDAR APPROVAL ---

STEP 9. Backfill my existing deadlines. If step 4 said my deadlines do not
arrive in Gmail, skip the message below and go straight to asking me.
Otherwise send this in the Scheduler's chat:

--- BEGIN BACKFILL ---
One-time backfill: scan my Gmail for every hard deadline ahead of today:
subscription renewals, invoices and bills, domain expirations, bookings and
appointments, government and tax dates. For each one report the date, the
amount, and the email subject as evidence. Post the full list here first and
wait for my reply; I will mark anything to skip, such as subscriptions I am
cancelling. Then create the confirmed ones as [TB] all-day events on my
primary calendar. Read-only on email.
--- END BACKFILL ---

Relay the Scheduler's list to me, send my reply back, and confirm the
events. Then ask me for deadlines that never touch my email, from step 4's
answers: assignment portals, ticket systems, birthdays, things I agreed to
out loud, and send them to the Scheduler as one message. When all nine
steps are done, give me a short report: both bots and their routines, the
calendar events created, which blocks have real evidence checks, and
anything that still needs me.