How to Run a Grokbot Specialist Team Across Notion and Slack

Key takeaways

Give each Grokbot one job. A Slack bot that only handles mentions, a PM bot that only updates Notion, and an engineer bot that only watches the repo beat one generalist you have to re-prompt all day.
Make Notion the source of truth, then tell every bot to keep it current. Checklists and Kanban are both fine; the speakers flipped views on the same database.
Wire routines to events, not to your memory. Slack @mentions and DMs, GitHub PR opens and changes, and cards moving to In Progress are enough to keep work moving.
When you feel like you are micromanaging individual prompts, stop and have Dr. Eggbot update the whole team at once.
Share context on purpose: one canonical doc, Slack messages your teammates’ bots can hear, and workspace permissions so agents can actually open the page.
Park 3D, pixel art, ads marketplaces, and sound as side quests. Ship the web path first; scrap prototypes you do not like.
Cursor projects plus potato mode (full autopilot) are how the speakers ran many cloud agents in parallel, including verification. Early on they treated failing tests as drag, not quality.
Humans still preview Slack drafts, share docs, slow down overbuilt data models, and decide what merges.

Who this is for (and who should skip it)

This is for a founder, operator, marketer, or ops lead on a small shipping team that already lives in Notion, Slack, and GitHub, and is willing to connect those tools to Grokbot. It assumes you can install a Slack plugin, hook a repo, and let Cursor Cloud agents touch code. The worked example is a game studio spinning up a web client and server, but the operating system is the bot team, not the game.

Skip it if you want a single chat window, you will not share a source-of-truth doc, or you need proof of hours saved. The speakers did not give those numbers. Also skip a hard-launch ads marketplace or a 3D client if you do not have the core product playable yet; they explicitly kept those off the critical path.

Give each Grokbot one job

The problem is not “we need more AI.” It is that work is scattered: people dump tasks into Notion, two people merge the same repo from different sides, and every agent waits for the next pasted instruction. The speakers’ fix was a named roster with specialists, not a smarter blob.

Prepare a short list of recurring jobs before you spawn anything. Theirs looked like this: a chief of staff to turn conversation into a to-do list; a personal PM bot whose only job is updating Notion; a Slack bot whose only job is @mentions (later DMs); a founding engineer watching PRs; a game-design researcher; throwaway prototype bots for frontend and audio. Fun names and labels were not decoration. They used them so a human can see Glow vs Crit vs Ping at a glance.

Ask Dr. Eggbot to create the bot and state the job in one breath. Tweak instructions after it exists. Two people even created the same Slack bot in voice mode at the same time; both landed on the name Ping. The speaker’s read: Dr. Eggbot is strong at naming, and a multi-bot creation flow is worth repeating.

I like to have specialists for my bots.

Good looks like this: you can point at a card, a PR, or a Slack ping and know which bot owns it. Failure looks like one agent doing research, tickets, code, and comms, which is when you start repeating yourself.

Make Notion the source of truth your bots actually update

You are trying to get a shared board that humans and bots burn down together, including milestones, not a graveyard of dumped bullets. Prepare by putting the real work in one Notion space and deciding, out loud, that this doc is canonical.

Steps the speakers used:

Ask a chief of staff bot for a Notion to-do list and to keep an eye on it while the team talks.
Capture tasks as they come up (backend shipped, client kept on web, ads thinking, 3D as a non-blocking side quest) and have the bot write them in.
Let the bot structure the work. Theirs took the liberty of making a page per task inside a Notion database.
Pick a view you will actually look at. One speaker switches between checklists (five things in your head) and Kanban (Not started / Up next / In progress / Done). Notion is useful here because the same database can flip views.
Optional but powerful: a bot that listens to the board. When a human moves a card to In progress, that bot starts the work.
Tell Dr. Eggbot to tell the whole team that Notion is the source of truth and every bot should keep it updated. Remind engineer bots to check off cards when PRs land, not only to notify you.

