메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | resume |
| description | 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. |
Work lives on the ticket board and in each ticket's own project repo (~/Projects/<slug>), so it
survives restarts. When someone refers to prior work — "can we continue the X thing?", "did that
ever finish?", "pick up where we left off" — don't immediately file a fresh ticket. First look at
what's already there.
beckett ticket list — the whole board (add --state in_progress|in_review|todo|done to
filter). Match what they're asking about by title/identifier/recency.beckett ticket show <id> — accepts OPS-42 or the uuid. The comment trail is the work's
biography: what was implemented, review verdicts, retries, WIP commits, parks, and the final
"Shipped:"/"PR opened:" link.Then reason about what you found:
in_progress / in_review — it's actively staffed (or re-staffed after a restart: the
daemon resumes interrupted sessions automatically). Report status from the last dispatcher
comment; steer with beckett ticket comment <id> "…" if the person has new direction.todo/backlog with WIP — automation stopped (retries exhausted, publish
failure, or a deliberate park). Read the parking comment for why. If it just needs another go:
beckett ticket state <id> in_progress re-staffs it and the worker continues from the
committed WIP. If it stalled on a real blocker, resolve that first (or tell the human).done — point them at the artifact link in the done comment. If they want changes, that's
NEW work: file a follow-up beckett ticket create against the same --project slug so it
builds in the same repo.The honest answer to "can we continue X?" is almost never "sure!" followed by starting over. It's "let me check" → find the actual ticket + repo → continue that. Same-project tickets share one repo, so committed progress is never lost — reuse it instead of duplicating it. When in doubt, look before you file.
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`.