@oomkapwn/enquire-mcp 2.0.0 → 2.5.0

package/dist/index.js

@@ -9,10 +9,10 @@ import { z } from "zod";
 import { EmbedDb } from "./embed-db.js";
 import { DEFAULT_MODEL_ALIAS, EMBEDDING_MODELS, loadEmbedder, resolveModel } from "./embeddings.js";
 import { chunkContent, defaultIndexFile, FtsIndex } from "./fts5.js";
-import { appendToNote, archiveNote, createNote, dataviewQuery, embeddingsSearch, findPath, findSimilar, getBacklinks, getNoteNeighbors, getOpenQuestions, getOutboundLinks, getRecentEdits, getUnresolvedWikilinks, getVaultStats, lintWiki, listCanvases, listNotes, listTags, openInUi, paperAudit, readCanvas, readNote, renameNote, replaceInNotes, resolveWikilink, searchHybrid, searchText, semanticSearch, validateNoteProposal } from "./tools.js";
+import { appendToNote, archiveNote, chatThreadAppend, chatThreadRead, contextPack, createNote, dataviewQuery, embeddingsSearch, findPath, findSimilar, frontmatterGet, frontmatterSearch, frontmatterSet, getBacklinks, getNoteNeighbors, getOpenQuestions, getOutboundLinks, getRecentEdits, getUnresolvedWikilinks, getVaultStats, lintWiki, listCanvases, listNotes, listTags, openInUi, paperAudit, readCanvas, readNote, renameNote, replaceInNotes, resolveWikilink, searchHybrid, searchText, semanticSearch, validateNoteProposal } from "./tools.js";
 import { Vault } from "./vault.js";
 import { VaultWatcher } from "./watcher.js";
