Route feedback memories to their proper home

[williamthorsen]

Problem

Feedback memories accumulate in per-project stores on every machine, but no tool exists to route them to their proper home. #721 made capture-feedback the default intake for generalizable feedback; #859 must now migrate the existing store. Routing 170+ memories by hand across 10+ stores per machine is error-prone and drops provenance. A repeatable skill is needed to enumerate feedback memories and route each one.

Context

• Feedback memories live under ~/.claude/projects/<project>/memory/ (machine-local); this machine holds 174 across 10 stores, other machines their own.
• They are identified by frontmatter, not filename. The effective type is metadata.type ?? type, and the schema varies by store and era: a legacy shape (top-level type:, a human-title name:, no session id) and a current shape (nested metadata: { node_type, type, originSessionId }).
• Three destinations: capture as a propagating capture-feedback-style candidate, retain as a genuinely-local memory, or delete as redundant.
• Codify generalizable feedback in shared guidance, not per-project memories #721 already placed the redirect guidance in shared/AGENTS.md (loaded for every project on every machine), so the lone per-project redirect memory is redundant with source and is deleted like any other — no carve-out.
• The codeassembly KB vault is git-synced, so it is the cross-machine dedup backstop: a memory already captured from another machine is detected there and deleted rather than re-captured.

Proposed solution

Create the migrate-feedback-memories skill, modeled on kb-add: an authored SKILL.md plus a bundled TS helper registered in bundle-skill-helpers.ts. The helper enumerates every feedback memory across the machine's project stores by parsing frontmatter as YAML (matching metadata.type ?? type == feedback, tolerant of both schemas) and emits each with provenance — origin project from the store path, machine hostname, and originSessionId/name when present; it also executes deletions with MEMORY.md reconciliation. The agent classifies each memory into capture, retain, or delete, dedups capture candidates against the synced KB via kb-retrieve-events, and presents a batch routing plan for review. On approval it captures propagating feedback via capture-event (--store codeassembly, --tags feedback[,mistake], --skill when apt, merits-rated --impact, origin provenance in the body) and deletes redundant memories, leaving only genuinely-local memories. Confirm-by-default, with an --auto escape hatch.

Propagating feedback routes through the capture-feedback mechanism — a deferred candidate a later distillation pass codifies — not a direct edit of the agents source at migration time, so the migration never requires the agents repo on the machine it runs on.

Acceptance criteria

Must have

• The skill enumerates every feedback memory across all project stores on the machine by parsing frontmatter (metadata.type ?? type), tolerant of the legacy top-level and current nested schemas, and proposes one of three destinations (capture, retain, delete) for each.
• Approved routing executes each destination and reconciles the affected MEMORY.md.
• Propagating feedback is captured via capture-event to the codeassembly KB with feedback tags and origin provenance (project, machine, session when available) in the body.
• A memory whose equivalent already exists in the synced KB (captured from another machine) routes to deletion, not re-capture.
• Re-running after a completed migration is a no-op.
• The helper's enumeration and MEMORY.md reconciliation are covered by tests.

Should have

• Captures are impact-rated on the merits of the memory's content, falling back to unrated only on a genuine toss-up.
• A confirm-by-default flow with an --auto escape hatch.