| name | my-curator |
| description | Use when interacting with the user's My Curator second brain via the my-curator MCP. Activates for READ ("what does my wiki say about X", "deep research my second brain", "find every source that mentions Y", "what does our cohort wiki say"), WRITE ("save to my wiki", "compile our findings", "put this in my projects domain"), Shared Brain contribution ("save to our shared brain", "contribute to the cohort wiki"), and maintenance ("check my wiki", "find broken links", "scan for duplicate pages"). Enforces atomic decomposition (entities, concepts, summaries), grounds every wikilink in an existing slug before writing, refuses speculative links on fresh domains, respects per-domain siloing, and handles Shared Brain mirrors correctly (read-only locally; contributions go through the user's personal opted-in domain + Sync-tab Push). Always calls list_domains and get_index before composing any write. |
| allowed-tools | mcp__my-curator__list_domains mcp__my-curator__get_index mcp__my-curator__get_graph_overview mcp__my-curator__get_tags mcp__my-curator__search_wiki mcp__my-curator__search_cross_domain mcp__my-curator__get_node mcp__my-curator__get_connected_nodes mcp__my-curator__get_backlinks mcp__my-curator__get_summary mcp__my-curator__compile_to_wiki mcp__my-curator__scan_wiki_health mcp__my-curator__fix_wiki_issue mcp__my-curator__scan_semantic_duplicates mcp__my-curator__get_health_dismissed mcp__my-curator__dismiss_wiki_issue mcp__my-curator__undismiss_wiki_issue |
My Curator — second brain playbook
This skill is the canonical playbook for working with the user's My Curator second brain through the my-curator MCP. The MCP exposes 17 tools — 10 for reading the wiki and 7 for writing to it. This playbook tells you how to use them well, in the order that produces the best results.
§1 — What the second brain is
The user's "second brain" is a Curator-managed wiki: plain markdown files organised into a knowledge graph the user has built up over time. It lives on disk under domains/<name>/wiki/ and is browsed visually in Obsidian, queried in the Curator app, and accessed by you via the my-curator MCP.
A wiki is divided into independent domains (e.g. articles, business, projects). Each domain is its own knowledge graph with its own pages, schema, and conversations. Domains are siloed — there are no automatic links between them and there is no shared inventory. A [[wikilink]] in articles resolves only against pages in articles. Cross-domain reasoning is possible (via search_cross_domain); cross-domain linking is not.
Within a domain, every wiki has three folders:
domains/<name>/wiki/
├── entities/ — the nouns
├── concepts/ — the verbs / ideas
└── summaries/ — the glue
§2 — The atomic decomposition rule
This is the most important rule. When the user asks you to save something to the wiki, you must atomise it into the three folder types correctly.
| Folder | Contains | Examples |
|---|
| entities/ | The nouns. Specific named things — people, companies, tools, datasets, products, organisations, places. Each has a proper name. | entities/openai.md, entities/anthropic.md, entities/gpt-4.md, entities/andrej-karpathy.md, entities/lumina-pro.md |
| concepts/ | The verbs / ideas. Theories, techniques, frameworks, principles, methodologies. Ideas without a single owner. | concepts/rag.md, concepts/agentic-workflows.md, concepts/context-engineering.md, concepts/llm-deployment-strategies.md |
| summaries/ | The glue. One summary page per ingested source or compiled conversation. The narrative that connects entities to concepts for that source. | summaries/lumina-pro-research-notes-2026-04-27-...md |
Slug rules. Filenames are lowercase, hyphenated, and become the slug used in [[wikilinks]]:
entities/openai.md → [[openai]]
concepts/agentic-workflows.md → [[agentic-workflows]]
summaries/<title>-<hash>.md → [[summaries/<title>-<hash>]]
[[wikilinks]] use bare slugs (no folder prefix) for entities and concepts. Summaries are the one exception — they keep their summaries/ prefix because they live in a sibling folder Obsidian needs for routing. So: [[openai]] not [[entities/openai]]. But: [[summaries/foo]] not [[foo]] for summaries.
§3 — Domain awareness
Before you do anything, know which domain you're working in.
- If the user named a domain (
"add to my projects domain") → use it.
- If they said "my wiki" without naming one → call
list_domains. If exactly one domain exists, use it. If multiple exist, ask the user which one. Never guess.
- The user may have set a default domain in the Curator app's Settings. If they did, MCP tools fall back to that automatically when you omit
domain. But still confirm with the user when ambiguous.
- Domains are siloed. Don't try to write a link from one domain to a page in another. If the user wants cross-domain synthesis, that's a
search_cross_domain reading task — not a writing task.
§3.1 — Shared Brain mirror domains (the read/write contract)
Some domains in list_domains may be Shared Brain mirrors — named like shared-<slug> (e.g. shared-cohort, shared-team). These are local read-only copies of a collective wiki the user contributes to as part of a cohort, team, or research group (see docs/shared-brain-user-guide.md for the user-facing model).
Reading a mirror is unrestricted. All ten read tools work normally on shared-* domains — get_node, get_index, search_wiki, search_cross_domain, get_graph_overview, get_connected_nodes, get_backlinks, get_tags, get_summary, list_domains. This is where the cohort use cases get powerful: you can be asked "across our shared brain, which papers contradict each other on X?" and you answer by traversing the collective wiki.
Writing to a mirror is refused. All seven write tools (compile_to_wiki, fix_wiki_issue, scan_semantic_duplicates merge path, dismiss_wiki_issue, undismiss_wiki_issue) check the target domain's CLAUDE.md frontmatter for readonly: true. If true, they refuse with this exact error:
"Domain 'shared-cohort' is a read-only Shared Brain mirror. Direct writes here would not propagate to other contributors and would be overwritten on the next pull. To contribute, call this tool on your personal opted-in domain (e.g. 'work-ai'), then run 'Push contributions' from the Sync tab."
§3.2 — How to actually contribute to a Shared Brain via MCP
The user CAN add to a shared brain through this skill — just indirectly. Here's the full flow and where MCP fits in:
What you (Claude via MCP) do Where it happens What it does
───────────────────────────── ────────────── ────────────────────
1. compile_to_wiki MCP Saves pages to the
target = PERSONAL user's PERSONAL
opted-in domain opted-in domain (e.g.
(NEVER shared-*) 'work-ai/'), not the
mirror.
2. Tell the user clearly: Conversation User now needs to
"Pages are in <domain>. complete the loop in
To push them to the the Curator app.
cohort wiki, click
'Push contributions' in
your Sync tab."
──────────────────────── steps below are NOT MCP-driven ────────────────────────
3. (User) opens Curator Curator app The local LLM
Sync tab → clicks pre-processes the
"Push contributions" changed pages into
DeltaSummaries and
uploads them to
shared storage.
4. (Admin) periodically runs Curator app Merge rules 1-5,
"Run synthesis" contradiction
resolution, Provenance
section, etc.
Rewrites the
collective wiki.
5. (Everyone) clicks Curator app The shared-<slug>/
"Pull updates" mirror domain on each
machine refreshes with
the new synthesised
pages.
The MCP tools push/pull/synthesize are not exposed in v3.0.0-beta.1. Steps 3-5 only happen via the Curator app's Sync tab. This is intentional: those operations consume LLM tokens (paid) and credentials (PAT); they should fire on explicit user action, not as a side-effect of "save this".
§3.3 — Dialogue scripts for common user requests
When the user says one of these phrases, follow the matching script.
"Save this to our shared brain" / "Add to the cohort wiki"
- Identify the personal opted-in domain. Call
list_domains if you don't already know. Look for personal domains (NOT starting with shared-) — the user opted ONE of them into the shared brain. Typical names: work-ai, work, cohort-contributions, research. If multiple personal domains exist and it's unclear which feeds the shared brain, ask the user: "You have personal domains work-ai and research. Which one feeds the shared brain you want me to contribute to?"
- Compile to that personal domain using the full §5 writing playbook (get_index → ground links → compile_to_wiki).
- Tell the user how the contribution reaches the cohort: "I've saved this to your
work-ai domain. To make it appear in the shared brain for your cohort, open the Curator Sync tab and click Push contributions. The admin will then run synthesis (usually weekly) and everyone will see it on their next Pull."
"What does our cohort wiki / shared brain say about X?"
This is a read on the mirror. Treat it like any other deep-research query on shared-<slug>:
get_graph_overview(domain="shared-cohort") for orientationsearch_wiki(domain="shared-cohort", query="X") for retrievalget_node(domain="shared-cohort", slug="...") for full content- All work normally. Cite specific slugs in your synthesis.
If the user wants to compare what the SHARED brain says vs what their PERSONAL brain says, use search_cross_domain — it'll query both at once.
"Check our shared brain for problems" / "Find broken links in the cohort wiki"
This is a Health scan on the mirror. Scanning is allowed:
scan_wiki_health(domain="shared-cohort") works fine — returns the report.
But fixing is refused (Health fix tools would write to the mirror). Tell the user:
"Here's the scan: 12 broken links, 3 orphans. Fixing these directly would not propagate — the shared brain is rebuilt by synthesis from contributors' personal domains. To fix a broken link in the shared brain: ask the contributor whose personal page references that broken slug to update it, then push + synthesise. Or, if it's your own contribution that introduced the broken link, I can fix it in your work-ai domain right now — want me to?"
"Push my contributions" / "Run synthesis" / "Pull updates"
These are NOT MCP operations in v3.0.0-beta.1. Tell the user:
"Push, Pull, and Run synthesis live in the Curator app's Sync tab — they're not exposed via MCP yet (planned for v3.x). Open the app → Sync tab → click the appropriate button. I can prepare the contribution by compiling to your personal domain first — want me to do that?"
§4 — Reading workflow (deep research)
When the user asks a question of their wiki, your job is to traverse the graph efficiently and synthesise — not just keyword-search.
The five reading patterns
| Pattern | Tools | When |
|---|
| Topology orientation | get_graph_overview | "Show me the shape of my knowledge". Returns hubs, orphan sample, top tags. Always cheap; safe first move on a new domain. |
| Targeted retrieval | search_wiki → get_node | "What does my wiki know about X?". Search ranks results; fetch the top 1–3 with get_node for full content. |
| Bidirectional tracing | get_node + get_backlinks | "Every source that mentions Y". Pull the entity page; then list every page that links to it. |
| Multi-hop traversal | get_connected_nodes | "How is X connected to the rest?". Returns the neighborhood up to 2 hops, ranked by hop+degree. |
| Tag-driven clusters | get_tags (with filter) → get_node | "Pages tagged ai-safety, then synthesise". Tag inventory then per-page fetch. |
Cross-domain reasoning
search_cross_domain queries every domain at once. Use this when the user asks something like "What patterns appear across both my articles and my projects domains?". The tool returns matches scoped per-domain — synthesise them in the conversation. You cannot create persistent cross-domain links — that's a fundamental property of the wiki architecture (see §3).
The opening move that usually works
For a deep-research request, this two-step is almost always the right start:
get_graph_overview(domain) — orient yourself on hubs, clusters, orphan sample.- Based on what you see, decide which entities/concepts are worth
get_node calls, then synthesise.
You don't need to enumerate everything. The wiki is large; reasoning over hubs and surfacing connections is the value.
§5 — Writing workflow (adding knowledge)
This is the rule that produces ZERO broken links and ZERO duplicate pages. Follow it every single time the user asks you to save, add, compile, or update.
The five-step playbook
Step 0 — Check the target isn't a Shared Brain mirror. If the domain starts with shared-, STOP. Apply the §3.3 "Save this to our shared brain" script instead — redirect the write to the user's personal opted-in domain. Trying to write directly to a shared-* mirror will be refused with a clear error, but earlier rejection saves a round trip.
Step 1 — Confirm the domain. Per §3.
Step 2 — Inventory the existing wiki. Mandatory before composing.
get_index(domain)
This returns the master catalog. Read it. Note which entities and concepts already exist. For specific topics that might already have pages, also call search_wiki to find variant slugs you might miss in the index.
Step 3 — Decide: what's new vs what already exists. For every concept or entity you're about to mention:
- Already in the index? → use that EXACT slug in your
[[wikilinks]]. Do not invent a variant. ([[openai]] matches entities/openai.md; [[OpenAI]] or [[open-ai]] would NOT.)
- Not in the index, but you want to introduce it? → add it to
additional_pages so it gets created in this same call.
- Not in the index, and you don't want to create a page for it? → write the term as plain prose without
[[brackets]].
Step 4 — Compose with grounded links. Every [[wikilink]] you write must reference one of:
- A slug already in the index (from step 2)
- A slug you're creating in this same
additional_pages array
Anything else is a broken link the user will have to fix later. Do not invent slugs.
Step 5 — Choose the right broken_link_policy when calling compile_to_wiki:
- Fresh / mostly-empty domains (< ~20 pages) → use
broken_link_policy: 'refuse'. The call will abort if any link is broken, returning the broken list + a sample of valid slugs. Retry with corrections — typically converges in 1–2 iterations.
- Established / populated domains →
broken_link_policy: 'keep' (default) is fine. The response's links field still tells you what's broken.
- When unsure, prefer 'refuse'. It's strict but produces clean wikis.
After the call, inspect the links field in the response:
"links": {
"total": 12,
"resolved": 10,
"normalized": 1,
"broken": [...],
"broken_count": 1
}
If broken_count > 0 and you used 'keep', decide: retry with corrections, or accept the broken link as a known TODO?
Idempotency
compile_to_wiki refuses re-compiles when the title + content + date hash to the same slug. If the user asks to compile the same thing twice, the second call is refused with a clear message. To extend a previous compile, the user should add new content to their conversation first.
Don'ts
- Don't write to
summaries/ paths via additional_pages. Summary slugs are deterministically generated by the system. You only provide summary_content; the tool produces the path.
- Don't compile twice with identical content. The idempotency guard will refuse — that's correct behaviour, not a bug.
- Don't try to link across domains.
[[business:openai]] is not supported syntax.
§6 — Maintenance workflow (Wiki Health)
When the user asks to "check my wiki" or "clean up", use the Health tools. There's a three-tier mental model:
| Tier | Issue types | Action |
|---|
| Auto-fix without asking | folderPrefixLinks, crossFolderDupes, hyphenVariants, missingBacklinks, brokenLinks with suggestedTarget | These have one clear right answer. Call fix_wiki_issue for each, no confirmation needed. |
| Confirm with user first | orphans, brokenLinks without a target | Show the user, accept "fix" / "dismiss" / "leave for later", then act. |
| ALWAYS preview, then confirm | semanticDupe (destructive — deletes a file, rewrites links) | Call fix_wiki_issue with preview: true to get the diff plan; show the user; only on explicit confirmation call again with preview: false. |
The standard "clean up" dialogue
1. scan_wiki_health(domain)
2. Loop the auto-fixable ones via fix_wiki_issue (count successes)
3. List the review-only ones; ask the user one by one (or in batch)
4. For each user-approved fix → fix_wiki_issue
5. For each user dismissal → dismiss_wiki_issue (persists across scans + machines)
Persistent dismissals: dismiss_wiki_issue writes to a file synced across the user's machines. Items dismissed in a Claude Desktop conversation also disappear from the in-app Health tab; same store. Use get_health_dismissed to list previously skipped issues if the user asks.
Semantic-duplicate scanning is paid
scan_semantic_duplicates calls the LLM with a small per-scan cost (~$0.005–$0.03). Only run it when the user explicitly asks — and use estimate_only: true first to show the cost before committing.
Health on Shared Brain mirror domains
scan_wiki_health works fine on shared-* mirrors — you can show the user the report. But fix_wiki_issue is refused on mirrors: fixes wouldn't propagate to other contributors and would be overwritten on the next Pull. To resolve a Health issue in the shared brain, the contributor who introduced it must fix it in their personal opted-in domain, then Push + run synthesis. Tell the user this explicitly when their scan request targets a shared-* domain.
§7 — Tool reference
| Tool | Purpose | When | Works on shared-* mirror? |
|---|
list_domains | List domains | Always when domain is unclear | Yes (lists mirrors too) |
get_index | Master page catalog | Always before any write | Yes |
get_graph_overview | Topology snapshot | First move on a research task | Yes |
get_tags | Tag inventory | Tag-driven cluster work | Yes |
search_wiki | Ranked search in one domain | Specific topic lookup | Yes |
search_cross_domain | Search across all domains | Cross-domain synthesis only (read) | Yes (treats mirrors as just another domain) |
get_node | Full page with frontmatter | Detail pull on a known slug | Yes |
get_connected_nodes | Neighborhood traversal | "How is X connected" | Yes |
get_backlinks | Incoming-link list | "Every source that mentions X" | Yes |
get_summary | Pull a summary page | When user references a specific source | Yes |
compile_to_wiki | Save findings as wiki pages | THE write tool — follow §5 | No — refused. Redirect to personal opted-in domain per §3.3 |
scan_wiki_health | Find structural issues | "Check my wiki" | Yes (read-only scan) |
fix_wiki_issue | Apply ONE Health fix | After scan, per issue | No — refused. Fixes don't propagate from mirrors |
scan_semantic_duplicates | AI duplicate detection | Opt-in, paid, user-initiated only | Yes (scan) but the merge path that would delete files is refused on mirrors |
get_health_dismissed | List previously dismissed | "What have I skipped?" | Yes (read-only) |
dismiss_wiki_issue | Permanently skip an issue | When user says "leave alone" | No — refused on mirrors |
undismiss_wiki_issue | Restore a dismissal | When user changes their mind | No — refused on mirrors |
§8 — Quality rules (the don'ts)
A compact reminder of what NOT to do:
- Don't invent wikilinks. Every
[[X]] must resolve. If you didn't verify it's in the index or in additional_pages, write the text without brackets.
- Don't create duplicate pages. If
entities/openai.md exists, your update goes to [[openai]] — never [[OpenAI]] or [[open-ai]].
- Don't write summaries via
additional_pages. Only entities/ and concepts/.
- Don't compile identical content twice in a day. Idempotency refusal is correct.
- Don't try to link across domains. Domains are siloed.
- Don't use folder prefixes in wikilinks for entities or concepts.
[[openai]] not [[entities/openai]]. Summaries keep their prefix: [[summaries/foo]].
- Don't run
scan_semantic_duplicates without the user asking. It costs money.
- Don't fix
semanticDupe issues without preview: true first. Destructive — deletes files.
- Don't skip
get_index on writes. That's the #1 cause of broken links.
- Don't compose first and check links after. Ground links during composition by referring to the index.
- Don't compile to a
shared-* mirror. Always redirect to the user's personal opted-in domain (§3.3). The mirror's writes don't propagate and would be overwritten on the next Pull.
- Don't promise the user "I've added this to the shared brain" when you've actually compiled to their personal domain. Be precise: "Saved to your
work-ai domain — it'll appear in the shared brain after you click Push contributions in the Sync tab and the admin runs synthesis." The Push and synthesise steps aren't yours to do.
- Don't try to call a "push" or "synthesize" MCP tool. They don't exist in v3.0.0-beta.1. Those operations live in the Curator app's Sync tab. If the user asks you to push, tell them how to do it themselves.
- Don't suggest fixing Health issues on a
shared-* mirror. Suggest the upstream fix (in the contributor's personal domain) and a Push + synthesise cycle.
§9 — Quick reference
For any user request, ask yourself:
Is the user READING the wiki?
→ §4 reading workflow
→ Start with get_graph_overview or search_wiki
Is the user WRITING to the wiki?
→ §5 writing workflow
→ Steps: domain check → get_index → ground links → compile_to_wiki (refuse mode on fresh domains)
Is the user MAINTAINING the wiki?
→ §6 maintenance workflow
→ scan_wiki_health → loop fix_wiki_issue (auto-fix simple, confirm risky, preview destructive)
For sample dialogues that show end-to-end flows for each scenario, see examples.md.
§10 — Version compatibility
This skill targets Curator v3.0.0-beta.1 and later. If you're working with The Curator, the following features are covered by this version of the skill:
- The 17 MCP tools (10 read + 7 write, list in §7)
- Shared Brain mirror domains (
shared-*) — §3.1 read/write contract, §3.2 indirect-write model, §3.3 dialogue scripts
- Health on mirrors — scan allowed, fix refused (§6)
- Two-primitives model — invite token (metadata) vs PAT (per-contributor identity)
Earlier Curator versions (pre-v3.0.0-beta.1) didn't have Shared Brain at all. The mirror-domain logic still works — there simply won't be any shared-* domains to dispatch on. The skill is backward-compatible.
Updating to a newer skill version: just re-run the install commands in docs/mcp-user-guide.md — they overwrite the existing files in ~/.claude/skills/my-curator/ (Claude Code) or replace the project knowledge upload (Claude Desktop). Re-installation doesn't restart any conversation — edits take effect mid-session.
