memory-tasks について
memory-tasks は、Basic Memory のスキーマシステムで進行中の作業を管理するスキルです。タスクを検索・検証可能なナレッジグラフのノートとして保存し、コンテキスト圧縮や再起動後に再開できます。
主な機能
- 01状態とメタデータ付きタスクの作成
- 02状態や項目によるタスク検索
- 03手順、コンテキスト、期限の記録
- 04スキーマによるタスク検証
- 05チェックサムによる編集競合の防止
活用シーン
- 01複数段階の作業の分割と追跡
- 02コンテキスト圧縮後のタスク再開
- 03圧縮前の進捗保存
- 04ブロック中や期限間近のタスク検索
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ basicmachines-co/ basic-memory --skill memory-tasksインストール後、Claude Code で/memory-tasksを入力して読み込まれたか確認します。
詳細
メモリータスク
Basic Memory のスキーマシステムを使って、進行中の作業を管理します。タスクは type: Task を持つ単なるメモです。ナレッジグラフに保存され、スキーマに照らして検証され、コンテキストが圧縮されても残ります。
使用するタイミング
- 複数段階の作業を始めるとき(3 ステップ以上、またはコンテキストウィンドウを超えて続く可能性がある作業)
- 圧縮/再起動後 — アクティブなタスクを検索して再開します
- 圧縮前のフラッシュ — すべてのアクティブなタスクを現在の状態に更新します
- 必要に応じて — ユーザーからタスクの作成、確認、管理を依頼されたとき
タスクスキーマ
タスクでは BM スキーマシステムを使用します。スキーマメモは schema/Task.md にあります。
---
title: Task
type: schema
entity: Task
version: 1
schema:
description: string, what needs to be done
status?(enum, current state): [active, blocked, done, abandoned]
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
---
タスクの作成
作業が該当する場合は、タスクメモを作成します。note_type="Task" を指定して bm_write を使い、クエリ可能なフィールドを metadata に入れます。
bm_write(
title="Descriptive task name",
directory="tasks",
note_type="Task",
metadata={
"status": "active",
"priority": "high",
"assigned_to": "claude",
"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"""
)
frontmatter と観察事項の両方に記載する理由は? metadata 内のフィールド(frontmatter として保存)は、filters を使った bm_search を可能にします。観察事項として記載したフィールド(- [status] active)は、bm_schema(command="validate") を可能にします。両方にクエリ可能なフィールドを含めると、網羅的に扱えます。
主な原則
- ステップは具体的で確認可能なものにします — 「ファイル Y で X を実装する」とし、「いろいろ調べる」とはしません
- コンテキストは、記憶が失われた後に作業を再開するためのものです — これまでの作業を何も知らない聡明な人に説明するつもりで記述します
- 関連付けで他のエンティティとつなぎます —
parent_task [[Other Task]]、related_to [[Some Note]] - メモの種類は snake_case に正規化されます —
bm_write(note_type="Task")はtype: taskとして保存されます。また、note_types=["Task"]とnote_types=["task"]はどちらも一致します。
圧縮後の再開
セッションの開始時または圧縮後に、次の手順を実行します。
-
アクティブなタスクを検索します。
bm_search(note_types=["task"], filters={"status": "active"}) -
タスクメモを読み取り、コンテキスト全体を確認します
-
contextフィールドを使って、current_stepから再開します -
進捗に応じて更新します —
current_stepを増やし、コンテキストを更新して、完了したステップにチェックを付けます
タスクの更新
作業の進行に応じて、タスクメモを更新します。
## 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...
まずタスクを JSON として読み取り、編集のたびにそのチェックサムを expected_checksum として渡します。たとえば圧縮前のフラッシュ時など、2 つのセッションが同じタスクを更新することがあります。リビジョンの競合は、もう一方が先に書き込んだことを意味するため、書き込む前に再度読み取ってください。
command="set_metadata" と metadata パラメーターを使って、frontmatter も更新します(本文は変更されません)。
task = bm_read(identifier="tasks/descriptive-task-name", output_format="json")
bm_edit(
identifier="tasks/descriptive-task-name",
command="set_metadata",
metadata={"current_step": 3},
expected_checksum=task["checksum"]
)
タスクの完了
完了したら、次の操作を行います。
status: done
completed: YYYY-MM-DD
達成した内容と、必要なフォローアップを簡潔にまとめます。
圧縮前のフラッシュ
圧縮イベントが迫っているときは、次の手順を実行します。
- アクティブなタスクをすべて探します:
bm_search(note_types=["task"], filters={"status": "active"}) - 各タスクについて、次の項目を更新します。
- 実際の進捗を反映するように
current_stepを更新します - 再開に必要な情報をすべて
contextに記載します - 完了したステップが分かるようにチェックボックスを更新します
- 実際の進捗を反映するように
- 書き留めていないコンテキストは、圧縮時に失われます
タスクのクエリ
BM のスキーマシステムを使うと、タスクを自在にクエリできます。
| クエリ | 検索される内容 |
|---|---|
bm_search(note_types=["task"]) | すべてのタスク |
bm_search(note_types=["task"], filters={"status": "active"}) | アクティブなタスク |
bm_search(note_types=["task"], filters={"status": "blocked"}) | ブロック中のタスク |
bm_search(note_types=["task"], filters={"assigned_to": "claude"}) | 自分のタスク |
bm_search("blockers", note_types=["task"]) | ブロッカーのあるタスク |
bm_search(note_types=["task"], time_kind="due", valid_overlaps="[2026-10-14,2026-10-21)") | 今週期限のステップがあるタスク |
bm_schema(command="validate", note_type="Task") | すべてのタスクをスキーマに照らして検証 |
bm_schema(command="diff", note_type="Task") | スキーマと実際のタスクメモの差異を検出 |
期限
ステップまたはタスクに、修飾子付きの期限を設定します(memory-notes を参照)。そうすれば、「期限が来ているもの」を 1 回の検索で調べられます。
- [deadline] @due:2026-10-20 Draft ready for review
日単位の精度で指定した期限は、その日以降のものとして扱われるため、今週が期限のタスクを検索すると、期限超過の項目も返されます。
ガイドライン
- 作業単位ごとにタスクは1つ — 複数のプロジェクトを1つのタスクに詰め込まないでください
- 早めに外部化する — 気づいたことはすぐに書き留めてください
- 手順よりコンテキストを重視する — 手順は何をすべきかを示し、コンテキストはその理由と方法を伝えます
- 完了したタスクを閉じる — 完了した作業を
activeのままにしないでください - 関連するタスクをリンクする —
parent_task [[X]]または関連付けを使って、関連する作業をつなげてください - スキーマ検証を活用する —
bm_schema(command="validate", note_type="Task")を定期的に実行し、不完全なタスクを見つけてください