using-memorylisted

# Using memory This project's **volatile** knowledge — how the user wants to work, feedback, current project state, references — lives in a SQLite-canonical memory store (`ultra-memory`). The verbs enforce the rules; this skill teaches you which path to use and what never to do. ## What memory is / is not - **Memory** = volatile, fast-moving facts: user preferences, feedback directives, current project state, references. Rule of thumb: *how the user wants to work* → memory. - **Not** the durable domain knowledge base. If a wiki skill is co-installed (e.g. `using-trading-knowledge`), *what we learn about the domain* → there, not here. ## READ paths 1. **Ambient (already injected — do not re-fetch):** on every SessionStart the rehydration gist (pinned rules + where-we-left-off + open follow-ups + hot memories) is injected into your context. It is already there; do not call recall just to get it. 2. **Trusted / full recall:** `/ultra-memory:memory-recall "<query>"` → JSON `{title, snippet, score, id, stale, links}`. This is the human/orchestrator path (full type access). Field semantics: - `stale: true` ⇒ `last_verified` is older than the staleness window ⇒ consider `/ultra-memory:memory-verify` after reconfirming. - `links` ⇒ 1-hop outbound references; follow them for related context. - `score` is title-boosted (NOT raw cosine) — treat as a relative rank, not a probability. 3. **Scoped recall (subagents / crons):** the `knowledge` MCP `knowledge_query` tool. **Privi