Good: cards flip from Up next to In progress to Done while you are doing something else; PRs waiting on rebase show up as board state. Failure: the page is still private, so a teammate’s bot cannot read it; bots invent extra rollup docs while the Kanban stays stale; you never tell the engineer to check the box.

If a bot cannot open a page, do not prompt harder. Change sharing so it lives in the shared space, then retry.

Connect Slack and GitHub so Grokbot routines run without extra prompts

Notion holds state. Slack and GitHub are how the team finds out that state changed. The job of this phase is to stop being the human router.

Prepare integrations, and do the secret-heavy clicks off a shared screen. The speakers installed a Slack plugin, connected Slack, and tied GitHub so a founding engineer bot (Bake) got notified whenever a PR opened or changed. That mattered because they were dual-merging: one person on the client, one on the server.

Stand up a Slack specialist with a narrow first version: listen for @mentions of your username and process them (task completed, pointer to the Notion progress doc). Then extend it. One speaker had to be told to watch DMs, not only channel mentions. If you start a workflow you want, that is the moment to have Dr. Eggbot fix all of your agents, not to write a one-off prompt forever.

Sending from a bot is not fire-and-forget. The Slack feature they liked was a draft you preview, then send. Use that when the chief of staff needs to ping the team that the Kanban exists.

Routines are the underrated layer. Daily routines exist, but so do event subscriptions. Slack messages are the obvious one. For a more factory-like setup, the speaker pointed at Datadog or Sentry: backend is down, spin bots to investigate and triage. Same pattern as “card moved to In progress, start work.”

Good: your Ping bot’s routine list shows “when @mentioned anywhere in Slack” plus DMs; Bake surfaces PR noise; a Slack message to two humans is enough because their bots are listening. Failure: missed DMs, secrets in the screen share, or a “post every decision to Slack” rule that spams the channel. The speaker’s caution was explicit: ask for fluid comms, and hope it does not overdo it.

Let Dr. Eggbot orchestrate the Grokbot team

Dr. Eggbot is the bot you talk to when you need a new specialist, a team-wide rule, or a swarm on a repo. You are trying to stop commanding agents one at a time.

When you’re starting to feel like you are micromanaging your bots too much with individual commands and prompts, it’s a good time to take a step back.

That step back is orchestration. Examples from the session: tell Dr. Eggbot you want fluid comms and that decisions should post to Slack; tell it Notion is canonical and every bot must update it; have a game-design bot message the founding engineer with review rules; spin Glow to prototype 3D with Cursor Cloud agents and potato mode; spin Tone as audio engineer and require drop-off in Notion.

Share context the same way you would with humans. The speakers wanted a single game-design document bots could reference, not only a scratch doc. They also used Slack as the bus: “I know you both have bots listening to Slack so I can just say send something to Slack.” If nothing arrives, check the listener bot’s routines before you rewrite the design.

When output sounds like AI writing, they did not accept it. Install P-stack from the marketplace (they cited more than 40 skills for a “potato engineer”) and run the unslap skill or the bro skill to get plain English. Those two were called out as the most useful for “what did my bot just say?”

Good: one instruction fans out; bots message each other; you are steering jobs, not restating the board. Failure: private docs, listeners that miss DMs, and a pile of specialist bots with no shared rules.

Ship in parallel with Cursor projects and potato mode

Once tickets exist, the speakers did not wait for a single agent to finish. They used Cursor Cloud agents against the repo, and Cursor projects as a long-running coordinator that tracks sub-agents. The distinction they drew: projects are more powerful than a simple multitask mode because the project agent and the cloud agents it spawns share memory, so they can pass context.

Potato mode, specifically the full autopilot playbook, is how they opted into a loop that merges a lot of PRs. It is not what they would call YOLO mode. Implementation agents go do the work; verification agents try to run the code. The P-stack skill they named is setup P-stack, which sets how much multitasking you want. At the max level they described a swarm that runs the app and fuzzes it: click around, behave like users, check that things work.

