sync-memory

name

sync-memory

description

Batch-sync this session's learnings, insights.json entries, and campaign history into the persistent memory layer — incremental from the last checkpoint so repeat runs are fast and idempotent — and report exactly what was synced, skipped, or failed. Triggers on "/digital-marketing-pro:sync-memory", "save what we learned this session", "sync insights to memory", "persist campaign learnings before I close", "did my session learnings get saved". Stores via a connected vector-DB MCP when one exists, otherwise the local index; reads the active brand profile and complements /digital-marketing-pro:save-knowledge, which saves single items.

/digital-marketing-pro:sync-memory

Purpose

Batch sync current session learnings, insights.json entries, and campaign history to the persistent memory layer. Ensures valuable knowledge from this session is preserved for future sessions without requiring the user to manually save each item via /digital-marketing-pro:save-knowledge. Syncs incrementally — only new items since the last sync checkpoint — so repeated syncs are fast, idempotent, and safe. Handles the full pipeline from diff detection through storage to checkpoint update, with detailed reporting on what was synced, skipped, or failed. Run this before ending a productive session to capture everything worth remembering.

Input Required

The user must provide (or will be prompted for):

• Sync scope: What to sync — all (insights + campaigns + session learnings), insights-only (only insights.json entries — performance data, metric snapshots, and automated learnings), or campaigns-only (only campaign data, retrospective learnings, and strategy decisions). Default is all
• Force full sync (optional): Set to true to ignore the last sync checkpoint and re-sync everything regardless of previous sync state. Useful after data corruption, vector DB migration, index rebuild, or when the local index and persistent storage may be out of alignment. Default is false (incremental sync from last checkpoint)
• Content type override (optional): Force a specific content_type classification for all synced items — overrides auto-detection. Rarely needed but useful for bulk re-classification when migrating knowledge taxonomy
• Dry run (optional): Set to true to preview what would be synced without actually storing anything. Shows the full diff, payload previews, and estimated storage impact for review before committing. Useful for auditing what has accumulated since the last sync
• Tags to apply (optional): Additional tags to apply to all items in this sync batch — e.g., "q1-2026-review", "pre-rebrand", "campaign-retrospective". These are added alongside auto-detected tags, not replacing them
• Exclude patterns (optional): Content patterns or types to skip during this sync — e.g., exclude draft insights, partial campaign data, or specific content types. Prevents syncing incomplete or work-in-progress knowledge

Process

1. Load brand context: Read ~/.claude-marketing/brands/_active-brand.json for the active slug, then load ~/.claude-marketing/brands/{slug}/profile.json. Apply brand voice, compliance rules for target markets (skills/context-engine/compliance-rules.md), and industry context. Also check for guidelines at ~/.claude-marketing/brands/{slug}/guidelines/_manifest.json — if present, load restrictions. Check for agency SOPs at ~/.claude-marketing/sops/. If no brand exists, ask: "Set up a brand first (/digital-marketing-pro:brand-setup)?" — or proceed with defaults.
2. Load sync state: Run python "${CLAUDE_PLUGIN_ROOT}/scripts/memory-manager.py" --brand {slug} --action sync-insights to load the last sync checkpoint from ~/.claude-marketing/brands/{slug}/memory/_last_sync.json. Identify the last sync timestamp, items previously synced (by content hash), and any partial sync that needs resuming from its failure point. If force sync is requested, reset the checkpoint to epoch zero.
3. Gather syncable items: Load insights.json entries, campaign data from campaigns/, and session learnings accumulated in the current working context. Apply sync scope filter (all, insights-only, campaigns-only) and exclude patterns to build the candidate set.
4. Identify new and modified items: Diff the candidate set against the sync checkpoint. Generate content hashes (SHA-256) for each candidate and compare against the local content hash registry. Separate items into: new (not previously synced), modified (content changed since last sync — hash mismatch), and unchanged (already synced — skip). Report the diff summary before proceeding.
5. Prepare storage payloads: For each new or modified item, run memory-manager.py --action prepare-store to structure the metadata payload — auto-detect content_type based on source (insight entries become performance-insight, campaign retrospectives become campaign-learning, strategy decisions become campaign-learning, guidelines become guideline), apply auto-detected tags plus any user-specified batch tags, and set source to sync.
6. Check configured memory services: Run python "${CLAUDE_PLUGIN_ROOT}/scripts/memory-manager.py" --brand {slug} --action get-memory-status. This checks environment variables only — it reports which backends are configured, not whether they are reachable and not how much remote capacity remains (it cannot measure a remote provider's usage). If no vector-DB env var is set, store locally and recommend connecting a vector DB.

Output

A structured sync report containing:

• Sync summary: Total items processed with breakdown — new items synced, modified items updated, duplicates skipped (with count by reason: hash match, exclude pattern), and items failed with specific error reasons and remediation steps per failure
• Items synced detail: List of each synced item with content summary (first 100 characters), content_type assigned, tags applied (auto-detected + batch tags), and storage ID in the vector database for reference
• Items skipped: Duplicates and excluded items listed with reason — content hash match (already in persistent storage), exclude pattern hit, or unchanged since last sync — so the user can verify nothing important was missed
• Items failed: Any items that could not be stored — with full error message, failure reason (API timeout, validation error, capacity limit, malformed payload), content hash for retry identification, and specific remediation steps
• Sync state update: New checkpoint timestamp, cumulative items in persistent memory (total across all syncs), delta since last sync (net new items), and estimated next sync size based on current session activity rate
• Per-layer status: Which memory layers received data — vector DB items stored (with namespace), knowledge-graph entities created (if a graph server is connected), cross-session entries updated (if a cross-session store is connected), and local index entries registered
• Local index size: Total items synced from the local index this run and cumulative local count. (DMP cannot read a remote vector DB's plan usage — check remaining capacity in your provider's own dashboard.)
• Next sync recommendation: Suggested timing for next sync based on session activity volume and storage capacity — with a reminder that running /digital-marketing-pro:sync-memory before ending a session ensures no learnings are lost

Agents Used

• memory-manager — Sync checkpoint loading and incremental diff calculation against content hash registry, SHA-256 hash generation for new and modified item detection, payload preparation with auto-classified content types and source-based tagging, batch storage execution via vector database MCP with per-item error handling and progress persistence, local index and content hash registry updates after each successful store, sync state checkpoint management with partial-progress recovery for interrupted syncs, storage capacity monitoring with utilization alerts, and comprehensive sync report generation with retry queue management