Team memory

Team memory in Prometheus is shared the same way you already share code: over git. Curated and explicitly-shared memories live as committed markdown files under .prometheus/memories/. That is the entire mechanism — there is no memory server, and Supabase stores no memory.

Three places, clear roles

Because shared memory is just files in your repo, it inherits git's semantics for free: feature-branch knowledge stays on the branch, a merge promotes it into the team's memory, and a revert removes it. The pull request is the review gate — curated knowledge is diffable, correctable, and deletable like any code.

Turning sharing on

By default .prometheus/ is gitignored, so your memory is private and local. To share the memories folder with your team, add the exception to .gitignore:

.prometheus/*
!.prometheus/memories/

Then commit the folder. The memory server's status tool tells you which mode you are in ("team sharing ON/OFF"). Turning sharing off again is just removing the exception — local memory keeps working either way.

What becomes a shared file — and what never does

A record is written to .prometheus/memories/ only when it is meant to be shared:

• Curated knowledge — facts and procedures distilled from your sessions (see Session recorder).
• Explicitly promoted — a memory_write with share: true.
• Hand-written — you create or edit a file yourself.

These are always project-scoped semantic or procedural records. What is never written to a file: working notes, episodic records (including session summaries), the raw session recorder, and anything outside the project scope. That is the boundary — a file is shared; the local DB is private. On read, each record is tagged with its origin (file for shared, local for private).

File format

Each file is one record with a small, tolerant YAML frontmatter:

---
type: semantic
tags: [payment, api]
confidence: 0.8
updated: 2026-07-10
source: curated:session:abc123
---

The payment provider needs idempotency keys, or you get double charges.

Frontmatter is optional — a file without it is read as a plain semantic record, so older mirror files need no migration. Provenance in source is a hint; git blame stays authoritative.

Safety

Every file is secret-scanned on ingest: a file whose body matches the credential deny-list is skipped, never ingested, and surfaced in status/read (never silently). Combined with the write-time reject and the recorder's redaction, that is three independent layers keeping secrets out of shared memory — but the usual rule still holds: never commit secrets, in memory files or anywhere else.

A quick walkthrough

Anna is on a feature branch. As she works, the recorder captures her session and curation distils a durable fact — "the new webhook must be verified with the X-Signature header" — into .prometheus/memories/webhook-signature.md on her branch. Her teammates on main don't see it yet. When her PR merges, the file travels with it: now everyone's next memory_read picks it up. If the approach is later reverted, the file goes with the revert — and so does the memory.