Practical rules they actually used:

Point a Grokbot (one was named Tater) at the project agent and let it spawn sub-agents. They showed five at once in a working tray.
Every agent on the project is a cloud agent. You can close the laptop; it keeps working.
Keep the Notion board visible. Their cards moved to In progress and Done as PRs waited on rebase and then landed.
At a very early stage, they cared more about getting a playable build out than about tests. Agents, in their view, are not super good at writing tests, and failing tests were slowing them down. They deleted tests and said they would write them later once they knew what they were testing.

We’ll write the tests later once we know what we want. Once we know what we’re testing.

Good: multiple PRs in flight, verification in the loop, the Kanban burning down without you copying status. Failure: a swarm polishing tests for an MVP that is not playable, or prototype agents that never interact with the real repo contract.

Treat experiments as side quests so launch stays unblocked

The product work in the session was a game called Cupcake: log in with X, pit uploaded Grokbot templates head-to-head, set a lineup with a captain, climb a global leaderboard. Architecturally they split a Next.js React client from the server so each can evolve, and so the server decides outcomes (a modified client should not be enough to cheat). Web was the launch client because it was the easiest. Auth (Clerk) and a real backend were on the board; one speaker tried Vercel functions as a serverless experiment.

None of that required 3D, pixel art, a terminal client, or an ads marketplace on day one. Those were explicit side quests: try them with a bot, keep them if you like them, scrap them if not.

Use case	Bot / tool	Input needed	Output	Owner
Task tracking	Chief of staff + personal PM bot, Notion	Spoken tasks, shared workspace	Database, pages per task, Kanban or checklist	Ops / PM
Mentions and comms	Ping (Slack bot)	Slack plugin, @mentions, DMs	Processed pings, optional Notion updates	Each teammate
Repo watch and implementation	Bake (founding engineer), GitHub, Cursor	PRs, repo access	PR notifications, merged work, board checkoffs	Engineering
Game design research	Crit / game designer bot	Current mechanics, other games	Notion research, proposed changes	Design
Lightweight 3D / 2.5D prototypes	Glow, Cursor Cloud agents, potato mode	Client repo, bias (they picked match-and-fight)	Throwaway prototypes and videos to merge or scrap	Frontend
Ads / lobby billboard	Research agent + server	How games sell ads, existing server	Recommendation; they pushed back on a heavy advertisers/campaigns/creatives model	Growth
Promo video assets	Remotion	Existing motion assets	1:1, 9:16, 16:9 renders to slot into React later	Marketing
Sound exploration	Tone (audio engineer)	Notion task, “not annoying” bar	8-bit-style prototypes dropped in Notion for review	Audio

On ads, they had Remotion assets in multiple aspect ratios for places like LinkedIn, Instagram, and X, plus a remote-motion prototype for actually running ads. Fidelity was not perfect and the spots did not explain the game. The plan was to slot real mechanics into React components later and render dynamic video. A bot putting those in iPhone frames was interesting; pulling official Apple frames from a Figma pack was the cleaner path, and they noted bots are strong in Figma if you set up a workspace.

On 3D, keep the app lightweight. Swarm potato mode across frontend prototypes, then merge only what you like. Their first pass leaned 2.5D and ran too fast; one speaker wondered whether you need to say three.js explicitly. Pixel art got the same honesty: sometimes good, sometimes really bad.

On sound, add the task to Notion first so the new bot can pick it up. High-level exploration, 8-bit, not an autoplaying annoyance in a browser. Put the files in Notion so the team reviews later.

Later, they wanted a feedback factory: players say it is boring, that feedback gets triaged into Notion, and the same bot system moves. That was a stated interest, not something they finished in the session.

Same pattern outside the repo, if you need it: an internet-connected printer for a morning summary or a dated journal template; a receipt printer for tweets; paying a parking citation through a payments link; listing items on online marketplaces (photos and meta tagging are the painful part); printing arithmetic worksheets. Those are routines and event hooks, not a second product.

