| name | intake |
| description | Use the moment a new @beckett mention arrives, before any work. Classify the request, size the effort (inline answer / quick errand / deploy a run), and for work requests post the fast ack FIRST. |
intake
Turn a fresh mention into (1) an effort judgment and (2) the right first move. For work
requests, the first move is an ack — a receipt, not a promise — sent before you spend the
turn working.
Steps
- Read the stamp. Every turn arrives as
[channel:<id>] [user:<id> address:"…" msg:<id>].
The channel: id is what you ack to and what you pass as --channel; address: is what to
call them; different user: ids are different people.
- Classify the message:
task (do something), question (answer something), chatter
(banter), or fyi (no action wanted).
- Size it (doctrine: Dynamic effort): answer inline · dispatch a QUICK AGENT (the errand
lane — see the
quick skill) · deploy a run. A 30-second inline scout (Read the
obviously-relevant files, recall the people/projects named) is fine if it changes the call.
The quick lane is for errands: a small one-off script (quick-code), a repo summarized
(repo-explorer). Anything touching a live website goes to the BACKGROUND browser agent
(beckett browser — see the browser skill), which returns instantly and reports back
later. Real work — reviewable, multi-file, building on a project repo — is a run.
- Move:
question/chatter → just reply; your turn text auto-sends. Do NOT run
beckett discord reply — that double-posts.- errand → ack first (same as a work request — quick runs take minutes), then
beckett quick <agent> "<task>" --channel <id>, then relay the report with a second
beckett discord reply (your CLI ack claimed this turn's reply, so plain turn text
won't post). If it answers "detached", the ack already covers it — end the turn; the
result comes back to you as an update turn.
task → ack FIRST: beckett discord reply --channel <id> "<one honest line>" before any
recall or deploying, so they hear from you in seconds. Then ONE
beckett task deploy --prompt "<their ask, faithfully>" --channel <id> --repo <slug> and end
the turn with no further message — the ack was your one reply, and the run card plus the done
ping carry the rest. If a [mid-flow: …] line shows up while you're still working, fold it
into the prompt (or steer the run if it's already out) and send the wrap-up discord reply
now, not a second deploy — run task deploy / task steer as separate Bash calls, never
chained with &&/;, so a mid-flow correction has a boundary to land on.- Honest ack phrasing: deploying queues the work and a worker picks it up within seconds — say
"on it — queuing the JWT swap now", not "the tests are running", which isn't true yet.
- No plumbing in the ack. Never a run id, a branch name, or a
-# line — the machinery
posts the run card and keeps it current. Twelve things deployed is still one ack.
- If there's irreversible/consequential ambiguity, ask the ONE clarify question instead of
acking a direction you might have wrong. Don't deploy a vague prompt — a bad brief wastes a
worker.
On hold
beckett status shows a paused: line when someone has taken the chat-only hold. A task
request that arrives while it's up gets a one-line honest answer — you're paused, the reason if
one was given — and no deploy; beckett resume is the only way it lifts, and that's not your
call to make on someone else's behalf.
Rules
- Receipt, not a promise: don't over-claim scope or timing.
- No filler ("let me think about that"). If it's big, say the read ("this touches auth + the
client + migrations — sending it as one ultracode build") and deploy it.
- One ack. Further messages only when something changed or you need input.
