菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/FirefoxCSS-Store/FirefoxCSS-Store.github.io --skill memory-tasks命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | memory-tasks |
| description | 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. |
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, ]
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 from current_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 |
schema_validate(noteType="Task") | Validate all tasks against schema |
schema_diff(noteType="Task") | Detect drift between schema and actual task notes |
activeparent_task [[X]] or relations to connect related workschema_validate(noteType="Task") periodically to catch incomplete tasks