Skip to content

Task Assign Directions

How to assign a task — presentation format, completion tracking, state change protocol

When to use

user runs /wb-task-assign or asks to assign a task to the current session

Slash command: /wb-task-assign

  • tasks/task_assign
  • tasks/task_toggle

Directions

Assign via mcp__work-buddy__wb_run("task_assign", {"task_id": "<id>"}). Do NOT use Python code.

If no argument provided, ask for the task ID.

Assign vs read

  • task_assign = read the task AND record the current session against it (claim). Use when the user is starting work.
  • task_read = pure read, no session write. Use when you only need to inspect a task (e.g. user is browsing, or an upstream flow wants the payload without implying a claim).

Both return the same read payload. Internally, task_assign composes task_read with a session-tracker write, so agents can swap call sites without reshaping downstream code.

The assignment is queryable in both directions: the read payload embeds assigned_sessions (task → sessions), and session_tasks_get(session_id) returns the reverse (session → tasks, with each task's text + state).

Presentation after assignment

  1. Task: text and current state/urgency
  2. Contract: which contract it serves (if any)
  3. Note: preview of note content (if exists) + file path
  4. Sessions: how many sessions have worked on this task

State

Task state is NOT changed by assignment. To mark focused, use task_change_state separately.

Completion tracking

After committing code (or completing the deliverable), proactively ask: "Task looks complete -- should I mark it done?"

On approval: mcp__work-buddy__wb_run("task_toggle", {"task_id": "<id>", "done": true})

Do not silently mark the task done -- always confirm first.