load-docs

加载文档

用户希望将文档载入你的上下文窗口，以便你在后续轮次中使用。你的任务是完整阅读他们指定的每份文档，然后回复“DONE”。

用户未提供内容时

如果用户调用此技能时没有指定任何文档、文件夹或 URL，请询问他们要加载什么。不要猜测。只问一个简短的问题，然后等待。

什么算作“文档”

用户指向的任何内容：

• 本地文件路径（Read 工具支持的任何类型 — 文本、代码、Markdown、PDF、笔记本、图像）
• 文件夹 / 目录 — 读取其中所有内容，包括子目录，并进行合理筛选（见下文）
• URL — 使用 WebFetch 获取并阅读内容

核心规则：亲自完整阅读

绝不要委托子 Agent 阅读。 这样做的目的是让内容进入你自己的上下文，以便你在后续轮次中回答相关问题。子 Agent 的上下文会在其返回时被丢弃。

从头到尾阅读每份文档。 如果文件长到 Read 一次无法返回全部内容（工具默认最多返回 2000 行，长行也可能被截断），请继续调用 Read，并按块大小递增 offset，直到覆盖整个文件。不要只读第一块就自以为掌握了大意——用户信任你确实已完整读取全部内容。

对于超过 10 页的 PDF，使用 pages 参数分段读取（每次最多 20 页），直到覆盖整份 PDF。

对于 URL，WebFetch 会一次性返回内容——无需分块；但如果响应明显被截断（例如页面内容极多），请如实说明，不要假装已全部读取。

开始前先建立清单

开始阅读前，列出即将加载的每份文档，并使用 TodoWrite 跟踪。每份文档对应一个待办事项。只有完整读取整个文件（所有分块、所有页面）后，才将其标记为已完成。这可以防止遗漏文档——没有清单，就容易漏掉尚未完整读取的内容。

对于文件夹：先列出文件夹内容（使用 Glob 或 Bash ls），按下方规则筛选，然后为筛选后保留的每个文件创建一个待办事项。开始阅读前，应向用户展示完整列表，以便他们在范围选错时进行纠正。

文件夹筛选（合理的默认规则）

当用户指定一个文件夹时，递归纳入所有文件，但排除：

• 隐藏文件和目录（任何以 . 开头的内容 — .git/、.env、.DS_Store 等）
• 依赖目录：node_modules/、vendor/、venv/、.venv/、__pycache__/、dist/、build/、target/、out/
• 锁定文件：package-lock.json、yarn.lock、pnpm-lock.yaml、Cargo.lock、poetry.lock、Gemfile.lock、composer.lock、go.sum
• 不适合作为文档的二进制文件和大型媒体文件：.exe、.dll、.so、.dylib、.zip、.tar、.gz、.mp4、.mov、.mp3、.wav、.iso
• 存在明显的 .gitignore 文件时，其中排除的内容

如果不确定是否应纳入某个文件，就纳入它——多读一个配置文件，总比默默漏掉用户希望读取的内容好。

如果筛选后的文件数量很多（例如 50 个或更多），请在开始前告知用户数量，并询问他们是否要缩小范围。将 200 个文件载入上下文通常不是用户真正想要的。

阅读顺序

按合理顺序阅读——通常按用户列出的顺序，文件夹则按字母顺序。如果有明显的入口文件（README.md、index.md、_index.md），先读它，为其余内容提供背景。

完成后

完成所有清单项后，只回复 DONE，不要添加其他内容。不要总结、回顾，也不要说“我已加载 N 个文档”——只回复 DONE。用户会在下一轮告诉你他们实际想如何处理这些内容；你在这里的任务只是确认加载已完成。

此技能的“单轮”特性意味着：回复 DONE 后，不要继续套用这些指令。如果用户的下一条消息是“第三份文档里写了什么？”，就根据当前已有的上下文正常回答——不要重新执行加载流程。

发生失败时的处理方式

• 找不到文件／权限被拒绝：在回复中说明失败情况（而不是只回复“DONE”），并列出哪些文件已成功读取、哪些失败。不要假装读取了实际上没有读取的内容。
• URL 获取失败：同样如实说明哪些 URL 已加载、哪些未加载。
• 无法筛除的二进制文件或不可读文件：跳过该文件，并在最终回复中说明。

如遇上述任何部分失败情况，最终回复应先提供失败摘要，然后另起一行写上 DONE，让用户知道技能已完成，即使有些内容未能加载。