memory-tasks by basicmachines-co/basic-memory-skills
npx skills add https://github.com/basicmachines-co/basic-memory-skills --skill memory-tasks使用基础记忆(Basic Memory)的架构系统管理工作进度。任务就是带有 type: Task 的笔记——它们存在于知识图谱中,根据架构进行验证,并在上下文压缩后得以保留。
任务使用 BM 架构系统(SPEC-SCHEMA)。架构笔记位于 memory/schema/Task.md:
---
title: Task
type: schema
entity: Task
version: 1
schema:
description: string, 需要完成什么
status?(enum): [active, blocked, done, abandoned], 当前状态
assigned_to?: string, 谁在处理此任务
steps?(array): string, 完成任务的步骤顺序
current_step?: integer, 当前进行到哪一步(从1开始计数)
context?: string, 记忆丢失后恢复所需的关键上下文
started?: string, 工作开始时间
completed?: string, 工作完成时间
blockers?(array): string, 阻碍进展的因素
parent_task?: Task, 如果这是子任务,则指向父任务
settings:
validation: warn
---
当工作符合条件时,创建一个任务笔记。使用 并指定 ,将可查询的字段放入 :
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
write_notenote_type="Task"metadatawrite_note(
title="描述性任务名称",
directory="tasks",
note_type="Task",
metadata={
"status": "active",
"priority": "high",
"current_step": 1,
"steps": ["第一步", "第二步", "第三步"]
},
tags=["task"],
content="""# 描述性任务名称
## 观察
- [description] 简要说明需要完成什么
- [status] active
- [assigned_to] claude
- [current_step] 1
## 步骤
1. [ ] 第一个具体步骤
2. [ ] 第二个具体步骤
3. [ ] 第三个具体步骤
## 上下文
未来接手此工作的你需要知道的信息。包括:
- 涉及的关键文件路径和代码库
- 已做出的决定及其原因
- 已尝试的方法以及哪些有效/无效
- 查找相关上下文的途径"""
)
为什么同时需要 frontmatter 和观察字段? metadata 中的字段(存储为 frontmatter)支持使用 metadata_filters 进行 search_notes 查询。作为观察的字段(如 - [status] active)支持 schema_validate。将可查询字段放在两个地方以确保全面覆盖。
parent_task [[其他任务]], related_to [[某个笔记]]note_types 区分大小写——write_note(note_type="Task") 会将类型以小写 task 存储在 frontmatter 中。在搜索查询中使用 note_types=["task"](小写)。在会话开始或压缩后:
搜索活动任务:
search_notes(note_types=["task"], status="active")
阅读任务笔记以获取完整上下文
从 current_step 恢复,使用 context 字段
随着进展更新——递增 current_step,更新上下文,勾选已完成的步骤
随着工作进展,更新任务笔记:
## 步骤
1. [x] 第一步 —— 已完成,结果是 X
2. [x] 第二步 —— 已完成,因为 Y 改变了方法
3. [ ] 第三步 —— 接下来要做
## 上下文
反映当前状态的更新上下文...
同时更新 frontmatter:
current_step: 3
完成后:
status: done
completed: YYYY-MM-DD
添加关于完成内容和任何后续需要的简要总结。
当压缩事件即将发生时:
search_notes(note_types=["task"], status="active")current_step 以反映实际进度context 包含恢复工作所需的一切信息借助 BM 的架构系统,任务可以完全查询:
| 查询 | 查找内容 |
|---|---|
search_notes(note_types=["task"]) | 所有任务 |
search_notes(note_types=["task"], status="active") | 活动任务 |
search_notes(note_types=["task"], status="blocked") | 受阻任务 |
search_notes(note_types=["task"], metadata_filters={"assigned_to": "claude"}) | 我的任务 |
search_notes("blockers", note_types=["task"]) | 存在阻碍的任务 |
schema_validate(noteType="Task") | 根据架构验证所有任务 |
schema_diff(noteType="Task") | 检测架构与实际任务笔记之间的差异 |
active 状态parent_task [[X]] 或关系来连接相关工作schema_validate(noteType="Task") 以捕获不完整的任务每周安装量
31
代码库
GitHub 星标数
6
首次出现
2026年2月22日
安全审计
安装于
codex27
claude-code25
github-copilot25
kimi-cli25
gemini-cli25
cursor25
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.
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
---
When work qualifies, create a task note. Use write_note with note_type="Task" and put queryable fields in metadata:
write_note(
title="Descriptive task name",
directory="tasks",
note_type="Task",
metadata={
"status": "active",
"priority": "high",
"current_step": 1,
"steps": ["First step", "Second step", "Third step"]
},
tags=["task"],
content="""# Descriptive task name
## Observations
- [description] What needs to be done, concisely
- [status] active
- [assigned_to] claude
- [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 context"""
)
Why both frontmatter and observations? Fields in metadata (stored as frontmatter) power search_notes with metadata_filters. Fields as observations (- [status] active) power schema_validate. Include queryable fields in both places for full coverage.
parent_task [[Other Task]], related_to [[Some Note]]note_types is case-sensitive — write_note(note_type="Task") stores the type as lowercase task in frontmatter. Use note_types=["task"] (lowercase) in search queries.On session start or after compaction:
Search for active tasks:
search_notes(note_types=["task"], status="active")
Read the task note to get full context
Resume fromcurrent_step using the context field
Update as you progress — increment current_step, update context, check off steps
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: 3
When done:
status: done
completed: YYYY-MM-DD
Add a brief summary of what was accomplished and any follow-up needed.
When a compaction event is imminent:
search_notes(note_types=["task"], status="active")current_step to reflect actual progresscontext with everything needed to resumeWith BM's schema system, tasks are fully queryable:
| Query | What it finds |
|---|---|
search_notes(note_types=["task"]) | All tasks |
search_notes(note_types=["task"], status="active") | Active tasks |
search_notes(note_types=["task"], status="blocked") | Blocked tasks |
search_notes(note_types=["task"], metadata_filters={"assigned_to": "claude"}) | My tasks |
search_notes("blockers", note_types=["task"]) | Tasks with blockers |
activeparent_task [[X]] or relations to connect related workschema_validate(noteType="Task") periodically to catch incomplete tasksWeekly Installs
31
Repository
GitHub Stars
6
First Seen
Feb 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex27
claude-code25
github-copilot25
kimi-cli25
gemini-cli25
cursor25
通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南
43,100 周安装
schema_validate(noteType="Task")| Validate all tasks against schema |
schema_diff(noteType="Task") | Detect drift between schema and actual task notes |