Chat Recall Memory

---
name: chat-recall-memory
description: >-
  Store and recall durable facts, decisions, and notes with chat-recall's
  knowledge graph and diary. Use when the user says "remember this", "note that
  we decided…", "what do you know about X", "did we decide Y", "what's our
  convention for Z", or when a non-obvious decision/preference is made that future
  sessions should know. Covers the temporal knowledge graph, decision records,
  the agent diary, and a scoped key/value store.
---

# Durable memory with chat-recall

Two directions: **recall** what's already known, and **record** new facts so
future sessions inherit them.

## Recall what's known

- `recall_kg_query` — query an entity's relationships (facts
  with validity windows). `as_of: <date>` time-travels to what was true then.
  Use to VERIFY before asserting a fact ("did we decide to use Postgres?").
- `recall_kg_timeline` — chronological story of an entity (or
  everything). `recall_kg_stats` — graph overview.
- `recall_wake_up` — high-importance facts + KG snapshot for a
  fast "what's true right now".
- `recall_diary_read` — prior agent diary entries (narrative
  notes across sessions). `recall_get` — a scoped key/value.

## Check what is already decided (do this BEFORE you choose)

- `recall_decisions` — the decision register, cascade already
  resolved: one value per area (auth, database, payments, deploy, pricing,
  licensing…), what it replaced and when, and the session behind it. Call it
  before picking a library, a datastore or an auth method. If the area is
  already decided, follow it or say plainly that you are proposing a reversal.
  It also returns `gaps` — areas nobody has decided, where you are free to
  choose and should record the choice afterwards.

  Project overrides beat account-wide decisions. A personal preference is
  returned marked `advisory` and never overrides a team decision.

- `recall_decision_scan` — what THIS repository's manifests
  say its stack is, beside what the register currently answers. The register is
  push-only and never reads a repository, so a project that never had the
  conversation inherits an answer from a broader scope — which is how an app
  whose store is `rusqlite` came to be told its database decision was Postgres.
  Run it when a decision card asks you to record an area, and before recording
  one yourself. It names the product that answers each area with the file and
  line it read: that is EVIDENCE, not a decision — it says what is there, never
  what was ruled out or why.

  `record: true` writes the areas the manifests answer, at project scope, with
  that file and line as the reason. It never writes an area with more than one
  candidate, and it never writes one the manifests are silent about. For those,
  ask the user and record their answer in their words.

## Record new knowledge (do this when something non-obvious is decided)

- `recall_decision_record` — an explicit decision (subject,
  decision, reason, importance). **Pass `area`**: it is the key a reversal
  supersedes on, so recording a new `auth` decision closes the previous one and
  leaves every other area alone. Without it nothing the decision contradicts is
  closed. Shows up in future wake-up context. Use the moment you and the user
  agree on something a later session would need.
- `recall_kg_add` — assert a fact triple
  (subject → predicate → object, optional `valid_from`). E.g.
  `("chat-recall", "uses", "Postgres")`.
- `recall_kg_invalidate` — mark a fact no longer true when a
  decision is reversed or a tool is replaced (keeps the graph honest).
- `recall_diary_write` — narrative notes ("what I learned /
  what matters") keyed per agent, across sessions.
- `recall_set` — small structured state (current PR url,
  branch, preferred test runner); `scope` namespaces per project.

## When to record

Record when a decision or preference is (a) non-obvious, (b) not already captured
by the code/CLAUDE.md/git history, and (c) useful to a future session. Prefer
`recall_decision_record` for choices with a rationale, `recall_kg_add` for plain
entity-relationship facts, `recall_diary_write` for narrative context, `recall_set`
for transient pointers. Don't duplicate what the repo already records.

## Verify-then-assert

Before stating "we decided X" or "we use Y", confirm with `recall_kg_query`
(and `as_of` if the timing matters) rather than relying on memory.