task-inspector
Read-only task inspection skill for controller, worker, and human sessions. Use when the user wants to view task status, inspect a task, or list tasks without changing lifecycle state.
- License 许可
- MIT
- 最近更新
- 2026-03-30
- Stars
- ★ 33
- Forks
- 3
01 前言 Front Matter
- name
- task-inspector
- description
- Read-only task inspection skill for controller, worker, and human sessions. Use when the user wants to view task status, inspect a task, or list tasks without changing lifecycle state.
03 SKILL.md 正文
task-inspector
Audience
- controller
- worker
- human
Triggers
- inspect task
- task status
- list tasks
- show task
CLI Binding
agent-team task listagent-team task show
Required Entry
- controller/human: MUST read
.agent-team/rules/index.mdfirst. - worker: MUST read
worker.yamlfirst.
Expansion
- Load only the task artifact or task lookup needed for the read-only question.
Boundary
- This skill is read-only.
- If the prompt includes create, assign, done, or archive intent, route to
task-orchestratorinstead.
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-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.
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.