-const VERSION = "2.0.0";
+const VERSION = "2.5.0";
 /** Default location for the persistent embedding index, alongside .fts5.db. */
 function embedDbPath(vaultRoot) {
     // Match the FTS5 location convention by stripping the .fts5.db extension
@@ -380,7 +380,11 @@ async function syncEmbedDb(vault, db, embedder) {
             if (chunks.length >= 30) {
                 process.stderr.write(`enquire: ${e.relPath} → ${chunks.length} chunks (this one will be slow; consider splitting the note)\n`);
             }
-            const vectors = await embedder.embed(chunks.map((c) => c.text));
+            // v2.1.0: prepend heading breadcrumb to embedded text so the model sees
+            // structural context. Free win at zero token cost — Chroma 2024 +
+            // NAACL 2025 show +2-5 NDCG@10 from breadcrumb prepending. The text
+            // stored in `text_preview` (for snippets) stays clean.
+            const vectors = await embedder.embed(chunks.map((c) => (c.breadcrumb ? `${c.breadcrumb}\n\n${c.text}` : c.text)));
             const rows = chunks.map((c, i) => {
                 const vector = vectors[i];
                 if (!vector)
@@ -865,12 +869,84 @@ function registerReadTools(server, vault, ftsIndex, diagnosticSearchTools) {
             embedding_model: z
                 .string()
                 .optional()
-                .describe("Override the embedding model alias (default 'multilingual'). Only consulted if a .embed.db exists.")
+                .describe("Override the embedding model alias (default 'multilingual'). Only consulted if a .embed.db exists."),
+            granularity: z
+                .enum(["note", "block"])
+                .optional()
+                .describe("v2.2.0: 'note' (default) returns one hit per note (best chunk wins). 'block' keeps each chunk as a distinct hit — useful when one note covers a topic in multiple paragraphs and you want the LLM to see all of them."),
+            graph_boost: z
+                .boolean()
+                .optional()
+                .describe("v2.3.0: post-RRF wikilink graph-boost — rerank top-K by counting how many OTHER top-K hits link to each one. Default ON. Set false to disable for diagnostic comparison. The 'only enquire-mcp does this' feature: generic vector stores can't do this without an Obsidian-aware layer.")
         }
     }, async (args) => {
         const embedFile = embedDbPath(vault.root);
         return textResult(await searchHybrid(vault, args, { ftsIndex, embedFile }));
     });
+    server.registerTool("obsidian_chat_thread_read", {
+        title: "Read parsed chat thread from a note",
+        description: "Parse a note's `## Chat: <title>` block into structured messages with role/timestamp/content/line-range. Non-chat content in the same note is ignored. Read-only.",
+        annotations: { ...READ_ONLY, title: "Read chat thread" },
+        inputSchema: {
+            note_path: z.string().min(1).describe("Vault-relative path to the note hosting the thread")
+        }
+    }, async (args) => textResult(await chatThreadRead(vault, args)));
+    // v2.2.0: context pack — Smart Connections "Send to Smart Context" pattern,
+    // MCP-native (works with any AI client, not just Obsidian).
+    server.registerTool("obsidian_context_pack", {
+        title: "Pack vault context for an AI question (token-budgeted)",
+        description: "Given a question, retrieve the top relevant notes (via hybrid search), gather backlinks summaries + optionally recent dailies, deduplicate, pack to a token budget, return a single ready-to-paste markdown bundle. Saves the agent ~5 separate tool calls; produces a coherent context blob you can paste into any AI chat.",
+        annotations: { ...READ_ONLY, title: "Context pack" },
+        inputSchema: {
+            query: z.string().min(1).describe("Topic or question to gather context for"),
+            budget_tokens: z
+                .number()
+                .int()
+                .positive()
+                .max(32000)
+                .optional()
+                .describe("Approximate token budget (default 4000, ~4 chars/token)"),
+            folder: z.string().optional().describe("Restrict retrieval to this folder (vault-relative)"),
+            include_backlinks: z
+                .boolean()
+                .optional()
+                .describe("Include 1-line backlink summaries for top-3 notes (default true)"),
+            recent_dailies: z
+                .number()
+                .int()
+                .min(0)
+                .max(30)
+                .optional()
+                .describe("Include the last N daily-format notes (YYYY-MM-DD basenames). Default 0 (off).")
+        }
+    }, async (args) => {
+        const embedFile = embedDbPath(vault.root);
+        return textResult(await contextPack(vault, args, { ftsIndex, embedFile }));
+    });
+    // v2.3.0: frontmatter atomic ops — read.
+    server.registerTool("obsidian_frontmatter_get", {
+        title: "Read note frontmatter (full or single key)",
+        description: "Return parsed YAML frontmatter for a note. With `key`, returns just that field's value. Without `key`, returns the whole frontmatter object. Read-only.",
+        annotations: { ...READ_ONLY, title: "Get frontmatter" },
+        inputSchema: {
+            path: z.string().optional().describe("Vault-relative path"),
+            title: z.string().optional().describe("Note title (filename without .md, accepts periodic aliases)"),
+            key: z.string().optional().describe("Single key to read; omit for full frontmatter")
+        }
+    }, async (args) => textResult(await frontmatterGet(vault, args)));
+    server.registerTool("obsidian_frontmatter_search", {
+        title: "Find notes by frontmatter predicate",
+        description: "Find every note where frontmatter.<key> matches a predicate. Useful as a precursor to bulk frontmatter_set: 'find all notes with status:draft and set their status to published'. Predicates are exclusive: pass exactly one of `equals` (strict equality), `exists` (key must be present), `contains` (for array values, member match).",
+        annotations: { ...READ_ONLY, title: "Search frontmatter" },
+        inputSchema: {
+            key: z.string().min(1).describe("Frontmatter key to test"),
+            equals: z.unknown().optional().describe("Strict equality predicate (JSON.stringify comparison)"),
+            exists: z.boolean().optional().describe("Predicate: key must exist (any value)"),
+            contains: z.unknown().optional().describe("For array values, value must be a member"),
+            folder: z.string().optional().describe("Restrict search to a folder"),
+            limit: z.number().int().positive().max(1000).optional().describe("Max matches (default 100)")
+        }
+    }, async (args) => textResult(await frontmatterSearch(vault, args)));
 }
 function registerWriteTools(server, vault) {
     // destructiveHint=true: `obsidian_create_note` with overwrite=true replaces a
@@ -956,6 +1032,35 @@ function registerWriteTools(server, vault) {
                 .describe("Allow overwriting an existing file at the archive destination (default false)")
         }
     }, async (args) => textResult(await archiveNote(vault, args)));
