Tasks in Graph Memory aren't just a todo list — they're a knowledge-connected workflow. Every task lives in the same graph ecosystem as code, documentation, notes, and skills. This means a task like "Fix auth redirect loop" can be directly linked to the code symbol it needs to change, the documentation that explains the expected behavior, the note that captured the original bug report, and the skill recipe for debugging auth issues.
Tasks follow a kanban model with six statuses:
backlog → todo → in_progress → review → done
→ cancelled
| Status | Meaning |
|---|---|
backlog |
Identified but not prioritized |
todo |
Prioritized, ready to start |
in_progress |
Actively being worked on |
review |
Work complete, awaiting review |
done |
Completed |
cancelled |
Won't be done |
The tasks_move tool manages completedAt automatically:
- Moving to
doneorcancelled→ setscompletedAtto current time - Moving from
done/cancelledto any other status → clearscompletedAt(reopening)
This is also enforced when changing status via tasks_update — the automation is consistent regardless of how the status changes.
Four priority levels with explicit sort ordering:
| Priority | Sort order | Meaning |
|---|---|---|
critical |
0 (first) | Drop everything, fix now |
high |
1 | Important, do soon |
medium |
2 | Normal priority |
low |
3 | Nice to have |
tasks_list sorts by:
- Priority (critical first → low last)
- Due date (earliest first, null dates sort to the end)
This ensures the most urgent and time-sensitive tasks always appear at the top.
Tasks connect to other tasks via three relationship types:
"Write auth tests" → [subtask_of] → "Implement authentication"
Creates a parent-child hierarchy. tasks_get enriches the parent with its subtasks list.
"Fix database migration" → [blocks] → "Deploy v2.0"
Indicates that one task must be completed before another can proceed. tasks_get enriches with both blockedBy (incoming) and blocks (outgoing) lists.
"Update docs for auth" → [related_to] → "Fix auth redirect loop"
Free-form association for tasks that are related but don't have a dependency.
tasks_get returns more than just the task fields — it traverses the graph to include:
- subtasks — all tasks that have a
subtask_ofedge pointing to this task - blockedBy — all tasks with
blocksedges pointing to this task (things blocking us) - blocks — all tasks this task blocks (things we're blocking)
- related — all tasks with
related_toedges (both directions, deduplicated) - crossLinks — links to docs, code, files, knowledge, skills nodes
This gives an LLM or UI a complete picture of a task's context in one call.
Tasks can link to nodes in any other graph:
tasks_create_link({
taskId: "fix-auth-redirect-loop",
targetId: "src/auth.ts::login",
targetGraph: "code",
kind: "fixes"
})
This is powerful for:
- Linking tasks to the code they modify — "this task fixes this function"
- Linking tasks to relevant docs — "see the auth flow documentation"
- Linking tasks to knowledge notes — "the bug report note explains the root cause"
- Linking tasks to skills — "use this debugging recipe"
Tasks have an assignee field referencing a team member ID from the .team/ directory. This enables:
- Filtering — "show me all tasks assigned to Alice"
- Kanban views — see who's working on what
- Team awareness — an LLM knows which person to ask about a task
See Team Management for details on the .team/ directory.
Every task is mirrored to .tasks/{id}/task.md with full frontmatter:
---
id: fix-auth-redirect-loop
status: in_progress
priority: high
tags: [auth, bug]
assignee: alice
dueDate: 2026-03-20T00:00:00.000Z
estimate: 4
completedAt: null
---
# Fix Auth Redirect Loop
When users log in with an expired session...This means:
- Tasks are version-controlled alongside code
- You can edit tasks in your IDE — changes sync back to the graph
- Tasks survive server restarts (persisted as both JSON and markdown)
- Tasks support file attachments stored alongside the task.md file
Graph Memory tasks aren't meant to replace your project management tool. They serve a different purpose:
- LLM-accessible — an AI assistant can create, update, search, and relate tasks using MCP tools, without needing API keys for external services
- Contextually linked — tasks are connected to code symbols, documentation sections, and knowledge notes in the same graph
- Local-first — everything is in the project directory, works offline
- Semantically searchable — "what tasks are related to authentication?" uses vector search, not just keyword matching
- Recipe-aware — tasks can reference skills (recipes) for how to accomplish them
Think of them as working memory for the AI-human collaboration, not as a permanent project management system.
Tasks support an order field for manual positioning within a status column. The ordering system uses gap-based integers — new tasks are assigned order values with large gaps (e.g. 1000, 2000, 3000) so that inserting between two tasks just picks the midpoint without renumbering siblings.
The tasks_reorder tool repositions a task by specifying beforeId and/or afterId anchors. When gaps become too small, the system automatically renumbers all tasks in the column.
Epics are higher-level groupings that organize related tasks into initiatives or milestones. They live in the same TaskGraph as tasks, distinguished by a nodeType: "epic" field.
Tasks are linked to epics via belongs_to edges:
"implement-auth" → [belongs_to] → "q4-security-epic"
"fix-session-bug" → [belongs_to] → "q4-security-epic"
Key properties:
- A task can belong to at most one epic
- Deleting an epic removes the
belongs_toedges but does not delete the tasks - Epics have the same status and priority fields as tasks
epics_getreturns the epic with its full task list
projects:
my-app:
projectDir: "/path/to/my-app"
graphs:
tasks:
enabled: true # can be disabled
access:
bob: r # bob can only view tasks, not modify