beckett

Use the moment a new @beckett mention arrives, before any work. Classify the request, size the effort (inline answer / one ticket / a plan), and for work requests post the fast ack FIRST.

Use for ANY browser / computer-use work — a live-site lookup, a signup, a login-and-do-something. Dispatches the dedicated BACKGROUND browser agent via `beckett browser` and returns instantly; the agent pauses for human input mid-run (verification codes, choices) and resumes, credentials injected from the jingle keychain without ever touching a transcript.

Use for errands BETWEEN "answer inline" and "file a ticket" — a web lookup on a live site, a small one-off script, a repo you need summarized. Dispatches a short-lived specialist agent via `beckett quick` and hands you its report; no ticket, no worker, no worktree.

Use for creating, storing, or using credentials for an external account without exposing passwords or TOTP seeds in the transcript. Drive the installed `jingle` vault by subprocess injection; never print or transmit a secret.

Use to throw a locally-running app/mockup up at <name>.<your Cloudflare zone apex> (this install: 0xbeckett.me) via Beckett's Cloudflare tunnel, or to manage DNS on that zone. Always go through `beckett dns` / `beckett deploy`; the token is injected for you.

Use whenever you touch GitHub — creating a repo, pushing a branch, opening/merging/reviewing a PR. Always go through `beckett gh ...`; never call raw `gh`/`git push` and never run `gh auth`.

Use to edit and deploy Beckett's OWN public website at your zone apex (this install: 0xbeckett.me) — the landing site, served from Cloudflare's edge. Edit files in web/public, then `beckett site deploy`. This is for the main apex site only — for throwaway mockups at <name>.<zone apex> use the deploy skill (tunnel) instead.

Use when a ticket update reports trouble — a stalled worker, a retry, a repeated failure, or a human asking "what's happening with OPS-N?". Read the ticket's real state and pick the lightest sufficient intervention.

Use before planning, answering questions about people/projects/environment, or staffing — to pull what you already know from your memory knowledge graph. Use whenever a task names a person, project, team, or your own setup.

Use whenever you spec, cast, or build frontend/UI work — a page, component, dashboard, marketing site, app screen, or "make it look good." Encodes the house aesthetic and a Tailwind-first, source-before-hand-roll workflow (21st.dev → shadcn/ui → build). Invoke it before writing a frontend cast brief and hand it to any worker implementing a UI ticket.

Use to persist a durable cross-task fact into your memory knowledge graph — a new person, a project's status change, a learned-worker observation, an environment change. Not for code facts or per-task ephemera.

Use to post the final result of a task in channel, in voice. States what was done, known limits, the artifact, and any assumptions — plus a handshake for anything irreversible (merge/send).

Use ONLY for genuinely big work with real structure — separate pieces that run in parallel or must run in order. Files the whole dependency DAG in one shot with `beckett plan`. For everything else, file ONE ticket.

Use when you want to change yourself — your voice/persona, your memory, a skill, your doctrine, or your own code. Persona and memory apply live; repo-owned changes (skills, doctrine, code) go through a --project beckett ticket and a deploy.

Use when someone asks to continue / pick up / check on earlier work ("can we keep going on X?", "what happened to that thing?"), or after a restart. Check the ticket board for the actual state of the work BEFORE filing anything new.

Use whenever you need to GENERATE or EDIT a raster image — a mockup graphic, logo, sprite, icon, illustration, banner, product shot, or any "make me a picture of…" request. Always use `beckett image`; never scaffold an image project or call codex/python/SVG yourself.