Answer research questions using vault knowledge and file novel insights back. ALWAYS use this skill when the user asks questions about topics covered in the vault — like "how does X relate to Y", "what do the papers say about Z", "compare approaches to W", or any question that could be answered from existing vault notes. Also activate when the user is discussing connections between concepts, since those discussions may reveal novel links worth filing back.
Answer research questions by reading vault notes, then file novel insights back into the vault automatically. The vault gets smarter with every question asked.
Most knowledge bases are read-only — you search, you get an answer, nothing changes. This skill treats every query as an opportunity to strengthen the vault. If answering a question reveals a connection between two concepts that aren't linked, or surfaces a pattern across papers that isn't captured in any MOC, file it back. The user expects this — they don't want to manually update concept notes after every conversation.
Run commonplace vault-path to get the vault path. Use it in all paths below.
Never load full index files — they grow without bound. Use Grep to target specific entries.
Index schemas (for reference):
source-index.json — top-level JSON array, fields: , , , , , , titlepathdomainscopetagsconceptsmocsconcept-index.json — top-level JSON array, fields: name, path, domains, backlinkCount, isStubSearch strategy:
Start with Grep on the indexes using terms from the user's question:
Grep "<term>" "$VAULT_PATH/.wiki/source-index.json"
Grep "<term>" "$VAULT_PATH/.wiki/concept-index.json"
Iterate with derived terms — look at what you find and generate new search terms from it. If a source note mentions [[Concept X]], grep for that. If a concept appears in two domains, grep for it in both. Don't stop at the first pass.
Traverse the graph — concepts are nodes, wikilinks are edges. Don't just find nodes, follow edges:
backlinkCount in concept-index.json is a corpus-wide signal. High count = referenced across many papers, not just one. Prioritize these.Grep "\[\[ConceptName\]\]" "$VAULT_PATH" --include="*.md"
moc-index.json for relevant MOCs, read the MOC note to get the full paper list for that subfield, then drill into specific papers.builds_on, compares_with, uses_method frontmatter. If a paper is relevant, grep for its title in those fields to find papers that build on or compare against it — this follows the citation graph without needing external tools.domains array in concept-index.json entries. A concept appearing in 2+ domains is a cross-domain bridge — especially powerful for synthesis questions because it connects otherwise separate clusters.Grep vault notes for terms not caught by the index:
Grep "<term>" "$VAULT_PATH" --include="*.md"
Read relevant notes: Once you find matches, read the full notes for context
[[wikilinks]] when mentioning vault concepts or papersEvery query is an opportunity to strengthen the vault. While synthesizing, decide what to file:
Always file concept connections — if you found links not currently captured in concept notes:
updated date in frontmattercommonplace scope-check --vault "$VAULT_PATH" "<file>"
File synthesis pages by default — this is the most important operation. Answers that draw on 2+ sources, reveal non-obvious connections, or produce structured comparisons are vault pages, not chat messages. The threshold is low: if it took real work to synthesize, it belongs in the vault. Don't ask — just file it.
Good candidates:
---