Brian Storage
Store memories, documents, and extracted facts — type selection, salience, tagging, supersession.
Description
Prerequisites
- Brian connected
Install in Claude
Download
Sign in, then click Download. You'll get a zip with the skill folder inside.
Upload to Claude
In Claude, go to Settings → Capabilities → Skills → Add custom skill. Upload the zip you just downloaded.
Test it
Try a prompt that should trigger the skill — Brian's docs and the description above show what activates Brian Storage.
Skill content
name: brian-storage description: How to store memories, documents, and extracted facts in Brian. Covers memory type selection, salience assignment, tagging, store_document routing, and supersession.
brian-storage
How to store memories, documents, and extracted facts in Brian.
When to use
Any conversation where durable information surfaces: decisions made, facts established, documents produced, preferences stated, instructions given. If it would be useful in a future session, store it now.
Choosing the right tool
store_memory — one specific fact
Use when you know exactly what to store and what type it is. One memory per call.
extract_memories — multiple facts from a block of text
Use for long user messages, meeting notes, or any input with multiple distinct facts. Run with save: false first to preview if unsure — this returns candidates without storing them. Uses an LLM to classify types and assign salience automatically.
store_document — file artifacts
Use for reports, specs, data files, or any content too long or structured to be a single memory. Goes to Supabase Storage (immutable blob) and optionally to Google Drive. Creates a document memory as the pointer. Automatically chunks and embeds the content for semantic search.
Memory types
| Type | Use | Retrieval boost |
|---|---|---|
truth | Durable facts about the user or their world | +1 |
instruction | Standing orders for Claude's behaviour | +1 |
intent | Goals and plans — close with outcome when resolved | — |
state | Current status of something that changes — supersede when it changes | — |
event | Things that happened at a point in time — never update, add new events | — |
preference | How the user likes things done | — |
outcome | Results after a decision or event — links to original intent | — |
document | Created by store_document or index_drive_file — rarely manual | — |
snapshot | Created by snapshot_dataroom — rarely manual | — |
Types are enforced server-side. The enum is: truth, intent, state, event, preference, instruction, outcome, document, snapshot.
Salience assignment
| Score | Use for |
|---|---|
| 1.0 | Core identity facts, critical standing instructions |
| 0.8 | Important truths, strong durable preferences |
| 0.6 | Project details, useful context (routine cap) |
| 0.4 | Minor preferences, background |
| 0.2 | Ephemeral notes, low-priority signals |
Default is 0.5 if not specified. Reserve 0.8-1.0 for things that should almost always surface in retrieval. Salience contributes up to 2 points in scoring.
Tagging conventions
Lowercase, hyphenated, 2-5 tags per memory. Tags are matched as keywords in retrieval scoring — they directly improve recall.
Good tags: tech-stack, q2-goals, brian-mcp, investor-pitch, energy-model
Bad tags: important, note, user, misc
Pinning rules
Pin: identity facts (truth, salience 1.0), standing instructions (instruction, salience 1.0), critical reference documents.
Do not over-pin. Pinned memories get +3 retrieval score — if too many are pinned, they crowd out dynamically relevant results.
Writing standalone statements
Memories must make sense without the original conversation. They will be retrieved months later by different conversations.
Good: "User prefers TypeScript over JavaScript for all new projects" Bad: "The user said they like TS"
Good: "Brian MCP pricing changed to $35/month effective April 15, 2026. Previously $25/month." Bad: "The price changed"
store_document details
Content type routing
| content_type | Storage | Drive upload |
|---|---|---|
markdown_doc | Supabase blob + Drive (as native Google Doc) | Yes |
json_data | Supabase blob only | No |
soul_definition | Supabase blob only | No |
session_context | Supabase blob only | No |
spreadsheet | Supabase blob + Drive | Yes (not chunked) |
presentation | Supabase blob + Drive | Yes (not chunked) |
word_doc | Supabase blob + Drive | Yes (not chunked) |
Content type is auto-detected from filename and content if not specified.
Drive path
Default: "Brian/Data Room". Override for project-specific organisation: "Brian/Marketing", "Brian/Development/Specs", etc.
Deduplication
Content-hash deduplication runs across ALL spaces for the user:
- Exact match (same SHA-256 hash): skips entirely, returns existing memory ID
- Same filename in same space: supersedes the old version (old memory gets
superseded_bylink, old chunks deleted)
Chunking
Text documents are automatically chunked and embedded after storage:
- Markdown: split on
##and###headings - Other text: 400-word fixed windows
- Chunks under 20 words are merged with adjacent chunks
- Each chunk gets a vector embedding (text-embedding-3-small)
- Spreadsheets, presentations, and Word docs are NOT chunked
Supersession
update_memory mutates in place — it changes the content/type/salience/tags/pinned on the existing memory and re-embeds if content changed. It does NOT create a new memory or set a superseded_by link.
For true supersession (keeping the old version linked to the new), store a new memory and separately update the old one's tags to indicate it's been replaced. The superseded_by field exists in the schema but is only automatically set by store_document when a file with the same name is re-uploaded.
No content length limit
There is no enforced maximum on store_memory content length. The database column is text (unlimited). However, very long content should use store_document instead — it gets chunked and embedded for better retrieval.
Release notes
Initial drop.