Prompts, bot instructions, and workflows

Cleaned from speech to Dr. Eggbot when they created the Slack specialist:

Hello Dr. Eggbot. We are interested in building a Slack bot.

The job of the Slack bot will be to listen for @mentions of our username on Slack and process them.

We might get notified of things like "here's a task that was completed." There will be a Notion doc tracking all of the progress we are making on our game. Start with that for now; we will tweak the instructions as we go.

For now: a Slack bot that just responds to mentions on Slack.

Follow-up they actually needed: watch DMs too, not just @mentions in random channels.

Cleaned from speech when they spawned the 3D prototype bot:

Hey Dr. Eggbot. We want to try more frontend client explorations for the client application we built in the Cupcake repo.

Spin up a bot whose job is to prototype ways we can add more 3D animations while keeping the app super lightweight.

The bot should use Cursor Cloud agents to get this work done and interact with that repo.

We want to swarm agents using potato mode on a bunch of different frontend prototyping tasks.

Corporate purpose: prototype. As we find prototypes we like, we will try to merge those in if they make sense.

They then biased the first system toward match-and-fight flourish (a multi-pick; UI chrome depth was the alternative).

Reconstructed from the speaker's description.

You are our audio engineer. Pick up the sound design task on the Notion board.

Explore high-level styles, including 8-bit music. Prototypes should not be annoying, especially in a web browser where someone might not expect music.

Drop the audio into Notion so the team can listen and review later.

Reconstructed from the speaker's description.

You are a personal PM bot. Your only responsibility is to update Notion.

When a task starts, a PR merges, or a task finishes, update the matching card on the Kanban (Not started / Up next / In progress / Done) and check it off.

Do not do engineering work. Do not handle Slack mentions. Work with the Slack bot and the founding engineer when those events happen.

Reconstructed from the speaker's description.

Dr. Eggbot: we want to be fluid with comms. Every time we make a decision, post to Slack. Do not spam us.

Tell the whole team that Notion is the source of truth and every bot should keep it updated.

Routing rules they used in practice, not as a formal spec: Slack is how you inject work into someone else’s bot ecosystem; Notion is what you reconcile to; GitHub PR events wake the engineer; moving a card to In progress can wake an implementation bot; prototype bots do not block launch.

Measurement and business impact

The speakers did not give time saved, cost, lead, or support numbers. The checkpoint they actually watched was operational: Notion cards moving, PRs opening and merging, bots messaging each other, and Slack drafts landing with the people whose listeners were on. If the board is frozen while chat is busy, the system is not working. If Clerk work flips to In progress without you typing it, it is.

Pitfalls and guardrails

Permissions before prompts. A private Notion page will fail a bot that “should” be able to read it. Share it into the workspace, then retry.
Narrow Slack too late. Mentions without DMs miss the real handoff. Preview drafts before send. Do not ask for “every decision on Slack” without a spam constraint.
Overbuilt ads. A lobby billboard endpoint may be enough. Advertisers, campaigns, and creatives felt like too much; they slowed that agent down.
Blocking on flavor. 3D, pixel art, music, and extra clients are side quests. Web first. Animation speed and “is this even 3D?” were real prototype misses.
Brand and copy. Design docs can read like AI. Run unslap or bro from P-stack before that text becomes the canonical doc.
Tests too early. They treated tests as something that can stall an MVP. That is a stage call, not a claim that tests never matter. They planned a code-quality factory after the thing existed.
Secrets. Connect Slack and similar tools off-screen. They called out a 1Password integration as the thing that would have made a painful secrets day easier.
Client trust. For a competitive game, the server has to decide outcomes or people will modify the client and cheat.
Human in the loop. You still choose launch scope, accept or scrap prototypes, approve Slack, set sharing, and stop a data model that is too clever.

7-day implementation plan

