/task

name: task
description: 'Tracks chat assignments, steering in a task thread, WORKER completions, and confirmations alongside task progress and results.'

Tasks

Read `.hermit/TASKS.md` first for intake and confirmation policy. Use `bun ${CLAUDE_PLUGIN_ROOT}/scripts/task.ts <verb> .hermit ...` for every record operation. Never edit `tasks/` directly. All `task.ts` shorthand uses that pinned command; see `../../docs/task-records.md`.

Commands

• `task-block`: `bun ${CLAUDE_PLUGIN_ROOT}/scripts/task.ts block .hermit`
• `task-note`: `bun ${CLAUDE_PLUGIN_ROOT}/scripts/task.ts note .hermit`
• `conversation`: `bun ${CLAUDE_PLUGIN_ROOT}/scripts/conversation.ts .hermit`

Intake

Typed terminal turn: `task answer <id> --local --reply <token>`, `task dismiss <id> --reason-stdin`, `task close <id> --local --by confirmed --reason-stdin`; no prompt, bypass refuses `answer --local`. If the gate says only the operator can run it, have them type `/hermitd:task-decide <id> <token>`. Chat turn: `--chat`/`--user`. Decision replies: `task answer [<id>] --chat <key> --user <sender-id> --reply <token>` first. In any language, map to yes, no, a number or label. Respect `not_decider`, `consent_required`, `stale` and `ambiguous`. Input resumes `decision.resume`. Before task steering, run `task.ts list .hermit --open --conversation <sourceKey>:<chat_id>`. Select via the task thread or hook's open-tasks line; on ambiguity, ask once naming candidates. Questions open nothing.

Use `open --title ... --requester <sourceKey>:<user_id> --done ...` for assignments. Pass requester display name, origin message id, conversation, due date and explicitly named approver when available. A record's `--card` stays with the resident, which also hands it to a worker and takes it back with `note <id> --owner worker:<agentId>` / `--owner resident`; a worker never opens or closes a record itself. Resident readiness is handled by `/hermitd:resident-start`. Work whose definition of done the agent can observe gets a check, at `open` when the predicate is already known, otherwise with `note <id> --check` once the inputs have been read.

Dispatch independent new work at once, in parallel with running tasks. Only for work explicitly requested after the current work, open a resident record and state its queue position from the open-task ordering. After a close or cancel, continue with `next_queued` in the same turn when the digest names a record. In a chat without threads with two or more open tasks, resident-composed replies and cards name their task by handle.

Complete a task turn

For a task assignment or update, follow this order once the caller's authorization check has passed (`channel-responder/SKILL.md` § 1c for a channel turn):

1. **Accept an assignment.** Send the short "On it" acknowledgement through the channel, then create its record using the route § Channel task procedures selects. Do this before reading task inputs or doing substantive work. 2. **Do the work.** Record progress on the selected record per § Progress and results. 3. **Deliver and record the outcome.** Send the outcome through the channel. When it needs human acceptance, pipe that same outcome into `task.ts block .hermit <id> --result-stdin` before ending the turn. Require the returned digest to say `listing: "unconfirmed"` with a positive `result_rev`; this saves the result and waits on the named approver or requester. 4. **Acknowledge updates.** After a requested record change succeeds, acknowledge it through the channel, including short bookkeeping-only turns. A terminal summary does not complete this step. Confirmed results close through § Closure's revision and actor checks.

Finished recommendations, drafts and reviews awaiting acceptance require `--result-stdin`. The `--waiting-on` / `--status-line` / `--next` form records an unfinished-work stall, not a result. If a finished outcome returns a stall digest, run the result form before ending the turn.

Inspect each command's result. If delivery or recording fails, report what remains incomplete through the available channel; do not claim the failed step succeeded.

Applying proposal tasks

At intake, a `kind: proposal` record follows [proposal-create/apply.md](../proposal-create/apply.md), which also says when an instruction is its consent. The resident can apply a one-line configuration edit; use `hermitd:task-worker` for larger work. Never open another task to implement it. A `done` worker response with a passing executable check closes through `task-check.ts`; a worker’s `task report --kind result` records authored content and opens the admin result decision. Resident-authored content uses `block --result-stdin`. For `needs-input`, REJECT opens a new `consent` decision with the evidence; an unsettled implementation choice opens an `input` decision with options and `resume` naming the procedure. Pass `--decision` JSON to `block`, plus status and next step for an unfinished wait.

Channel task procedures

• **Task thread**: a thread holds one open task; chats without threads share records named by the hook’s open-tasks line. With `[task thread <key>: …]`, continuations steer that record; unrelated one-offs answered in this reply open nothing. Unrelated work meeting TASKS.md’s threshold opens its own task. When unsure, ask once. Steering to watch something goes to `/hermitd:watch <instruction>` in this turn.
• **Open the thread.** Run `bun ${CLAUDE_PLUGIN_ROOT}/scripts/conversation.ts .hermit thread-open --source '<sourceKey>' --chat-id '<chat_id>' --message-id '<message_id>' --name '<title>'`, adding `--thread-id '<value>'` when the tag carries the thread attribute. The title is 1 to 100 characters, distinguishing detail (subject or id) first and shared details (model, effort) last. Its JSON `key` is `<key>`, `chat_id` is the destination chat, and any `reply` parameters go on every reply in the task thread. On `thread_busy`, Read [branches.md](branches.md) § Busy thread and foll