Task management via Basic Memory schemas: create, track, and resume structured tasks that survive context compaction. Uses BM's schema system for uniform notes queryable through the knowledge graph.

Memory Tasks Manage work in progress using Basic Memory's schema system. Tasks are just notes with type: Task — they live in the knowledge graph, validate against a schema, and survive context compaction. Project scope If the project is unknown, discover it with bm project(command="list") . Pass a nonempty project on every note, folder, context and schema call, even with one project or a qualified memory:// URL. Use the chosen project's name, workspace/project , or external ID; <project below is a placeholder for it. Recent activity also requires project . Search accepts project for one project, projects for selected projects, or all projects=True explicitly. Discovery and bundled manuals need no project. Keep the same scope when following returned paths, paginating, or recovering from a refusal. When to Use Starting multi step work (3+ steps, or anything that might outlast the context window) After compaction/restart — search for active tasks to resume Pre compaction flush — update all active tasks with current state On demand — user asks to create, check, or manage tasks Task Schema Tasks use the BM schema system. The schema note lives at schema/Task.md : Creating a Task When work qualifies, create a task note. Use bm write with note type="Task" and put queryable fields in metadata : Why both frontmatter and observations? Fields in metadata (stored as frontmatter) power bm search with filters . Fields as observations ( [status] active ) power bm schema(command="validate", project="<project ") . Include queryable fields in both places for full coverage. Key Principles Steps are concrete and checkable — "Implement X in file Y", not "figure out stuff" Context is for post amnesia resumption — Write it as if explaining to a smart person who knows nothing about what you've been doing Relations link to other entities — parent task [[Other Task]] , related to [[Some Note]] Note types are normalized to snake case — bm write(note type="Task", project="<project ") stores type: task , and note types=["Task"] or note types=["task"] both match it. Resuming After Compaction On session start or after compaction: 1. Search for active tasks: 2. Read the task note to get full context 3. Resume from current step using the context field 4. Update as you progress — increment current step , update context, check off steps Updating Tasks As work progresses, update the task note: Read the task as JSON first and pass its checksum as expected checksum on each edit. Two sessions often update the same task, for example in a pre compaction flush; a revision conflict means the other one wrote first, so re read before writing. Update frontmatter too, with command="set metadata" and the metadata parameter (the body stays unchanged): Completing Tasks When done: Add a brief summary of what was accomplished and any follow up needed. Pre Compaction Flush When a compaction event is imminent: 1. Find all active tasks: bm search(note types=["task"], filters={"status": "active"}, project="<project ") 2. For each, update: current step to reflect actual progress context with everything needed to resume Step checkboxes to show what's done 3. Context that isn't written down is lost at compaction Querying Tasks With BM's schema system, tasks are fully queryable: Query What it finds bm search(note types=["task"], project="<project ") All tasks bm search(note types=["task"], filters={"status": "active"}, project="<project ") Active tasks bm search(note types=["task"], filters={"status": "blocked"}, project="<project ") Blocked tasks bm search(note types=["task"], filters={"assigned to": "claude"}, project="<project ") My tasks bm search("blockers", note types=["task"], project="<project ") Tasks with blockers bm search(note types=["task"], time kind="due", valid overlaps="[2026 10 14,2026 10 21)", project="<project ") Tasks with a step due this week bm schema(command="validate", note type="Task", project="<project ") Validate all tasks against schema bm schema(command="diff", note type="Task", project="<project ") Detect drift between schema and actual task notes Due Dates Give a step or the task a due date with a qualifier (see memory notes ), so "what's due" is one search: A day precision due date counts from that day onward, so a due this week search also returns overdue items. Guidelines One task per unit of work — Don't cram multiple projects into one task Externalize early — write things down when you notice them Context steps — Steps tell you what to do; context tells you why and how Close finished tasks — Don't leave completed work as active Link related tasks — Use parent task [[X]] or relations to connect related work Schema validation is your friend — Run bm schema(command="validate", note type="Task", project="<project ") periodically to catch incomplete tasks

memory-tasks