worker-recovery
Worker-first recovery entry for resuming the current assignment from file artifacts. Use when a worker needs to recover task context, continue work, or re-anchor after a pause.
- License 许可
- MIT
- 最近更新
- 2026-03-30
- Stars
- ★ 33
- Forks
- 3
01 前言 Front Matter
- name
- worker-recovery
- description
- Worker-first recovery entry for resuming the current assignment from file artifacts. Use when a worker needs to recover task context, continue work, or re-anchor after a pause.
02 资源文件 4
- 脚本scripts/_core_path.py697 B
- 脚本scripts/fetch_datasheet_digikey.py5.9 KB
- 脚本scripts/provider_digikey.py14.0 KB
- 脚本scripts/sync_datasheets_digikey.py2.3 KB
03 SKILL.md 正文
worker-recovery
Audience
- worker
Triggers
- resume work
- recover task
- continue current assignment
CLI Binding
- Read worker artifacts directly.
- Use
agent-team task showonly when task details must be refreshed from the CLI.
Required Entry
- MUST read
worker.yamlfirst.
Expansion
- Recovery order is fixed:
worker.yaml->task.yaml->context.md-> referenced materials only if needed.
Boundary
- This is the standard worker recovery path.
- Do not use controller assumptions or
.agent-team/rules/index.mdas the first entry here. - Do not use this skill for worker -> main reporting; that belongs to
worker-reply-main.
04 同仓库更多 Skills
workflow-orchestrator
Governance-only workflow plan entry for controller and human sessions. Use when the user asks to generate, approve, activate, or close workflow plans through `agent-team workflow plan`.
worker-reply-main
Worker-first reporting entry for sending completion, blocker, or decision-needed messages back to main through `agent-team reply-main`.
worker-inspector
Read-only worker inspection skill for controller and human sessions. Use when the user wants to view worker status without opening a worker or sending a reply.
worker-dispatch
Controller-side worker dispatch entry for opening workers, checking targeted worker status, and replying to workers with existing `agent-team worker` and `agent-team reply` commands.
tdd
Acceptance-first TDD workflow for solo implementation work. Use when handling a coding change directly and you want to follow a disciplined sequence: read context, define acceptance criteria, write failing tests when feasible, implement, verify, and conclude with passed, failed, or skipped with reason.
task-splitting
Decompose requirement, design, or brainstorming documents into reviewable task drafts with one function per task and one file per task, then create `agent-team` task packages only after explicit approval. Use when turning a document into tasks, splitting oversized tasks, validating task boundaries, or preparing approved task files for `agent-team task create`.