/sync-memory

name: sync-memory
description: "Batch sync session learnings to memory. Use when: persisting campaign insights and performance history across sessions."

/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. 7. **Execute batch storage**: Store each prepared item via the connected vector-DB MCP (e.g. Pinecone) if one is connected; otherwise persist to the local index. Process items sequentially to handle failures gracefully — if one item fails, log the failure with error details and continue with the remaining items. For each successful storage, update the local content hash registry immediately so progress is not lost if the sync is interrupted. 8. **Update sync state**: After all items are processed, update `_last_sync.json` with the new checkpoint timestamp, cumulative items synced, items skipped, items failed (with content hashes for retry), and per-layer storage status. If any items failed, their hashes are queued for automatic retry on the next sync run. 9. **Report sync summary**: Present the complete sync report with actionable details — what was synced, what was skipped and why, what failed and how to fix it, storage uti