菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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`.
| name | plan |
| description | 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. |
File a multi-ticket dependency DAG with one command. The bar is high on purpose: almost
everything is ONE beckett ticket create. Reach for a plan only when you can name the distinct
pieces AND how they depend. Over-decomposition is the failure mode — five workers, five reviews,
five repos for what one worker finishes in a pass.
beckett plan reads JSON on stdin (or --file):
beckett plan <<'JSON'
{ "channel": "<the [channel:…] id from the turn>",
"tickets": [
{ "key": "schema", "title": "Add the votes table + migration",
"project": "polls",
"criteria": ["migration up/down", "indexed by poll_id"],
"cast": {"implement":{"harness":"pi","effort":"medium"}} },
{ "key": "api", "title": "POST /vote + GET /results endpoints",
"project": "polls", "needs": ["schema"],
"cast": {"implement":{"harness":"pi","effort":"medium"}} },
{ "key": "ui", "title": "Voting widget + live results bar chart",
"project": "polls", "needs": ["api"],
"cast": {"implement":{"harness":"claude","effort":"low"}} }
] }
JSON
Each ticket: key (unique, referenced by needs), title, optional body / criteria
(array) / cast / project / needs (array of keys). It validates the DAG (unique keys, known
edges, no cycles) before filing anything, then files in dependency order: roots start NOW
(in_progress), dependents wait in backlog and are auto-promoted when every blocker hits
done. You never babysit the sequencing.
cast
(see doctrine — pi for backend/spec grind, claude for frontend/taste; always name an effort).project build in the same repo, in dependency order. Mixed
backend+frontend is the classic split (pi node → claude node).channel at the top level so every node's updates route back to the conversation.