Builtpublic

Commands

How much you can ask for through a chat box — and the two that changed how it feels.

11 of them
What Command What it does
Conversation DMs carry over; threads are separate from each other. A channel top-level message gets no session
Long jobs !jobs !cancel !stop Two at once, same thread in order. A pipeline running for hours streams progress into the thread
Scheduling !schedule Daily, weekly, or once. After a reboot, recurring rolls forward and one-shots fire immediately
Goals · nudges !goal !nudge Stale goals (72h), three consecutive failures for the same reason, chosen brain unreachable
Swap the brain !provider Spawns a CLI that’s already logged in on this PC
Checklists !check Click to check; it syncs for everyone looking at it
Orgs !org One file, one org — members, channels, readable folders, permitted commands, hourly cap
Auto-listen !listen !exit Inside a designated zone it answers without being mentioned
Plugins One file in plugins/ is one command
Watchdog doctor Revives it within five minutes. A stopped heartbeat counts as death too
Usage !usage 90 days of it. Metadata only — conversation bodies are never written down

Where a session is anchored

Originally the session key was the message’s own identifier. So threads worked while a top-level DM started a fresh conversation every time — meaning you couldn’t pick up yesterday’s thread today.

Now it splits three ways.

  • DM — carries over, expiring after an idle period
  • Thread — its own, never mixed with another thread
  • Channel top-level — no session

The last one isn’t a feature, it’s a defence. Several people use a channel, and attaching a session there means somebody else’s conversation joins my context. One convenience given up to close that path entirely.

There was a trap attached. Unless the job queue’s serialisation key also becomes the session key, two DMs arriving back to back resume the same session concurrently. The moment you make sessions continuous, the queue has to be fixed alongside.

Why the checklist is hand-built

Slack has checkboxes natively, and I built my own anyway. One reason: native checkboxes are per-user input, so they don’t sync. What I check nobody else can see.

So it works by re-rendering the button labels wholesale. When anyone clicks, the message itself updates, so everyone looking at it sees the same state.

It toggles by text too, for situations where clicking isn’t possible.

Watching a goal versus telling you about it

Nudges use one concept in two directions. Pull builds suggested prompts with no side effects; push waits out a cooldown and DMs you.

The three watchers were chosen on one criterion — they must need to understand nothing.

  • A goal hasn’t moved in 72 hours
  • Three consecutive failures for the same reason
  • The selected brain can’t respond

All three are decided by counting. The approach of reading the conversation and judging “this is going in circles” was rejected.

Usage keeps metadata only

Ninety days of records, and no conversation bodies. When, who, how long.

Good for privacy and bad for audit. It cannot answer “what instruction was given then.” That’s a trade-off, and being a personal tool, I took the first one. Deploying to a team would mean reversing it.