// 翻译 Markdown 文档为中文，并格式化为 Obsidian 兼容的 Markdown。用户指定文件或目录路径，翻译 front matter（title 简化翻译、description 翻译）和正文内容，使用 Obsidian Callout 等语法美化输出。触发词：翻译文档、translate、翻译 markdown、doc translate、翻译文件、translate doc。即使用户只说"翻译这个文件"或"把这个翻译一下"也应该触发此 skill。
删除 Wiki 中的源资料及其关联页面，级联清理索引、引用和元数据。触发词包括：删除、delete、移除、remove、清理 wiki、清理摄入。当用户想删除某个已摄入的资料或清理错误摄入的内容时使用。不用于摄入新资料、查询或健康检查。
摄入新资料到 LLM Wiki 知识库。当用户提供新的文章、论文、笔记、截图等资料要求添加到知识库时使用。触发词包括：摄入、ingest、添加资料、新资料、导入、导入资料、摄入资料、添加到 wiki、加入知识库。即使用户只说"帮我整理这篇资料"或"把这个加入知识库"也应该触发。不用于查询知识库内容或检查 Wiki 健康。无参数调用时自动扫描 raw/ 目录处理未摄入的文件。
检查 LLM Wiki 知识库的健康状况。扫描所有 Wiki 页面，发现矛盾、过时信息、孤立页面、失效链接、缺失摘要等问题。触发词包括：lint、检查、wiki 检查、健康检查、检查 wiki、wiki lint、检查知识库。即使用户只说"检查一下知识库"或"wiki 有没有问题"也应该触发。不用于摄入新资料或查询知识库内容。
查询 LLM Wiki 知识库内容并基于 Wiki 页面回答问题。当用户的问题涉及知识库中已有内容时使用——技术概念解释、实体信息、主题对比、知识关联等。触发词包括：查询、query、搜索、查找、搜索知识库、查一下、问一下。当用户问的是知识库覆盖的话题（编程、数学、密码学、设计模式、Docker、Git、OAuth2 等已有概念），即使没有明确说"查询知识库"，也应考虑使用。不用于摄入新资料或检查 Wiki 健康。
通过网络搜索深入研究某个主题，自动将搜索结果摄入知识库。触发词包括：研究、research、深入调查、搜索资料、查资料、调研。当用户想对某个主题进行深入研究或知识库内容不足需要补充时使用。不用于摄入已有文件（/ingest）、查询知识库（/query）或删除内容（/delete）。
Generate Excalidraw diagrams from text content for Obsidian. Use when user asks to create diagrams, flowcharts, mind maps, or visual representations in Excalidraw format. Triggers on "Excalidraw", "画图", "流程图", "思维导图", "可视化", "diagram".
| name | doc-translate |
| description | 翻译 Markdown 文档为中文，并格式化为 Obsidian 兼容的 Markdown。用户指定文件或目录路径，翻译 front matter（title 简化翻译、description 翻译）和正文内容，使用 Obsidian Callout 等语法美化输出。触发词：翻译文档、translate、翻译 markdown、doc translate、翻译文件、translate doc。即使用户只说"翻译这个文件"或"把这个翻译一下"也应该触发此 skill。 |
将英文 Markdown 文档翻译为中文，同时将输出格式化为 Obsidian 兼容的 Markdown 文档。
这个 skill 做且只做一件事：原地翻译指定的 Markdown 文件。
AskUserQuestion 主动询问。.md 文件，逐个翻译。文件大小 > 30KB 时，必须使用 general-purpose subagent 执行翻译。
原因：大文件翻译需要多次分段读取和多次 edit，容易填满主会话 context；会话压缩后需要重建翻译状态，效率低且容易出错。
操作方式：
Get-Item <path> | Select-Object -ExpandProperty Length）general-purpose subagent，将完整翻译任务（含文件路径、翻译规范、术语约定）作为 prompt 传入用 Read 工具读取源文件内容。
分析文档顶部的 YAML front matter（--- 包裹的部分）：
| 字段 | 处理规则 |
|---|---|
title | 简化并翻译为中文。如果原标题冗长，提取核心含义。如果不存在 title 字段，从文档第一个 H1 标题提取并创建 |
description | 翻译为中文。如果不存在则忽略，不创建 |
| 其他字段 | 保留原样，不做修改 |
title 简化原则：去掉冗余修饰词，保留核心主题。例如 "Getting Started with Spring Security Authentication" → "Spring Security 认证入门"。
目标是产出自然流畅的中文，读起来像是由母语工程师撰写的——而非机器翻译的逐字对应。
术语处理是翻译质量的核心分界线。分四种情况：
情况 1：行业通用英文术语——保持英文，不加注解
在中文技术写作中广泛使用的术语应保持英文原样，不要强行翻译，也不需要附加中文注解：
Spring Boot、Bean、Controller、Handler、Provider、Service、Repository、Promise、Hook、middleware、payload、token、socket、pipeline、callback、namespace、runtime、mock、stub、framework、plugin、schema、endpoint、request、response、session、cookie、header 等。
正确示例：Controller 负责处理 HTTP 请求。
错误示例：Controller（控制器）负责处理 HTTP 请求。
错误示例：控制器负责处理 HTTP 请求。
情况 2：英文术语+首次出现附中文注解
当保留英文术语有助于精确性或符合标准实践时，保留英文，首次出现时在括号中附加简短中文注解：
Interceptor（拦截器）、Circuit Breaker（熔断器）、Service Mesh（服务网格）、Dead Letter Queue（死信队列）
注解只在术语首次出现时添加，后续出现保持纯英文。
情况 3：中文术语+附英文原文
对于翻译成中文的术语，在括号中附加英文原文：依赖注入 (Dependency Injection)、消息队列 (Message Queue)、反向代理 (Reverse Proxy)。
情况 4：纯中文通用术语
如果术语本身已经是中文技术写作中的通用表达（如"数据库"、"服务器"、"线程"、"接口"），直接使用中文，不需要附加英文。
将翻译后的内容按照 Obsidian 兼容的 Markdown 语法进行格式化。
根据原文内容语义，适当添加 Obsidian Callout 提升可读性：
> [!note] 标题
> 内容
> [!tip] 标题
> 内容
> [!warning] 标题
> 警告内容
> [!info] 标题
> 补充说明
适用场景：
note：一般性备注info：补充说明、背景知识tip：实用技巧、最佳实践warning：注意事项、潜在问题danger：严重警告、可能导致数据丢失等example：示例说明abstract：摘要、总结question：常见问题bug：已知问题Callout 语法规则：
> 引用块语法，[!type] 后跟标题> 开头> 前加 > 表示嵌套层级使用标准 Markdown 代码块，Obsidian 原生支持语言标识符高亮：
```java
// 代码内容
```
如果需要标注代码来源文件，在代码块上方用普通文本说明，不使用特殊属性语法。
翻译过程中遇到原文的交叉引用时：
[[页面名]] 双链语法保留原有的 Markdown 表格和列表格式，内容翻译为中文。
依赖注入 (Dependency Injection)** 加粗正文文本完成翻译后，对照以下清单自检：
> [!type] 标题 + > 前缀内容）