sync

name	sync
description	Use when I say "sync" or "sync my notes" — pull meeting / 1:1 notes from my external notes provider into the local vault.

Sync

Some of my notes live in a shared third-party tool (so I can share them with others), but my vault is my agent's long-term memory. This skill pulls those notes into the vault as local markdown so everything is searchable here and nothing gets lost. It must be safe: it creates or appends, it never blindly overwrites my local edits.

Connect your source (do this first)

This skill needs a way to read pages from your notes/docs provider. Wire in whatever YOU already use — there is no single required vendor. Pick one:

• An MCP server / connector for your provider, if your agent supports it.
• The provider's API with a token you supply (keep it in a secrets manager / vault, or a git-ignored .env as a fallback — never in the repo).
• A manual export — you export the pages/folder to markdown and drop them in a known location, then point me at it.

Replace the bracketed placeholder below with the concrete instruction for your setup. A couple of vendor-neutral examples of how that line might read:

Example A: "My meeting notes live in a workspace-style docs tool. Use the connected <your-docs> MCP to list pages under the database/folder called Meeting Notes, then read each page as markdown."

Example B (manual): "I've exported my notes to working/sync-inbox/. Read the markdown files there."

[CONNECT YOUR SOURCE HERE — replace this line with the instruction above that matches your setup.]

Steps

1. List the relevant pages from the connected source (e.g. 1:1 notes, meeting notes). If you're unsure which set, ask me which folder/database to sync.
2. For each page, map it to a stable local file in meetings/ — a predictable name so the same source page always lands in the same file, e.g. meetings/<person>.md for an ongoing 1:1, or meetings/<yyyy-mm-dd>-<short-title>.md for a one-off.
3. Write it in safely:
   • If the local file doesn't exist → create it with the page content.
   • If it already exists → append any new content under a dated heading (e.g. ## Synced <yyyy-mm-dd>). Never rewrite or delete what's already there.
4. Report what you did: files created, files updated, anything skipped. If you couldn't actually read a page, say so — don't make notes up.

Safety rules

• Create or append; never overwrite a whole local file.
• My local edits always survive a sync.
• If the source isn't connected, stop and tell me how to connect it — don't fabricate notes.
• Keep credentials in a secrets manager / vault (a git-ignored .env only as a fallback), never committed.

Make it yours

This is a deliberately simple v1 — it appends everything new under a dated heading. Once it earns its keep, consider:

• Track sync state — add a small header to each file recording the source id/URL and a last_synced timestamp, and use it to bring in only what changed since last time (a true delta) rather than re-appending.
• Handle conflicts explicitly — if the source and your local edits disagree on the same content, don't pick a winner: keep your version and add the source version below under a > ⚠️ Conflict from source <date>: block to resolve yourself.
• Two-way awareness — flag local notes that should be pushed back to the shared tool (but keep human-facing edits in your own voice).
• Sync other sources too (e.g. project docs into concepts/).
• Keep a meta/sync-log.md of when you last synced each source.