task-management

name	Task Management
catalog_line	Decide when work becomes a task; manage task scope, ownership, schedule, and relationships safely.
description	Task workflow playbook for deciding when work should become a task and how to manage task scope, ownership, schedule, and relationships safely.
skill_type	procedure
altitude	domain
activation	progressive
preserve_markdown	true
legacy_paths	["onto.task.skill","task.skill","tasks.skill"]
child_skills	[{"id":"task_state_updates","name":"Task State Updates","summary":"Focused child skill for mapping user progress language to safe task state updates.","when_to_load":["When the user reports task progress, completion, or blocking and state mapping is the main risk."],"path":"apps/web/src/lib/services/agentic-chat/tools/skills/definitions/task_state_updates/SKILL.md"}]
reference_modules	[{"id":"task_management.state_coverage","name":"Task State Coverage","summary":"Extra examples for mapping progress language to task state updates without emitting description-only writes.","when_to_load":["When task status mapping is ambiguous or a previous update omitted state_key."],"path":"references/state-coverage.md"}]
path	apps/web/src/lib/services/agentic-chat/tools/skills/definitions/task_management/SKILL.md

Task Management

Identity

Task workflow playbook for deciding when work should become a task and how to manage task scope, ownership, schedule, and relationships safely.

This is a procedure skill at domain altitude: an operational runbook for BuildOS task operations (create, update, ownership, scheduling, containment). The deep state-mapping cases — turning progress language into safe state updates — are owned by the child skill task_state_updates (declared in frontmatter child_skills), which loads when state mapping is the main risk.

Activation

• Decide whether a user request should become a task at all
• Create a task for future human work
• Assign or reassign task ownership
• Update task state, dates, or priority
• Place a task under the right plan, goal, or milestone

Escalate to the child skill task_state_updates when the user reports task progress, completion, or blocking and state mapping is the main risk.

Procedure

1. Decide first whether this should be a tracked task or whether the work should just be done in the conversation now.
2. If it should be a task, choose the project and the right parent context: plan, goal, milestone, or direct project scope.
3. For creates, include title and only add schedule, assignees, or supporting links when the user has given enough concrete information.
4. Prefer assignee_handles over actor IDs unless the IDs were just discovered in-turn from project membership data.
5. Use valid task states such as todo, in_progress, blocked, or done.
6. For updates, reuse the exact task_id from recent context or the prior assistant turn when the follow-up clearly refers to that task. If the exact task_id is not already known, discover it before any write.
7. Only use description merge strategies when append or merge behavior is actually needed; otherwise keep updates simple.
8. State coverage. When the user reports that real-world task work advanced (started, in progress, blocked, or finished), include state_key in the update_onto_task call alongside any description change. Do not update only the description when the task state should also move.
9. After execution, tell the user what changed and call out any missing owner, due date, or parent relationship that still matters.

Direct tool packaging

Part 1: Choose the dynamic op first

• Treat task work as two separate decisions: first choose the canonical op, then package the call.
• Examples: use for a new tracked task, for changing an existing task, and or when the exact is still unknown.