Skill v1.0.1

version: "1.0.1" name: memory description: >- Triage context-memory candidates mined from past AI coding sessions. Use when the user says "triage memory", "review memory", "mine memory", "/memory", or asks what durable facts their session history contains. Runs the mine, clusters paraphrased candidates, judges which facts generalize beyond the session they came from, and walks approve / reject / snooze, including marking standing constraints always-on and assigning project groups. argument-hint: repo path (optional, defaults to current repo)

Turn mined candidate turns into a small set of durable facts worth remembering.

Steps

1. Run the mine. sessions memory mine --repo <path> --json (omit --repo for the current repo; --all mines every repo in the index; add --since-last to mine only transcripts that changed since the previous mine, which is what the weekly summary uses). stdout is a JSON array of candidate records; progress goes to stderr. If the command is not found, say so and stop — do not substitute a search. If the array is empty, say there is nothing to triage and stop; never invent candidates.

1. Cluster paraphrases. Group candidates whose texts assert the same fact in different words — "use canary as the base branch" and "we branch off canary" are one memory in two phrasings. A cluster's distinctPhrasings is the number of distinct member texts. Keep the clearest phrasing as the cluster's text; the rest are evidence, not separate memory. Byte-identical repeats were already collapsed upstream, so every member you see is genuinely a different wording.

1. Apply the generalizability rubric. For each cluster ask: _does this fact hold beyond the session it appeared in?_ Propose only the clusters that pass.

• Passes — standing constraints ("API keys go in the keychain when available"), repo or tooling facts ("this repo branches off canary", "skills can invoke inline scripts"), architectural rules.
• Fails — one-off task instructions ("make it Ideation instead of docs/ideation", "let's do a single PR"), bug reports ("syntax highlighting isn't loading"), anything naming a specific transient artifact.
• Fails loudly — text that reads like a copy-pasted prompt or eval fixture. A suspiciously boilerplate candidate is chaff, not signal.
• Assign kind: instruction for "do this / don't do that", information for "this is how the world is".

1. Walk triage. One AskUserQuestion per cluster, batching up to 4 independent clusters per call. For each, show the text, the derived scope (repo with its container, or workflow), distinctPhrasings, and the firstSeen–lastSeen range. Options: Approve, Approve as always-on, Reject, Snooze (hide without a verdict).

Offer Approve as always-on only when the fact is a standing constraint an agent must see no matter what it is working on — "canary is the mainline branch", "API keys go in the keychain". Retrieval is topic-conditional by default, so a normal approval means the memory comes back only when the task looks related. Always-on is the exception, and proposing it for everything defeats the filter.

1. Persist. One command per decision, using the cluster's id:

• sessions memory merge <id> <other-id>... — run this first for any cluster with more than one record
• sessions memory approve <id> (add --always-on for a standing constraint)
• sessions memory reject <id>
• sessions memory snooze <id>

Each exits non-zero on an unknown id, so a failure means the decision was not recorded — surface it rather than reporting success.

Merge is not optional bookkeeping. Your clustering in step 2 exists only in this conversation until you write it back. An id is a hash of that record's own text, so every phrasing is a separate row and nothing else can ever tell them apart. merge folds the members' evidence onto the canonical record — distinct phrasings counted, sessions unioned, date range widened — which is what makes distinctPhrasings mean "how many ways the user has said this" instead of a permanent 1. It is also what lets a snoozed memory come back, and what gives the cross-author quorum something real to count. Pick the clearest phrasing as the canonical, pass the rest as members, then approve/reject/snooze the canonical.

If the user says a fact applies to a set of related repos rather than just this one, assign a project group: sessions memory approve <id> --scope group:<name>. Only ask when they volunteer it — group membership comes from ~/.local/share/sessions/groups.json, which the user maintains by hand, and a group they have not configured there is silently never returned. Say so if you assign one.

An imported record needs a repo before it means anything. A record whose scope is repo with an EMPTY key came from someone else's bundle: export strips the local path, and retrieval skips a keyless repo memory rather than letting it match every repo. Approving it as-is succeeds and changes nothing. Bind it in the same command: sessions memory approve <id> --scope repo:. for this repo, or --scope repo:<path> for another (the path is resolved to its repo container, so a worktree or subdirectory works). If the fact is clearly not repo-specific, say so and let the user decide instead of guessing a repo.

1. Report. Proposed count, approved count, and the ratio. That ratio is the number the precision goal is measured on, so state it plainly even when it is bad.

Guidelines

• Propose only what passes the rubric. Dumping every narrowed candidate on the user is the failure mode that trains people to reject the whole list without reading it — a short, high-precision proposal is the point.
• Records already carry a state. Triage the candidate ones and leave approved records alone unless the user asks to revisit them. Rejected and merged records never appear. A record that was snoozed and is back in the batch has resurfaced — its 30 days passed and a merge added a new phrasing since, meaning the user kept saying it in different words. Say so when you present it; that history is the strongest evidence the original dismissal was wrong.
• repo and workflow scope are derived from evidence and are shown, not edited — with one exception each way. group is assignable because no derivation can reach it: the index cannot tell "these four repos share a convention" from "this is universal". repo is assignable only because an imported record has no derivation to override — its key was stripped on export and no local transcript will ever produce it. workflow is never assignable: it is the only direction that widens, and a mistake there turns one repo's convention into a rule for every repo, silently.
• Never paste raw session text you did not get from the batch — records deliberately carry no verbatim quotes.
• Snooze means "not now, but keep watching". A snoozed memory returns once 30 days have passed and a later merge folds in a phrasing that was not there before — continued repetition is treated as evidence the dismissal was wrong. Prefer it over reject when a fact might be real but the evidence is thin: reject is terminal, snooze records no verdict. Expiry alone brings nothing back, so a snooze on a fact the user never repeats stays hidden, which is the intended behavior rather than a gap.