Standalone citation-first repository memory Skill, CLI, MCP server, and local L0-L3 runtime
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (memory_*). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. However, parameter descriptions lack specificity on constraints, formats, and error recovery. Output schemas are not documented. Error handling guidance is minimal. Tool composition is sound but lacks pagination/limit enforcement on search results.
Inspect the server-configured repository sources, adapters, freshness, and index state. Omit root unless an explicit verified Git root is required. Set local=true to avoid remote snapshot fetches and no_index=true for a metadata-only fast probe.
Resolve a memory result and its source evidence. Pass the result citation commit and line_start/line_end when pinning the exact evidence window.
Observe durable local memory events without ranking or generating a conclusion. This is provenance, not repository evidence, and is read-only.
Generate a bounded, candidate-labelled reflection over local memory. It is a derived aid, not an accepted fact; inspect citations before reuse.
Answer anything about this project, its history, past conversations, or prior team decisions — pass the user's question verbatim. Returns Git-cited repository evidence as the answer surface, plus conversation memory and team decisions as separate groups. Use `answerable`/`results` for claims; if empty, abstain. `abstain` describes the repository plane only — check `answered_by` before giving up, and answer from that plane's group when it is listed. See references/result-contract.md for the full contract.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing response structure. memory_search, memory_get, memory_timeline, memory_observe, memory_reflect all lack documented return types.
Parameter descriptions lack format/constraint details. 'root' is described as 'Optional verified Git repository root' but no guidance on format (absolute path? relative? must exist?). 'limit' has min/max but no explanation of what happens when exceeded.
No error recovery guidance. Descriptions do not explain what to do if a tool fails (e.g., 'If root is invalid, try omitting it' or 'If search returns empty, check scope parameter'). Agents have no fallback strategy.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2025-06-18+ | v2 |
Fetch remote snapshots and update derived indexes without changing the worktree. Uses the server-configured root by default.
Read the ordered L0/L1 trace for a session from the active local memory runtime. This is diagnostic provenance, not repository evidence, and never changes canonical Git data.
memory_search accepts 'limit' (1-50) but no pagination/cursor mechanism documented. Returning 50 results in one call may exhaust context; no guidance on how to fetch next batch.
Tool composition risk: memory_search returns results with 'answered_by' field that directs agent to other planes, but no documented structure for 'results' or 'abstain' fields. Agents cannot reliably parse responses.