Day 1. Dump the real work into one Notion space. Spawn a chief of staff bot and have it build the to-do list while you talk. Decide checklist vs Kanban (or both views on one database). Write down non-goals out loud: web client first, experiments as side quests. Capture every task you already know (auth, API, ads thinking, prototypes).

Days 2–3. Create three specialists only: Slack (mentions + DMs), GitHub-watching engineer, PM bot that only updates Notion. Connect Slack and GitHub off-screen. Share the Notion doc with the whole workspace. Turn on a routine for @mentions. Practice one preview-and-send Slack message that points at the board. If you already move cards, add the “In progress means start work” listener.

Days 4–5. As soon as you catch yourself re-prompting, have Dr. Eggbot set team rules: Notion is canonical; decisions can go to Slack without spam. Add one canonical doc your bots must read. Let bots message each other instead of you forwarding feedback. If you are in a repo, attach a Cursor project coordinator, turn on potato mode full autopilot at a multitasking level you can stand, and let cloud agents keep running when you step away.

Days 6–7. Spawn at most one or two side-quest bots (prototype UI, ads research, sound) with an explicit scrap rule. Review their output as a human: kill overbuilt schemas, keep lightweight experiments, do not block launch. If copy sounds generated, run it through P-stack unslap or bro. Ship the core path. Only then think about a feedback factory into the same Notion board.

If you only do the first 24 hours, do Day 1 plus one Slack or GitHub specialist. A board nobody updates is still a graveyard.

The business outcome is not more bots. It is a specialist Grokbot team that burns down one Notion board while Slack and GitHub carry the events, and you stay on scope, sharing, and taste. Start with one specialist bot and the shared board; watch the walkthrough when you want to see the roster, potato mode, and the Kanban move in real time.

FAQ

Do I need many Grokbot specialists or one generalist?

The speakers ran specialists on purpose: Slack only, Notion only, GitHub only, design only, prototype only. A generalist is what you already have when you paste a new prompt every five minutes. Use Dr. Eggbot to spawn a named bot when a job repeats, not when you have a one-off question.

Grokbot vs Cursor projects: what is each for?

Grokbot (with Dr. Eggbot) is the roster, the routines, and the comms into Notion and Slack. Cursor projects are a long-running coordinator over cloud agents that share memory and implement against the repo. They used both: Tater working with a project agent, potato mode full autopilot merging PRs, Notion reflecting the burn-down.

Do I need Slack if Notion is already the source of truth?

They used both. Notion was canonical state. Slack was how humans and bots notified each other, including DMs, and how one person’s instruction entered another person’s bot ecosystem. If you skip Slack, you still need some event bus your listeners subscribe to, or you are back to manual prompting.

Checklist vs Kanban for a bot-updated Notion board?

Use a checklist when there are a handful of items you can hold in your head. Use Kanban when you want In progress / Done and a bot that starts work when a card moves. The same Notion database can flip views; one speaker switches depending on the work.

Should bots write tests on day one?

Not in their early-stage call. They said agents are not super good at writing tests, failing tests were slowing the MVP, and they deleted them to ship, with the intent to write tests later once they knew what they were testing. After the product exists, they planned a code-quality factory.

What if a bot cannot see the Notion doc?

Assume permissions, not a bad prompt. One research doc was still private; sharing it into the space unblocked the bot. Also tell every bot that Notion is the source of truth, or they will notify you and never check the box.

Do I need Cursor Cloud agents and potato mode to make this work?

No for the ops layer (chief of staff, Ping, PM bot, GitHub notifications). Yes if you want the parallel implementation loop they ran: cloud agents on the repo, full autopilot with verification, optional swarm that runs and fuzzes the app, and work that continues if you close the laptop.

Web client vs a 3D client first?

Keep web. They split client and server so they could prototype extra clients later (3D, pixel, even a terminal idea) against the same API, but they would not ship multiple clients at launch. 3D was a throwaway prototype bot, not a blocker.