Files
Paul Hernandez 5458c35b35 refactor(plugins): prefix Claude Code plugin skills with bm- (#878)
Signed-off-by: phernandez <paul@basicmachines.co>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-04 12:04:05 -05:00

2.0 KiB

title, type, entity, version, schema, settings
title type entity version schema settings
Session schema Session 1
summary? context?(array) next_step?(array) decision?(array) problem?(array) produced?(array)
string, one-paragraph what-happened this session string, key context needed to resume after memory loss string, explicit cursor for the next session string, decisions surfaced during the session string, problems hit — including attempted-and-rejected approaches Entity, notes created or updated during the session
validation frontmatter
warn
project started ended? status?(enum, lifecycle of the checkpoint) cwd? claude_session_id? capture?(enum, how this checkpoint was produced)
string, the Basic Memory project this session belongs to string, when the session began (ISO timestamp) string, when the session was checkpointed
open
resumed
closed
string, the working directory the session ran in string, Claude Code session identifier
extractive
summarized

Session

A SessionNote is a resume checkpoint written by the Basic Memory plugin's PreCompact hook (and, later, the /basic-memory:bm-handoff command) right before Claude Code compacts the context window. It records what the session was doing so the next session can pick up where this one left off.

Sessions are found by the SessionStart hook via structured recall: search_notes(metadata_filters={"type": "session"}, after_date="3d").

What goes in a SessionNote

  • summary — a short paragraph of what happened (richer once summarized checkpoints replace the extractive first cut).
  • context / next_step — the cursor: what's in flight and what to do next.
  • decision / problem — choices made and dead-ends hit, so the next session doesn't repeat them.
  • produced — relations to the notes this session created or changed.

Frontmatter

type: session and status are the queryable fields that power recall. warn validation means a missing field is surfaced, never blocking — the user's flow is never gated on schema conformance.