markdown-vault-query

markdown-vault-query

Use this skill when the user wants answers grounded in a configured Markdown vault.

Workflow

1. Analyze the question before searching. Extract useful keywords: product names, cloud/provider names, system names, aliases, English/Chinese variants, and likely typo corrections. Prefer domain terms over generic words; the provider down-weights vault-specific common tokens, but precise keywords still improve the top results.
2. Call markdown_vault_search for knowledge-base, internal-doc, wiki, runbook, or vault-note questions. Pass both the original query and the expanded keywords.
3. Read the returned text, path, heading_path, and line range as internal evidence. The returned text is not a final answer.
4. Do not pass path_filter for ordinary Q&A. It is only a vault-relative path constraint, in the same format as returned result path values.
5. Use path_filter only when the user explicitly gives a vault-relative directory/file path, or when a previous search result path should be used to narrow a follow-up search. Do not derive path_filter from product names, provider names, provider instance names, knowledge-base names, or topic words.
6. If the top results are too narrow or ambiguous, search again with clearer keywords first. Add path_filter only when the path is explicit or came from prior search evidence.
7. Call markdown_vault_get on the most relevant path and line range when surrounding context matters.
8. Answer with a natural-language synthesis: start with the conclusion or support judgment, then give the minimal supporting details and citations. If the evidence text already contains headings or bullet fields, paraphrase and compress them instead of copying the block.
9. Final answers must not contain the literal Source: label. Cite evidence in prose, for example from path.md or an inline parenthetical citation, and cite each path at most once.

Evidence Rules

• Do not use this provider for every factual question. Use it only when the user intent is document or knowledge-base grounded.
• If no result is returned, say the current knowledge base has no matching evidence.
• Do not claim that an answer came from the vault unless it is supported by returned search or get output.
• Never return raw search results as the final answer. Do not concatenate result blocks, repeated ### ... headings, - Source: sections, JSON payloads, or copied text fields. Use at most the most relevant citations needed to support the answer.
• Specifically, a block that starts with ### ... and then - Source: ... is a vault evidence block, not a final answer format. Convert it into a concise conclusion and a few bullets; cite the source once instead of repeating source headings.
• If multiple search/get results point to the same file, merge them into one answer section. Do not create one section per returned chunk.
• Python retrieval only ranks and bounds Markdown evidence. The Agent LLM remains responsible for final answer synthesis and support judgment.