+    // v2.2.0: append message to a note's chat thread.
+    server.registerTool("obsidian_chat_thread_append", {
+        title: "Append message to note-tethered chat thread",
+        description: "Add a user/assistant/system message to a note's `## Chat: <title>` block. Creates the note + heading if absent. Threads are stored as markdown so they're searchable, version-controllable, and survive across sessions / clients. Pair with `obsidian_chat_thread_read` to load past context. WRITE TOOL — only registered with --enable-write.",
+        annotations: { ...WRITE, title: "Append chat thread" },
+        inputSchema: {
+            note_path: z.string().min(1).describe("Vault-relative path to the note hosting the thread"),
+            role: z.enum(["user", "assistant", "system"]).describe("Role of the message being appended"),
+            content: z.string().min(1).describe("Message body (markdown allowed)"),
+            thread_title: z
+                .string()
+                .optional()
+                .describe("Optional thread title — used when the note is created from scratch")
+        }
+    }, async (args) => textResult(await chatThreadAppend(vault, args)));
+    // v2.3.0: surgical frontmatter writes (set / unset / bulk).
+    server.registerTool("obsidian_frontmatter_set", {
+        title: "Set/unset frontmatter keys atomically",
+        description: "Surgical YAML manipulation: set one or more keys, or remove them by passing `null` as the value. Round-trips through gray-matter (same parser used at write time) so YAML formatting / quoting / type-coercion stays consistent. Returns `before` + `after` + list of changed keys for observability. `dry_run: true` shows the diff without writing.",
+        annotations: { ...WRITE, title: "Set frontmatter" },
+        inputSchema: {
+            path: z.string().optional().describe("Vault-relative path"),
+            title: z.string().optional().describe("Note title (filename without .md)"),
+            set: z
+                .record(z.string(), z.unknown())
+                .describe("Keys to set. Pass `null` as value to delete a key (e.g. {status: 'published', draft: null})"),
+            dry_run: z.boolean().optional().describe("Preview the diff without writing (default false)")
+        }
+    }, async (args) => textResult(await frontmatterSet(vault, args)));
 }
 function registerChunkResource(server, idx, vault) {
     // Chunk-level addressing — closes the v0.10 roadmap item from issue #10
@@ -1311,6 +1416,303 @@ DO NOT actually modify any notes. This is a proposal pass — the user runs the
             }
         ]
     }));
