
Memory Tasks
- 525 installs
- 25 repo stars
- Updated April 20, 2026
- basicmachines-co/basic-memory-skills
memory-tasks is a Claude Code skill that creates, tracks, and resumes structured tasks via Basic Memory schemas for developers whose agent work must survive context window resets.
About
memory-tasks is a task persistence skill from basicmachines-co/basic-memory-skills that manages work-in-progress using Basic Memory's schema system. Tasks are notes with type: Task that live in the knowledge graph, validate against a schema, and remain queryable after context compaction. Developers use memory-tasks when starting multi-step work with three or more steps, after compaction or restart to search for active tasks, and during pre-compaction flush to update all active tasks with current state. The skill bridges agent session limits and long-running implementation work without losing progress metadata.
- Tasks are standard notes with type: Task that live in the Basic Memory knowledge graph
- Schema enforces description, status (active/blocked/done/abandoned), steps array, current_step, context, blockers, and p
- Use before starting any multi-step work that exceeds one context window
- Pre-compaction flush updates all active tasks with latest state
- Post-compaction resume by querying active tasks in the graph
Memory Tasks by the numbers
- 525 all-time installs (skills.sh)
- Ranked #741 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Aug 1, 2026 (Skillselion catalog sync)
npx skills add https://github.com/basicmachines-co/basic-memory-skills --skill memory-tasksAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 525 |
|---|---|
| repo stars | ★ 25 |
| Last updated | April 20, 2026 |
| Repository | basicmachines-co/basic-memory-skills ↗ |
How do coding agents persist tasks across context compaction?
Create, track, resume, and update structured tasks that persist through context window resets and knowledge graph queries.
Who is it for?
Developers running long multi-step agent sessions with Basic Memory who need tasks to survive context window limits.
Skip if: Single-step edits or teams not using Basic Memory schemas and knowledge-graph storage.
When should I use this skill?
Starting work with 3+ steps, recovering after context compaction, or flushing active task state before a session ends.
What you get
Schema-validated Task notes in the knowledge graph with resumable state after compaction or session restart.
- Task notes with type: Task
- Resumable WIP state after compaction
Files
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.
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 (SPEC-SCHEMA). The schema note lives at memory/schema/Task.md:
---
title: Task
type: schema
entity: Task
version: 1
schema:
description: string, what needs to be done
status?(enum): [active, blocked, done, abandoned], current state
assigned_to?: string, who is working on this
steps?(array): string, ordered steps to complete
current_step?: integer, which step number we're on (1-indexed)
context?: string, key context needed to resume after memory loss
started?: string, when work began
completed?: string, when work finished
blockers?(array): string, what's preventing progress
parent_task?: Task, parent task if this is a subtask
settings:
validation: warn
---Creating a Task
When work qualifies, create a note in memory/tasks/YYYY-MM-DD-short-name.md:
---
title: Descriptive task name
type: Task
status: active
created: YYYY-MM-DD
current_step: 1
---
# Descriptive task name
## Observations
- [description] What needs to be done, concisely
- [status] active
- [assigned_to] claude
- [started] YYYY-MM-DD
- [current_step] 1
## Steps
1. [ ] First concrete step
2. [ ] Second concrete step
3. [ ] Third concrete step
## Context
What future-you needs to pick up this work. Include:
- Key file paths and repos involved
- Decisions already made and why
- What was tried and what worked/didn't
- Where to look for related contextKey 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
- Use observations for BM-queryable fields —
[status],[description],[assigned_to]etc. become searchable in the knowledge graph - Relations link to other entities —
parent_task [[Other Task]],related_to [[Some Note]]
Resuming After Compaction
On session start or after compaction:
1. Search for active tasks:
- Via BM:
search_notes("type:Task status:active")orsearch_notes("[status] active") - Via memory_search: query "active tasks" (composited search includes task scanning)
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:
## Steps
1. [x] First step — done, resulted in X
2. [x] Second step — done, changed approach because Y
3. [ ] Third step — next up
## Context
Updated context reflecting current state...Update frontmatter too:
current_step: 3Completing Tasks
When done:
status: done
completed: YYYY-MM-DDAdd 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: search_notes("type:Task status:active") 2. For each, update:
current_stepto reflect actual progresscontextwith everything needed to resume- Step checkboxes to show what's done
3. This is critical — context not written down is context lost
Querying Tasks
With BM's schema system, tasks are fully queryable:
| Query | What it finds |
|---|---|
search_notes("type:Task") | All tasks |
search_notes("[status] active") | Active tasks |
search_notes("[status] blocked") | Blocked tasks |
search_notes("[assigned_to] claude") | My tasks |
search_notes("type:Task [blockers]") | Tasks with blockers |
schema_validate(noteType="Task") | Validate all tasks against schema |
schema_diff(noteType="Task") | Detect drift between schema and actual task notes |
Guidelines
- One task per unit of work — Don't cram multiple projects into one task
- Externalize early — If you think "I should remember this", write it down NOW
- 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 validate Taskperiodically to catch incomplete tasks
Related skills
How it compares
Use memory-tasks for schema-backed agent task persistence; use plain markdown todos when sessions never hit compaction limits.
FAQ
How does memory-tasks store tasks?
memory-tasks creates notes with type: Task in Basic Memory's schema system, validating against schemas and indexing them in the knowledge graph for post-compaction queries.
When should memory-tasks run a pre-compaction flush?
memory-tasks recommends updating all active tasks with current state before context compaction so progress survives the window reset and can be resumed via graph search.