recall

name	recall
description	Save durable project knowledge to Mission Control's Recall (project memory) so future sessions start already knowing it. Use when you discover or decide something worth remembering about THIS project — an architecture fact, a decision and its rationale, a convention, a stack detail, a glossary term, a known issue, or a useful discovery ("X lives in Y", "Z is generated"). Requires a Mission Control agent session (MC_API_URL, MC_API_TOKEN, MC_TASK_ID are injected automatically). Not for transient to-dos, run-specific notes, or projects running outside Mission Control.
user-invocable	true

Mission Control agent sessions receive env vars automatically:

• MC_API_URL — loopback API base (e.g. http://127.0.0.1:54321)
• MC_API_TOKEN — bearer token for that API
• MC_TASK_ID — the active task/session id

Mission Control maintains Recall, a curated, per-project memory that it assembles into a Session Brief and hands to every new session. When you learn something durable about this project, write it back so the next session doesn't rediscover it.

Skip this entirely when the MC env vars are missing (plain shell outside Mission Control).

When to save a memory

Save a memory when you establish a durable fact about the project — not about the current task:

• decision — a choice that was made and why ("Use JWT instead of session cookies — stateless across the worker fleet")
• architecture — where things live / how data flows ("Auth flow lives in useAuth")
• convention — a project-specific pattern or do/don't ("All API errors go through handleDomainError")
• stack — a language/framework/build/runtime/infra fact
• glossary — a domain term and its meaning
• known-issue — a current limitation, gotcha, or flaky area
• discovery — a useful finding ("Migrations run on boot from ensureSchema")
• overview / preference — what the project is / how the user likes to work here

Do not save: the task you were asked to do, TODOs, transient state, or anything only true for this one run. Prefer a few high-signal facts over many. Recall dedupes by title, so re-saving a known fact is harmless.

How to save

First resolve the project id from the task, then POST the memory:

# 1. Get the project id for this session.
PROJECT_ID=$(curl -s "$MC_API_URL/api/tasks/$MC_TASK_ID" \
  -H "authorization: Bearer $MC_API_TOKEN" \
  | sed -n 's/.*"projectId":"\([^"]*\)".*/\1/p')

# 2. Save a memory.
curl -s -X POST "$MC_API_URL/api/projects/$PROJECT_ID/memory" \
  -H "authorization: Bearer $MC_API_TOKEN" \
  -H "content-type: application/json" \
  -d '{
    "type": "decision",
    "title": "Use JWT instead of session cookies",
    "body": "Chosen for statelessness across the worker fleet.",
    "source": "agent",
    "confidence": "confirmed"
  }'

Fields

• type (required) — one of overview, stack, architecture, decision, convention, glossary, known-issue, preference, discovery.
• title (required) — a one-line headline. This is what gets injected into future briefs, so make it self-contained (≤ 200 chars).
• body (optional) — a short detail: the why / where / how.
• source — always send "agent" so the memory is tagged as agent-written.
• confidence — "confirmed" when you verified it in the code, "inferred" when you're reasonably sure, "ambiguous" when unsure.
• tags (optional) — a string array for filtering.

A 403 means the user has disabled agent memory writes in Settings → Recall — respect that and stop trying.

Etiquette

• Save at most a handful of memories per session — the highest-signal facts only.
• Keep each memory atomic (one fact per entry).
• Don't echo the whole brief back; only write things that are genuinely new or now more certain.