+    // v2.1.0: multi-query expansion as a prompt template (NOT a server-side
+    // LLM call — that would violate the MCP boundary). The agent paraphrases
+    // the user's question N ways, calls obsidian_search per paraphrase, then
+    // RRF-fuses the results client-side. Boosts recall on terse / ambiguous
+    // queries by 5-15 NDCG@10 vs single-pass search. Pure prompt eng.
+    server.registerPrompt("search_with_query_expansion", {
+        title: "Search with multi-query expansion",
+        description: "Higher-recall retrieval: paraphrase the query 3-5 ways, call obsidian_search per paraphrase, fuse results. Boosts recall on terse / ambiguous queries by 5-15 NDCG@10 over a single-pass search. Pure agent-side orchestration — no server-side LLM calls.",
+        argsSchema: {
+            query: z.string().describe("The user's original question / search query"),
+            n_paraphrases: z.string().optional().describe("How many paraphrases to generate (default 4)"),
+            limit: z.string().optional().describe("Top-K hits per paraphrase before fusion (default 10)")
+        }
+    }, ({ query, n_paraphrases, limit }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `High-recall retrieval over my Obsidian vault. The user asked: "${query}"
+
+1. Generate ${n_paraphrases ?? 4} short paraphrases of the question. Mix:
+   - 1 keyword-focused (good for BM25): noun phrases, technical terms
+   - 1 semantic-focused (good for embeddings): natural-language restating
+   - 1-2 step-back: a more general question whose answer would contain this one
+   - Optionally 1 in another language if my vault is bilingual
+
+2. For each paraphrase, call \`obsidian_search\` with \`query=<paraphrase>\` and \`limit=${limit ?? 10}\`.
+
+3. Reciprocal Rank Fusion: assign each hit a score of 1/(60+rank), sum across paraphrases per note path, sort descending.
+
+4. Return the top 10 fused results. For each: path, fused_score, which paraphrases hit it (and at what rank), and a 1-sentence "why this answers the original question."
+
+5. If a hit appears in only ONE paraphrase, mark it as "low-confidence — only retrieved by paraphrase #N" — these are speculative.
+
+The goal is recall + observability: the user sees not just the answer but WHY each note ranked.`
+                }
+            }
+        ]
+    }));
+    // v2.4.0 — Karpathy LLM-Wiki workflow prompts.
+    // Reference: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
+    // Karpathy named three workflows: ingest, query, lint. We had `query` and
+    // `lint` since v1.5. v2.4.0 adds `ingest`-style workflows + `compile`/
+    // `synth` patterns that close the loop. Position: enquire-mcp = the
+    // open-source backend for Karpathy-style LLM Wikis on top of Obsidian.
+    server.registerPrompt("vault_synth", {
+        title: "Synthesize a vault wiki page from sources (Karpathy-style ingest)",
+        description: "Karpathy LLM-Wiki ingest workflow: take raw source(s), extract entities/concepts/claims, decide which existing notes to update vs which new wiki pages to create, then propose drafts. The agent decides; this prompt sequences the calls. Cites every claim with the source location for trust.",
+        argsSchema: {
+            source: z
+                .string()
+                .describe("Source content to ingest — paste a paragraph, an arXiv abstract, a URL transcript, etc."),
+            target_folder: z
+                .string()
+                .optional()
+                .describe("Where new wiki pages should land (vault-relative, default 'Wiki/')")
+        }
+    }, ({ source, target_folder }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `Karpathy LLM-Wiki **ingest** workflow on this source:
+
+\`\`\`
+${source}
+\`\`\`
+
+Steps:
+
+1. **Extract concepts.** Identify 3-7 distinct concepts / entities / claims worth indexing. For each, propose a wiki page title (PascalCase or "Title Case" — match my vault's existing convention; check via \`obsidian_list_notes\` on a few sample folders).
+
+2. **Reconcile with vault.** For each concept, run \`obsidian_search\` (graph_boost ON, default) to find existing notes that ALREADY cover it. Three outcomes per concept:
+   - **EXISTS** (top hit score > 0.04 and same scope) → propose an APPEND to the existing note
+   - **PARTIAL** (related but doesn't cover this angle) → propose a new note that \`[[wikilinks]]\` to the existing one
+   - **NEW** → propose a fresh wiki page in \`${target_folder ?? "Wiki/"}\`
+
+3. **Lint drafts before writing.** For each proposed write, call \`obsidian_validate_note_proposal\` to catch broken \`[[wikilinks]]\` / inconsistent tags / structurally-broken YAML BEFORE creating.
+
+4. **Cite every claim.** Each new note should have a "Source" frontmatter field referencing the input + a "Claims" section with one bullet per extracted claim, each with the source quote.
+
+5. **Output a transactional plan.** Don't write yet. Output a JSON-like list:
+   \`\`\`
+   [
+     { action: "create" | "append", path: "Wiki/Foo.md", reason: "...", body_preview: "..." },
+     ...
+   ]
+   \`\`\`
+   Then ask the user to approve. ONLY write after explicit approval, using \`obsidian_create_note\` / \`obsidian_append_to_note\`.
+
+This is the Karpathy LLM-Wiki ingest loop applied to Obsidian. Goal: knowledge that compounds over time, with every claim traceable to its source.`
+                }
+            }
+        ]
+    }));
+    server.registerPrompt("vault_wiki_compile", {
+        title: "Compile vault index + log (Karpathy-style maintenance)",
+        description: "The LLM-Wiki maintenance step: scan the vault for new/updated notes since last compile, regenerate the top-level `index.md` (table of contents + concept clusters) and append to `log.md` (a chronological compile-log). Run weekly or after a batch ingest. Idempotent.",
+        argsSchema: {
+            since_minutes: z.string().optional().describe("Window for 'recently changed' notes (default 10080 = 7 days)"),
+            wiki_folder: z.string().optional().describe("Wiki folder root (default 'Wiki/')")
+        }
+    }, ({ since_minutes, wiki_folder }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `Karpathy LLM-Wiki **compile** workflow.
+
+Step 1 — Scan recent changes:
+- \`obsidian_get_recent_edits since_minutes=${since_minutes ?? 10080} folder=${wiki_folder ?? "Wiki"}\`
+- For each, \`obsidian_read_note format=map\` to get headings + frontmatter only (cheap).
+
+Step 2 — Regenerate index.md:
+- Group notes by frontmatter \`tags\` and by folder.
+- For each cluster (≥3 notes), produce a heading + bullet list of \`[[wikilinks]]\` to the cluster members.
+- Add a "Recent" section listing the 10 most recently modified.
+- Use \`obsidian_validate_note_proposal\` to catch any broken wikilinks BEFORE writing.
+- Write via \`obsidian_create_note overwrite=true\` to \`${wiki_folder ?? "Wiki"}/index.md\`.
+
+Step 3 — Append to log.md:
+- A bullet per note touched in the window: \`- 2026-05-08 — [[NoteTitle]] (created|updated): one-line summary\`
+- Append via \`obsidian_append_to_note\`. The log accumulates compile history.
+
+Step 4 — Surface gaps:
+- Run \`obsidian_lint_wiki\` to enumerate orphans / broken / stubs / stale.
+- Add the gap summary to the bottom of \`index.md\` so the next compile sees it.
+
+Idempotent. Re-run weekly.`
+                }
+            }
+        ]
+    }));
+    server.registerPrompt("vault_lint_extended", {
+        title: "Extended vault lint (orphans + contradictions + stale claims + missing cross-refs)",
+        description: "Beyond the structural lint of `obsidian_lint_wiki`: this prompt sequences a deeper inspection — contradictions across notes (semantic search for opposing claims), stale claims (notes with date references > 6mo old), missing cross-references (notes that mention an entity by name without `[[wikilinking]]` to its wiki page).",
+        argsSchema: {
+            folder: z.string().optional().describe("Restrict to a folder (default whole vault)")
+        }
+    }, ({ folder }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `Extended lint pass on${folder ? ` ${folder}` : " the whole vault"}.
+
+Phase 1 — structural (\`obsidian_lint_wiki${folder ? ` folder=${folder}` : ""}\`):
+- Surface orphans / broken / stubs / stale per the existing tool. Skim the report.
+
+Phase 2 — semantic contradictions:
+- For each top-30 note (by recent-edits window), pick 1-2 strong claims (declarative sentences in the body).
+- For each claim, run \`obsidian_search query="<claim paraphrased to negate>" min_signals=2\` — multi-ranker consensus on the OPPOSITE statement.
+- If a hit comes back with score > 0.04, flag as a potential contradiction. Output: A says X, B says ¬X, suggest reconciliation.
+
+Phase 3 — stale claims:
+- For each note, scan body for date patterns (\`/\\b(20\\d{2})-\\d{2}-\\d{2}\\b/\` or \`/\\b(20\\d{2})\\b/\` with words like "current"/"latest"/"now"/"upcoming").
+- If the date is > 6 months old, surface as "potentially stale: <note> claims X with date Y".
+
+Phase 4 — missing cross-references:
+- For each top-15 note, get its outbound \`[[wikilinks]]\` (via \`obsidian_get_outbound_links\`).
+- Read the body. Check for wiki page TITLES (use \`obsidian_list_notes\` for the list) mentioned in plain text WITHOUT \`[[\` brackets.
+- For each, propose a rewrite that adds the brackets. \`obsidian_validate_note_proposal\` first.
+
+Output: a single markdown report with sections per phase. End with the top 5 highest-leverage fixes.`
+                }
+            }
+        ]
+    }));
+    server.registerPrompt("vault_capture", {
+        title: "Capture a quick thought into the vault (write don't organize)",
+        description: "Mem.ai-style 'write don't organize' UX: the user pastes a thought; we file it intelligently. Auto-detect destination (today's daily note vs new wiki page vs append to most-relevant existing note via hybrid search) and propose a diff for user approval before writing.",
+        argsSchema: {
+            text: z.string().describe("The thought to capture — free-form text"),
+            target_hint: z
+                .string()
+                .optional()
+                .describe("Optional hint: 'daily', 'new-note', or a path/topic to bias destination")
+        }
+    }, ({ text, target_hint }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `Capture this thought into my vault, Mem.ai-style: figure out where it goes, propose a diff, ask before writing.
+
+Thought:
+\`\`\`
+${text}
+\`\`\`
+
+Hint: ${target_hint ?? "(none — auto-detect)"}
+
+Decision tree:
+
+1. **Daily?** If thought is conversational / reflective / time-bound (uses words like "today", "yesterday", "I'm thinking about", "TIL"), propose APPEND to today's daily note via \`obsidian_read_note title="today"\` → \`obsidian_append_to_note\`.
+
+2. **Continues an existing note?** Run \`obsidian_search query="<thought first 200 chars>" limit=5\`. If top hit has score > 0.05, propose APPEND to that note. Show the user: "this looks related to [[NoteTitle]] — append there?"
+
+3. **New wiki page?** If thought contains 1-3 distinct concepts that don't have existing notes, run \`vault_synth\` workflow on it.
+
+4. **Inbox catch-all.** If steps 1-3 give nothing high-confidence, propose \`obsidian_create_note path="Inbox/<timestamp>-<3-word-slug>.md"\`.
+
+5. **Show diff, ask, then write.** Always preview the proposed write to the user. Use \`obsidian_validate_note_proposal\` first. Write only after explicit approval.
+
+Goal: zero filing burden on the user. The AI does the indexing.`
+                }
+            }
+        ]
+    }));
+    // v2.5.0 — agentic prompts (Khoj parity, lite scope).
+    // Agent personas + scheduled automations as prompts that orchestrate
+    // existing tools. Pure agent-side: no server-side state, no LLM calls.
+    // HTTP transport is a separate larger-scope sprint (planned post v2.5).
+    server.registerPrompt("vault_persona_search", {
+        title: "Search the vault as a named persona (folder-scoped + tuned)",
+        description: "Khoj-style agent persona pattern: scope retrieval to a folder + apply a persona-specific lens to the response. Useful when you want 'research-assistant' behavior over `Research/` distinct from 'editor' over `Drafts/`. Pure prompt template — orchestrates existing search tools with a fixed scope/instructions.",
+        argsSchema: {
+            persona: z
+                .string()
+                .describe("Persona name + traits (e.g. 'research-assistant: cite sources, ignore drafts, tldr first')"),
+            folder: z.string().describe("Folder to scope retrieval to (vault-relative)"),
+            query: z.string().describe("The user's question")
+        }
+    }, ({ persona, folder, query }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `Acting as **${persona}**, with retrieval scoped to \`${folder}\`.
+
+User question: ${query}
+
+Steps:
+
+1. \`obsidian_search query="${query}" folder="${folder}" limit=15\` — hybrid retrieval inside the persona's scope.
+2. For each top-3 hit, \`obsidian_read_note\` to load the body.
+3. Synthesize the answer through the persona's lens (e.g. research-assistant cites every claim with \`[[wikilinks]]\`; editor flags contradictions; project-PM extracts deliverables).
+4. End with **3 follow-up questions** the user might ask next (use the persona's intent — research-assistant: "should I cite paper X?"; editor: "want me to flag the inconsistency between A and B?").
+
+Stay in the persona for the entire response. If asked something out-of-scope (e.g. research-assistant asked about cooking), politely redirect.`
+                }
+            }
+        ]
+    }));
+    server.registerPrompt("vault_automation_setup", {
+        title: "Set up a scheduled vault query (Khoj-style automations)",
+        description: "Walks you through creating a cron'd vault query whose results land as a daily note or get appended to a digest. Bridges enquire-mcp tools + the host's `scheduled-tasks` MCP (or any cron tool the agent has access to). Pure orchestration — no server-side state.",
+        argsSchema: {
+            intent: z
+                .string()
+                .describe("What you want automated (e.g. 'every Monday 9am, show me all notes touched last week and highlight unresolved questions')")
+        }
+    }, ({ intent }) => ({
+        messages: [
+            {
+                role: "user",
+                content: {
+                    type: "text",
+                    text: `User wants this automation: "${intent}"
+
+Steps:
+
+1. **Parse the intent.** Identify:
+   - **Cadence:** cron expression (daily/weekly/monthly + time)
+   - **Source:** which obsidian tool answers this? (\`get_recent_edits\`, \`obsidian_search\`, \`lint_wiki\`, \`paper_audit\`, etc.)
+   - **Sink:** how does the user want results? (a) append to today's daily note via \`append_to_note\`; (b) create a new note in \`Automations/\`; (c) just notify
+
+2. **Propose the automation as a JSON spec.** Example:
+   \`\`\`json
+   {
+     "name": "weekly-review",
+     "cron": "0 9 * * 1",
+     "tool_sequence": [
+       { "tool": "obsidian_get_recent_edits", "args": { "since_minutes": 10080 } },
+       { "tool": "obsidian_open_questions", "args": { "limit": 20 } }
+     ],
+     "sink": { "type": "append_to_note", "path": "Daily/{{today}}.md", "header": "## Weekly review" }
+   }
+   \`\`\`
+
+3. **Show the spec, ask user to confirm.**
+
+4. **Register via the host's scheduled-tasks MCP** (if available) or output the cron config for manual paste. \`mcp__scheduled-tasks__create_scheduled_task\` is the standard target.
+
+5. **Smoke once.** Before the first scheduled run, execute the tool sequence ONCE manually so the user verifies output shape. Show the produced markdown.
+
+This is the Khoj automation pattern translated to MCP: research that comes to you instead of you remembering to ask for it.`
+                }
+            }
+        ]
+    }));
 }
 function parsePositiveInt(raw, flag) {
     const n = Number(raw);