---
name: work
description: "Graph-backed work-item lifecycle management. Task nodes in Neo4j with dependency tracking (BLOCKS), conflict detection (AFFECTS), and a parallel safety query (work-ready). Surfaced by memory-search."
tools:
  - name: work-create
    publicAllowlist: false
    adminAllowlist: false
  - name: work-update
    publicAllowlist: false
    adminAllowlist: false
  - name: work-list
    publicAllowlist: false
    adminAllowlist: false
  - name: work-get
    publicAllowlist: false
    adminAllowlist: false
  - name: work-relate
    publicAllowlist: false
    adminAllowlist: false
  - name: work-complete
    publicAllowlist: false
    adminAllowlist: false
  - name: work-ready
    publicAllowlist: false
    adminAllowlist: false
  - name: session-list
    publicAllowlist: false
    adminAllowlist: false
  - name: session-name
    publicAllowlist: false
    adminAllowlist: false
  - name: project-create
    publicAllowlist: false
    adminAllowlist: false
  - name: project-list
    publicAllowlist: false
    adminAllowlist: false
  - name: project-get
    publicAllowlist: false
    adminAllowlist: false
  - name: project-update
    publicAllowlist: false
    adminAllowlist: false
  - name: project-complete
    publicAllowlist: false
    adminAllowlist: false
metadata: {"platform":{"always":false,"embed":[],"pluginKey":"work"}}
skills:
  - skills/execute-task/SKILL.md
mcp:
  command: node
  args:
    - ${PLATFORM_ROOT}/lib/mcp-spawn-tee/dist/index.js
    - ${PLATFORM_ROOT}/plugins/work/mcp/dist/index.js
  env:
    MCP_SPAWN_TEE_NAME: work
    LOG_DIR: ${LOG_DIR}
    PLATFORM_ROOT: ${PLATFORM_ROOT}
    ACCOUNT_ID: ${ACCOUNT_ID}
    SESSION_ID: ${SESSION_ID}
    AGENT_SLUG: ${AGENT_SLUG}
mcp-manifest: auto
---

# Work

Work items 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 work at the start of relevant conversations.

## Creating Work Items

Create a work item 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 work item to the entities it will modify via `AFFECTS` relationships. If the user mentions who requested it, link via `RAISED_BY`. If the work has prerequisites ("after the materials arrive"), create a `BLOCKS` edge from the prerequisite to this work item.

## Dependencies and Conflicts

**BLOCKS** — sequential dependency. The target work item 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 work items that both `AFFECTS` the same entity are in conflict. Surface this when either is started: "This invoice is also being modified by [other work item] — resolve that first or confirm you want both in progress."

## Before Starting

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

## During

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

## Completing

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

## Session Start

Run `work-ready` and surface the ready set if the user has open work. 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

- `work-create` — Create a work item, optionally linked to a person (RAISED_BY) and entities (AFFECTS). For durable-action records, pass `kind` (e.g. `"onboarding-establish-owner"`, `"cloudflare-tunnel-login"`) to set status `running`; pass `inputs` with the form payload and `inputSchema` declaring any secret fields — values land on the Task as `inputs.<field>` props after `redactSecrets` strips schema-tagged keys; `inputsProvided` records the call-shape (names submitted) alongside the value-bearing `inputs.*`. Pass `raisedDuringConversationKey` to write a `:RAISED_DURING` edge to the originating Conversation when it differs from the current session.
- `work-update` — Update name, description, status, priority, due date, or append a note (append-only). Pass `appendStep` to atomically append one entry to `steps[]` (call once per action phase); `errorMessage` is required when status transitions to `failed`; `completed` and `failed` transitions auto-set `completedAt`.
- `work-list` — List work items filtered by status, priority, or related entity
- `work-get` — Fetch a work item with full details and all relationships
- `work-relate` — Add AFFECTS, BLOCKS, PART_OF, or RAISED_BY relationships. For Task targets, pass the taskId (UUID) from work-create. For other labels, pass the elementId from memory-search.
- `work-complete` — Mark done, re-embed, surface newly-unblocked work
- `work-ready` — Safe-to-start set: pending work items with no unresolved BLOCKS and no AFFECTS conflicts
- `session-list` — List recent sessions with their linked work items
- `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 `work-create` + `work-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.
