Use when a Leader turns ready Quick Task or Project Work state into Worker task instructions, sends assignment messages, checks submitted results, and defines completion/blocker report contracts. Do not use to create projects, create rooms, or execute Worker tasks.
69
84%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Use this skill when acting as Leader to create Project Work task specs, send assignment messages, and check submitted Worker results.
Each delegated task should have a task id, owner, scope, expected deliverables, acceptance criteria, and blocker reporting path. Write task instructions to the shared task directory before asking the owner to execute.
A submitted result is only a candidate result until accepted by the Leader. Do not use this skill to turn ordinary conversation into tasks.
Use this skill for:
taskflow calls as LeaderUse teamharness-project-management to create projects, plan DAG or Loop work,
resolve ready nodes, record Loop iteration decisions, and accept results into
project progress.
Use delegate_task only for Project Work nodes that are ready in project
state. Do not create bare tasks directly from a user request. First create or
update a project DAG, then delegate a ready project node returned by
projectflow readyNodes, or create/update a Loop and delegate a ready
project node returned by readyLoopNodes.
For Quick Task, projectflow create_quick_project is used instead. It
already writes shared/tasks/{task-id}/meta.json,
shared/tasks/{task-id}/spec.md, and marks the task assigned; do not call
delegate_task again for that task. create_quick_project does not
auto-notify, so after it returns ok: true, send the assignment message
described in the Assignment Message section below.
Before delegation:
readyNodes or readyLoopNodes.taskflow. The spec must include the
completion report instruction below.shared/tasks/{task-id}/.... Do not ask a
Worker to write or submit shared/projects/...; project reports are Leader
owned.delegate_task mentions the assigned Worker automatically after it
succeeds — do not send a second mention.teamharness-roomflow owns task-room creation, reuse, external source binding,
and Worker invites before Project Work reaches this skill.
Call taskflow with role: "leader" and pass payload as an object:
{
"role": "leader",
"action": "delegate_task",
"payload": {
"projectId": "demo-project-001",
"taskId": "demo-project-001-01",
"roomId": "room:!task-room:matrix.local",
"spec": "# Task demo-project-001-01\n\n## Context\nExplain why this task exists.\n\n## Expected Result\nCreate deliverables under shared/tasks/demo-project-001-01/ and submit a result with STATUS, SUMMARY, and DELIVERABLES.\n\n## Acceptance Criteria\n- The result addresses the task scope.\n- Deliverables are listed in result.md.\n\n## Completion Report\nAfter `taskflow submit_task` returns `ok: true`, reply in the current Task room and mention the exact Leader Matrix user from this task context:\n\n<Leader Matrix user> TASK_COMPLETED: demo-project-001-01 - Result: shared/tasks/demo-project-001-01/result.md\n\nDo not use `NO_REPLY` after a successful task submission.\n"
}
}delegate_task writes:
shared/tasks/{task-id}/meta.json
shared/tasks/{task-id}/spec.mdIt changes the project node status to indicate the node is delegated/assigned,
publishes the task directory to shared storage, and automatically sends the
Worker assignment notification with m.mentions in the Task room, returning
the Matrix eventId in the response.
Every delegated task spec must include this final instruction, with the task id and result path adjusted for the actual task:
## Completion Report
After `taskflow submit_task` returns `ok: true`, reply in the current assignment
room and mention the exact Leader Matrix user from this task context:
<Leader Matrix user> TASK_COMPLETED: demo-project-001-01 - Result: shared/tasks/demo-project-001-01/result.md
Do not use `NO_REPLY` after a successful task submission.If the project node already contains a custom completion line, preserve it and still make the Leader mention requirement explicit.
delegate_task automatically notifies the assigned Worker in the Task
room: it validates room membership, sends a message with m.mentions
mentioning the Worker's full Matrix ID, and returns the Matrix eventId.
Do not send a second assignment message after delegate_task — that
duplicates the assignment and can trigger the Worker twice.
create_quick_project does not auto-notify. After it returns ok: true,
send a normal current-session reply in the Task room and mention the Worker:
@worker-a:matrix.local TASK_ASSIGNED: demo-project-001-01 - Please start this task. Spec: shared/tasks/demo-project-001-01/spec.mdDo not use the message tool for this same-room assignment. The direct Task
room reply is the trigger; using message plus a direct mention can trigger the
Worker twice.
Do not ask the Worker to edit project files. Do not ask several Workers to own the same task directory.
When a Worker reports completion or blocker status, call:
{
"role": "leader",
"action": "check_task",
"payload": {
"taskId": "demo-project-001-01"
}
}If effective is false, do not accept the task. Tell the Worker what is
missing and wait for a corrected result.
If effective is true, return to teamharness-project-management and decide
whether to accept the result into project progress.
Worker results should contain:
STATUS: SUCCESS
SUMMARY: Short summary
DELIVERABLES:
- shared/tasks/{task-id}/pathFor report-style tasks, the Worker may write the full report directly to
shared/tasks/{task-id}/result.md before calling submit_task. The tool
records structured status in task metadata and does not create or rewrite
result.md. Do not treat result.md as only a short envelope when it is the
expected deliverable.
Accepted statuses are:
SUCCESSSUCCESS_WITH_NOTESREVISION_NEEDEDBLOCKEDSubmitting a result ends that Worker task. If more work is needed, create a new project node and delegate a new task.
delegate_task sends the Worker assignment automatically: it validates
room membership, sends the assignment message with m.mentions in the Task
room, and returns the Matrix eventId in the response. No additional
assignment message is needed after a successful delegate_task.
submit_task and the notificationNeeded field are structured hints for the
completion report. When a Worker reports TASK_COMPLETED with a result path,
check the result and follow teamharness-project-management for acceptance or
rejection.
The Leader should check notificationNeeded after accepting a task result to
determine whether a requester report or downstream notification is due. See
teamharness-project-management Post-Action Notification for the full
protocol.
223ddc2
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.