beads-worker
Use when implementing one cohesive Beads delivery package in a dedicated worker worktree after a coordinator or operator provides ISSUE_ID and WORKTREE_PATH.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- beads-worker
- metadata
- { "owner": "tze", "status": "active", "authors": [ "tze", "OpenAI Codex", "Claude Fable 5.1" ], "last_reviewed": "2026-11-06" }
- description
- Use when implementing one cohesive Beads delivery package in a dedicated worker worktree after a coordinator or operator provides ISSUE_ID and WORKTREE_PATH.
- compatibility
- Requires a Beads-backed git repository with git worktrees, git, bd, jq, gh, and python3 available, plus authenticated GitHub access and network access for push and PR operations.
02 资源文件 7
- 参考文档agents/openai.yaml332 B
- 参考文档references/runtime-contract.md5.7 KB
- 参考文档references/worker-report.md5.1 KB
- 脚本scripts/assert_worker_context.py4.9 KB
- 脚本scripts/emit_worker_report.py10.1 KB
- 脚本tests/test_skill_package.py3.3 KB
- 脚本tests/test_worker_helpers.py22.9 KB
03 SKILL.md 正文
Beads Worker
Implement a cohesive package in its isolated accepted-branch worktree (default
agent/<ISSUE_ID>). ISSUE_ID
is an existing anchor; without a delivery manifest this remains a one-bead job.
The same implementation owner retains ordinary test/review corrections and related
packages until the accepted outcome is finished or explicitly handed off.
Use when dispatched with ISSUE_ID, WORKTREE_PATH, REPO_ROOT and optional
DELIVERY_FILE: “implement this package”, “correct this existing PR”, “continue
this accepted outcome”. Backlog processing without a dispatch uses
beads-looper or
coordinator; authoring uses
writer.
Contract
Read shared delivery model for packages, branch choices, evidence, recovery and per-member acceptance. This worker writes code, commits, pushes and opens/updates its authorized PR. Its lifecycle controller owns Beads writes; never claim/release/close or create follow-up issues here. A looper applying these phases performs lifecycle updates separately as holder.
Dispatch authorizes accepted scope, tests, ordinary corrections, commits and push;
edit examples are guidance unless explicitly an ownership boundary. Resolve routine
engineering choices. Stop only for actual scope/trust/architecture/authorization
changes or inaccessible external capability under
decision autonomy. Keep unaffected work going.
Do not spawn overlapping implementation tracks or commit Dolt-managed .beads/.
Inputs and continuation
| Field | Meaning |
|---|---|
| ISSUE_ID | Existing package anchor; branch defaults to agent/<anchor>, or exact validated delivery.branch |
| WORKTREE_PATH / REPO_ROOT | Isolated worktree and actual shared repository root |
| DELIVERY_FILE | Optional beads-delivery/v1 manifest, required for a multi-bead package |
| Current packet locator | Current instructions, member AC, authority references and recovery state |
| REVIEW_CORRECTION_MODE=yes | Continue existing PR using EXISTING_PR_NUMBER, REVIEW_BEAD_ID and CORRECTION_THREADS_JSON |
Resume the same Claude session/Codex thread for corrections or a related package. A new package revalidates cwd/branch/claims; guidance and relevant content evidence carry over only while their assumptions hold. A fresh session is recovery with an explicit published packet, never evidence of same-owner continuation by itself.
Bootstrap
- Set actual process cwd to WORKTREE_PATH; read runtime contract for guidance discovery and protected/shared Git identity rules.
- Invoke assert_worker_context.py by absolute
skill path with
--worktree-path,--repo-root,--issue-id,--current-pathand, for a package,--delivery-file. It rejects an unrelated repository, protected/wrong branch, manifest mismatch or cwd mismatch. Stop and emitinvalid-runtime-contextif it fails. - Read target AGENTS/CLAUDE and craft-and-care gate; reuse unchanged guidance on continuation. Read the concise current operative packet and exact referenced contracts/source. Fetch projected current fields only as needed; do not load every member's historical notes or inline archives.
Implement and verify
Inspect the actual source before relying on planning assumptions. Implement logical commits on the package branch, marking member IDs for traceability. Several related corrections can share fixtures/tests, owner and PR; unrelated outcomes stay separate. Preserve each member's actual acceptance and hard gates. Do not silently replace an accepted feature with foundation-only scope.
Extend nearest relevant checks under test growth. Run scoped checks while iterating; the full required gate runs on the landing tree in the repository-assigned tier under token efficiency. Reuse unchanged content evidence; refresh affected assumptions and time-sensitive runtime facts. No local duplicate of a required hosted gate is mandated here. No lighter check substitutes for a repo-required one. Finish applicable craft review before handoff.
Ordinary failing tests/CI and review findings stay with this owner. Correct and push to the same PR, then send changed content and tests directly to the independent reviewer. The controller receives state-change receipts, not permissions per hunk. If a shared prerequisite/authority boundary is missing, name exactly its dependent work and resume event; never create a second substrate implementation privately.
Publish and handoff
Prefer one PR per cohesive package, targeting the approved integration base.
Push the exact accepted implementation branch and use gh pr create --body-file with actual newlines.
PR maps every member to acceptance/evidence and explicitly names partial scope.
Only the lifecycle controller sets anchor external_ref and one review relation.
In correction mode update EXISTING_PR_NUMBER; do not create a new PR/review record.
Use ordinary push for appended commits; --force-with-lease only for a justified
history rewrite. Verify PR head and base after pushing. Never put runtime session
URLs or session-attribution trailers in commits/PRs.
A direct-merge candidate is only a repository-permitted trivial change with an independent verdict and the required local gate; a merge queue/required review cannot be bypassed by calling it direct. When policy is unknown, use the PR path. An intermediate integration branch is accumulation, never proof of main delivery.
On push/PR failure follow runtime failure routing: one justified local retry, then a precise external-blocker receipt. Preserve useful commits, remote branch and dirty/local-only work. Never delete a worktree because review begins. Session preemption/recovery publishes packet/claims/head/findings and explicit handoff rather than reallocating ordinary corrections.
Report
Use emit_worker_report.py; field schemas/examples
are in worker-report.md. Multi-bead reports include
--delivery-file and complete --member-results-json coverage, individually
satisfied, partial or blocked with evidence. Ready-for-review does not close any
member. Acceptance-inclusive runtime proof may still be unmet after source merge.
Statuses remain completed-pr-opened, completed-direct-merge-candidate,
blocked-awaiting-coordinator, invalid-runtime-context. “Completed” describes
this handoff, never the whole owner outcome. Include recovery state and exact resume
event when blocked. Current correctness discoveries stay in this package; genuinely
new behavior is reported separately after dedupe, without silently expanding scope.
Finish on a report, never a plan or promise. Search known errors before debugging an unfamiliar tracker/PR failure and record newly confirmed reusable fixes there.
04 同仓库更多 Skills
user-run
Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies