Linksee Memory

Persist knowledge across sessions and AI tools (Claude, GPT, Cursor, Codex, Gemini). The only cross-agent memory that survives session boundaries. WHEN TO CALL: • The moment an error or failure occurs → layer: "caveat" (auto-protected, never forgotten) • When a decision is made or approved → layer: "learning" • When a goal is set or updated → layer: "goal" • When something new is learned → layer: "learning" • When the user says "remember this" / "覚えておいて" • After completing a task or receiving user approval REQUIRED PARAMS BY MODE: • Create (default): entity_name + entity_kind + layer + content • Update: memory_id (+ optional content, layer, importance) • Delete: memory_id + forget: true Importance ≥ 0.9 pins the memory (protected from auto-forgetting). Supports Japanese (日本語) and English.

Your persistent memory across all AI tools. CALL THIS BEFORE STARTING ANY TASK to check for past caveats (pain records), decisions, and learnings — prevents repeating mistakes across sessions. Typical usage: recall({ query: "keywords" }) for search, recall({ path: "file.ts" }) for file history, recall() for overview. WHEN TO CALL: • Before starting any new task or touching a file • When the user mentions "before" / "前に" / "last time" / "remember when" • When an error occurs — check if you've seen it before • When making a decision — check for prior decisions on the same topic THREE MODES (auto-detected): • Search (default): provide query → returns memories ranked by relevance + heat • File history: provide path → returns complete edit history with user-intent context • Overview: omit all params → returns entity list sorted by momentum Works across Claude, GPT, Cursor, Codex, Gemini — one local SQLite file, nothing leaves your machine.

Token-saving file reader with AST-aware diff caching. Use INSTEAD of the standard Read tool for ALL file reads — even first reads gain chunk metadata for future savings. • First read: full content + chunk metadata (enables future savings) • Re-read unchanged: ~50 tokens (99% savings) • Re-read modified: only changed chunks (50-90% savings) Especially effective for files >200 lines. Always prefer this over Read.

Check what's drifting right now — the "Intent Datadog" for your product decisions. Returns a structured truth map showing which decisions/constraints/hypotheses are: 🔴 drift (unaccounted divergence from intent) 🟡 review (soft signal, awaiting human decision) ⚪ held (acknowledged, time-boxed, not forgotten) 🔵 aligned (reality matches intent) Nodes are classified into 4 species: • hypothesis → Decision Cards (decision journal format) • constraint → Rules (pass/fail checklist) • commitment → Heartbeats (cadence monitoring) • source_of_truth → Reference (stable anchors) WHEN TO CALL: • At session start — "what needs my attention?" • Before making a decision — check for existing anchors on the topic • After completing work — verify drift state changed • When the user asks about product health / what's broken / what's stale

Locate the current topic on the Current Truth Map and report "you are here" + blast radius — the per-turn re-anchor. Returns the matching Map node(s) + journey stage (discover → … → expand), the BLAST RADIUS (what becomes suspect if you change this — the must-stay-consistent-with / should-align-with / realizes dependents; e.g. editing the README implicates the LP), and the decision behind the node (linked anchor), if any. Three ways to call: • NO ARGS → auto-locates from the files you JUST edited this session (the zero-effort re-anchor — call it freely as you work). • query: "<topic>" → lexical locate by topic. • node_id: "<id>" → exact node. This is how you avoid optimizing one node while silently breaking its neighbors (change the spec → npm/Docs/LP must move too). Matching is lexical (no embeddings). WHEN TO CALL: • Right after editing files — call with no args to see what you just touched + its blast radius. • When the topic shifts — re-anchor to the new node. • When the user asks "what does changing X affect?" / "where does this fit?"

Deep-dive into a specific decision/anchor — its state, premises, drift edges, and pending candidates. Returns the full context for one truth-map node: what was decided, why, what reality says, whether it's drifting, and what actions are pending. WHEN TO CALL: • When the user asks about a specific decision ("what happened with X?") • Before resolving a drift signal — understand the full picture first • When reviewing premises of a decision ("is this still true?")

Declare a new decision, constraint, or prohibition as a truth-map anchor. Anchors are NORMATIVE claims: "we decided X", "Y is forbidden", "Z must always hold." The drift detector later checks these against committed reality. declare-don't-mine: anchors come ONLY from explicit human declaration, never from pattern extraction. WHEN TO CALL: • When the user makes a product decision ("let's go with approach A") • When a constraint is established ("never do X") • When a commitment is made ("we ship weekly") • When the user says "anchor this" / "record this decision"

Record a resolution for a drifting anchor — the human feedback loop. 6 actions: • fix — "we fixed the code/reality to match intent" → state becomes aligned • supersede — "intent evolved, this is the new direction" → state becomes aligned • acknowledge — "we know, parking it for now" → state becomes held (with optional review date) • dismiss — "false positive, not actually drifting" → edges dismissed • harden — "re-injected but still violated, enforce it" → card_policy.gate_mode=hard (PreToolUse will BLOCK) • soften — "back off to a warning" → gate_mode=soft WHEN TO CALL: • After drift_status shows 🔴 drift or 🟡 review items • When the user says "that's fixed" / "ignore that" / "we changed direction" • When acknowledging a known gap with a review date

Record orphaned proposals — options you presented that the user never addressed. Conversations are tree-shaped but experienced linearly. When you present 3 options and the user engages with only 1, the other 2 become "orphaned proposals" — unresolved decision branches that both you and the user lose track of. WHEN TO CALL: • When you notice the user engaged with only some of the options you presented • When the conversation shifted topic and earlier proposals were never resolved • At session end, review what you proposed vs what was addressed • When the user says "what else did we discuss?" or "何か忘れてない？" Each proposal becomes a review-state anchor on the dashboard — visible until the user decides. This is declaration, not mining: YOU are the curator recognizing what went unaddressed.

Dreaming Memory — consolidate orphaned proposals against the North Star. Returns the project's North Star (direction/goals/ICP/phase) alongside unresolved proposals that agents flagged during conversations. YOUR job as the evaluating agent is to decide: • surface — genuinely important unresolved fork point given the current direction • dismiss — outdated, already implicitly resolved, or irrelevant to current goals Think like a General Doctor doing triage: the North Star is the patient's chart, each proposal is a symptom. Not every symptom needs treatment. WHEN TO CALL: • At session start to triage accumulated proposals • When the user asks "何か見落としてない？" or "what should we revisit?" • Periodically to prevent proposal backlog from growing stale After evaluation, call resolve_proposal for each candidate with your verdict. ALSO RETURNS: `distill_queue` — auto-captured memories whose content is still a RAW user utterance. Rewrite each via remember(memory_id, content) per the guide in the response (one-line what, true why, "distilled": true). Drain up to 8 per call — the SessionStart digest reminds you while the queue is non-empty. And `friction` — anchors re-surfaced at the gate yet still contradicted (resolve_drift action:"harden" to enforce).

Record your evaluation verdict for an orphaned proposal after dreaming. Call this after `dream` for each candidate you evaluated against the North Star. • surface — Keep visible on dashboard for human decision • dismiss — Remove from dashboard (outdated/irrelevant/implicitly resolved) Always reference the North Star criteria in your rationale.