---
name: tasks
description: "Graph-backed task lifecycle management. Task nodes in Neo4j with dependency tracking (BLOCKS), conflict detection (AFFECTS), and a parallel safety query (task-ready). Surfaced by memory-search."
tools:
  - task-create
  - task-update
  - task-list
  - task-get
  - task-relate
  - task-complete
  - task-ready
  - session-list
  - session-name
  - project-create
  - project-list
  - project-get
  - project-update
  - project-complete
metadata: {"platform":{"always":false,"embed":[],"pluginKey":"tasks"}}
---

# Tasks

Tasks live in the graph — not in files, not in memory. When the user identifies a piece of work, create a Task node immediately and relate it to the entities it will modify. Surface open tasks at the start of relevant conversations.

## Creating Tasks

Create a task when the user states something that needs doing, when a conversation reveals a follow-up, or when a business obligation or deadline is mentioned. Don't ask — create it and confirm.

When creating, link the task to the entities it will modify via `AFFECTS` relationships. If the user mentions who requested it, link via `RAISED_BY`. If the task has prerequisites ("after the materials arrive"), create a `BLOCKS` edge from the prerequisite to this task.

## Dependencies and Conflicts

**BLOCKS** — sequential dependency. The target task cannot start until the source is completed. When the user says "start the kitchen refit," check for blockers and explain what's outstanding.

**AFFECTS** — conflict detection. Two active tasks that both `AFFECTS` the same entity are in conflict. Surface this when either task is started: "This invoice is also being modified by [other task] — resolve that first or confirm you want both in progress."

## Before Starting a Task

Check `task-ready` before moving a task to `active`. If the task has unresolved blockers, explain what's outstanding. If another active task `AFFECTS` the same entity, surface the conflict and let the user resolve it.

## During a Task

Append progress to notes — never overwrite existing history. If the task creates or modifies graph entities, the `AFFECTS` relationships should already exist from creation. If not, add them.

## Completing a Task

Use `task-complete` to mark done. It re-embeds the task and surfaces any tasks that were blocked by this one and are now ready. Proactively tell the user what's been unlocked: "The materials order is complete — the kitchen refit is now unblocked."

## Session Start

Run `task-ready` and surface the ready set if the user has open tasks. This answers "what can I work on next without conflict?"

## Priority

- `urgent` — must be handled in this session
- `high` — should happen this week
- `normal` — standard backlog
- `low` — nice to have, no deadline pressure

## Tools

- `task-create` — Create a task, optionally linked to a person (RAISED_BY) and entities (AFFECTS)
- `task-update` — Update name, description, status, priority, due date, or append a note (append-only)
- `task-list` — List tasks filtered by status, priority, or related entity
- `task-get` — Fetch a task with full details and all relationships
- `task-relate` — Add AFFECTS, BLOCKS, PART_OF, or RAISED_BY relationships. For Task targets, pass the taskId (UUID) from task-create. For other labels, pass the elementId from memory-search.
- `task-complete` — Mark done, re-embed, surface newly-unblocked tasks
- `task-ready` — Safe-to-start set: pending tasks with no unresolved BLOCKS and no AFFECTS conflicts
- `session-list` — List recent sessions with their linked tasks
- `session-name` — Set a human-readable name on the current session

## Project Tools

Project tools manage `:Project:Task` nodes — multi-label nodes with structured health tracking, lifecycle phases, and parent-child relationships via `HAS_TASK`. Use these instead of manually choreographing `task-create` + `task-relate` sequences for project work.

- `project-create` — Atomic project creation: parent node, child work items, dependencies, and relationships in a single transaction. Accepts tier (quick/standard/full), optional clientRef, targetDate, workItems with blocks dependencies. Max 50 work items.
- `project-list` — Active projects with structured health data (green/amber/red/grey signal, completion counts, overdue/blocked counts, next action). Defaults to pending + active projects.
- `project-get` — Full project detail: children with blocker status, health, relationships, lifecycle notes, timestamps.
- `project-update` — Update project phase, tier, targetDate, clientRef, status, or append a note. Phase changes auto-append `[PROJECT:PHASE]` lifecycle notes.
- `project-complete` — Complete a project. Returns incomplete children so you can confirm with the user before finalising. Always completes — does not gate on unfinished work.
