tpierrain/kenjaku/local-mirror

/local-mirror — Mirror a live internal source into your vault (opt-in, safe)

Brain-side skill. A local mirror (a copie miroir / réplica locale) is a zone of an

internal tool (Notion for the MVP) that you declare once; the brain then **mirrors its pages

into vault/mirrors/<name>/ as plain Markdown** (or vault/<universe>/mirrors/<name>/ when the

mirror belongs to a universe, see below). From there the existing RAG indexes and cites

them like any other note — *the central RAG you don't have yet, but local and right now, plugged

onto your live sources.*

⚠️ This skill holds no logic. All the real, testable work lives in the **local-mirror

MCP server (its own package, Outside-in TDD). This skill only recognizes intent, gathers the

declaration, guides the token into .env, calls the right MCP tool, and reports.**

First — a local mirror, or the native Notion connector? (don't mix them up)

A brain can touch Notion two completely different ways. Put yourself in the user's shoes and route to the right one before doing anything:

• They just want to read, write, create, edit, fetch or search something in Notion — live, ad hoc?

→ that's the native Notion connector (the brain's general, real-time Notion access: notion-fetch, notion-search, notion-create-pages, …). NOT this skill. Let that connector handle it; do not onboard a local mirror for it.

• They want a sub-zone of Notion replicated locally so the local RAG can search & cite it —

offline, framed, refreshed on demand, without re-querying Notion every time? → that's a local mirror. This skill. (Mirror = one-way read-only copy into the vault; this skill never writes back to Notion.)

🧭 One-line litmus: *live read/write in the ocean → native Notion connector; a local mirror of

a slice of the ocean for the RAG → local mirror (this skill).*

Disambiguate first — the balanced 2-option question (don't guess)

The exact fault line is a phrasing like "je veux que mon cerveau puisse chercher dans ce Notion". It can mean either tool. When the intent is genuinely ambiguous, don't assume — ask one honest, balanced question (not a sales funnel that pushes the mirror):

Two ways, depending on your need:

*— one-off, live (native connector): I read Notion directly, right now. Always up to date, but

online, basic search, and it doesn't stay in your brain's memory;*

*— durable (local mirror): I copy this zone once, then your brain searches it **semantically

(RAG), offline, cites** it, and crosses it with the rest of your notes — in exchange you

ask me to refresh it when the source changes.*

*Given your phrasing I'd lean toward the local mirror — shall I set it up?*

Discriminators — only ask when it's actually unclear:

• durable / recurring ("puisse", "à chaque fois", "qu'il garde", "hors-ligne") + citable →

local mirror (this skill).

• one-off / live / now ("lis", "va voir", "cherche maintenant") → native connector, not this skill.

If the discriminators clearly point one way (e.g. "mets en place un miroir local pour ce Notion" → obviously a mirror; "va me lire cette page Notion" → obviously the connector), don't ask — just route. The question is for the genuine grey zone, not a reflex.

When to use it

Load this whenever the user wants to work with a local mirror, in any language:

• "mirror / replicate / set up a local mirror of a Notion zone" — onboarding → setup_source
• "refresh / sync / update the `<name>` mirror" — delta + deletions → sync
• "is `<name>` up to date? / what's its status?" — → check_freshness / status
• "list my local mirrors" — → list_sources
• "remove / disconnect the `<name>` mirror" — → remove_source
• "file / move the `<name>` mirror into my `<universe>` universe" — → move_source (only ever

once a second universe exists; below that gate the notion does not exist for this user)

Scope — local mirrors only; do NOT invent other "source types". This skill mirrors a Notion

zone into the vault, full stop. When the user asks the generic "I'd like to connect a source",

do not improvise a multiple-choice "what type of source?" menu — and never offer a "live

connector / sync delta" option (background Slack/Drive/Calendar live querying is the separate

sync-sources mechanism, not this skill; "sync delta" already means a mirror's incremental delta —

keep the term unambiguous). If you must disambiguate, ask one neutral line: *"Do you want to

mirror a Notion zone into your vault as a locally-searchable copy? (That's what I set up here.)"*

— then proceed with the onboarding flow below. No invented option list.

Routing (the harness's job, not the MCP's — PRD §8): when a question is clearly **about a declared

mirror's topic (the `description` you captured at setup), stay local-first** — exactly like the

rest of the brain (Slack/Drive/Calendar): answer NOW from the local RAG, and verify freshness

in the background, never block the answer on a network sync. See "Local-first routing" below for

the exact pattern and wording. Sync only the relevant mirror, never all of them — and only when a

background freshness check actually reports behind.

Terminology — what to call it when speaking to the user

In English, say "local mirror" (or just "mirror"). In French, lead with « copie miroir » or « réplica locale »; « source synchronisée » is fine as a property, but always framed local / chez toi / hors-ligne so it never drifts back into the ambiguous native-connector "sync". Never use "golden source" / "source de vérité" anymore — they over-claim and confuse. Mirror the user's own wording when they have one. The identifiers stay English everywhere regardless of the spoken language: the skill name local-mirror, the frontmatter key mirror, the folder vault/mirrors/<name>/ (vault/<universe>/mirrors/<name>/ when scoped), the MCP tools — never translate those.

Golden rule — the token NEVER travels through the chat

The Notion integration token is a secret. It goes only into `.env`, referenced by name (token_env) — never pasted into the conversation, never passed as a tool argument, never committed. The setup_source tool takes the name of the env var, not the token.

Onboarding flow (setup_source)

1. Gather the declaration (ask in chat, conversationally):

• name — short technical id = the vault subfolder (e.g. team-a). Lowercase, no spaces.
• title — human label (e.g. "PA / SC zone").
• description — the topics this mirror covers, in natural language. This is the **routing

key**: it's how you'll later know which question should refresh which mirror.

• root_page_url — the URL of the root Notion page of the zone to mirror (its whole sub-tree

is in scope; pages outside it are not — see the perimeter disclaimer below).

• token_env — the name of the env var that will hold the integration token (e.g.

NOTION_TOKEN_PASC). One token/scope per mirror.

1. Guide the token into `.env` — ONE path, no chat paste-block (only if it isn't set yet).

⚠️ Settle `token_env` FIRST. Gather and confirm the exact var name with the user (step 1) before writing anything — open-env.mjs writes that name as a placeholder line, so a name you later change leaves a stale NOTION_TOKEN_<wrong>= line behind (the PERSO→FACTURE placeholder dance). Only once the name is agreed, proceed. .env is a hidden file a non-dev can't locate, so don't ask them to find it, and don't print a <token_env>=… block to copy into the chat (that duplicates what then has to be cleaned up, R2-3). Instead run the deterministic helper, from the brain folder, which writes a single <token_env>= placeholder line into .env (idempotent — never a second line) and pops their editor right on it: ``bash node scripts/open-env.mjs <token_env> # e.g. node scripts/open-env.mjs NOTION_TOKEN_PASC ` Then tell them: *"Your .env just opened — paste your Notion token right after <token_env>=, save (⌘S), and tell me when it's done."* The token stays **in .env**, never in the chat (golden rule). *(If no editor pops — headless / SBG_NO_OPEN_ENV — the command still prints the .env` path; relay it so they can open it themselves.)*