name	sunday-note-ingest
description	当任务涉及 ingest / 资料摄取：整理、吸收或处理外部资料、待处理材料或 Raw source，并判断是否值得长期保留、应放入哪一层、如何形成可复用结论时使用。

Ingest

判断规则

先判断资料是否值得沉淀，再决定去向。
只有相对 LLM 默认知识和普通互联网搜索都有增量的信息，才是高价值候选。
增量不要求信息完全独有；更深入、更有组织、密度更高、更贴近用户项目或包含已确认判断，也算增量。
仅当需要判断普通搜索可替代性或外部事实可靠性时，才搜索核验；资料价值来自用户项目上下文、个人事实或已确认判断时，不默认搜索。

工作流

读取路径配置解析 Raw、Routine、Wiki、Journal、Schema 路径；不要假设目录名。
按判断规则评估资料价值和去向。
区分来源事实、agent 推断和需要用户确认的问题，避免把外部观点或模型推理写成用户已确认判断。
对 Wiki 候选，优先建议更新已有同主题页面，并按既有 Wiki header 处理字段；涉及长期兴趣、近期计划、推荐偏好、当前项目或明确不感兴趣方向时，优先建议更新个人上下文页面，而不是新建零散偏好页。
只有候选会影响核心导航或维护历史时，才建议更新 index 或 maintenance log。
给出来源、价值判断、建议去向和待确认问题；需要写入时，按知识库写入规则确认后再修改或创建文件。

Wiki header 更新规则

更新已有页面：用标题、topic、keywords 和正文主题识别同主题页面；正文结论或来源实质变化时更新 last_updated、update_count 和 sources。
创建新候选：生成最小 header；last_updated 写当天，update_count: 1，last_queried: ""，query_count: 0，sources 指向当前资料。
topic 写单一稳定主题，用于 query 判断页面归属和合并边界，不用 ingest 材料临时改写已有主题。
keywords 写 3-8 个能帮助 query 命中的真实检索词，包含实体名、项目名、术语、常用问法或中英文变体，不写任务动词、泛词和临时状态词。

结构原则

不套固定模板；按材料类型、用途和未来使用场景选择结构，只重组会影响理解、判断或复用的部分。
需要回答问题或形成建议时，可用 SCQA 梳理背景、冲突、问题和回答。
需要表达结论时，可用金字塔原则组织：核心判断 -> 分组理由 -> 来源证据。
需要拆分复杂内容时，分组尽量清楚，避免混合不同主题、层级或来源。
Wiki 正文不保存来源结构复述；不要写“本文 / 本章 / 本节 / 主要介绍了 / 内容包括 / 围绕……展开”等只描述材料结构的句子。
每个写入 Wiki 的段落必须包含可独立复用的知识增量：事实、判断、关系、约束、经验模式、已确认结论、来源证据或待确认问题。
追加已有 Wiki 时，优先合并到最相关段落或新增短条目；正文只写可复用知识，因果解释、适用条件和反例必须是知识本身，不写“本次补充 / 基于以上 / 下面整理 / 我将更新”等写入过程、分析步骤、解释性铺垫或 agent 操作说明。
写入 Wiki 时，用户可读内容写在正文；仅供 agent 维护、继续编译、待确认或复查的内容写入 Obsidian 注释块 %% agent ... %%。

Más de este repositorio

mismo repositorio

paper-summarizer

Sunday514/SundayNoteAgent

从本地 PDF 论文解析正文和图表，整理贡献、方法、实验与局限，并生成以论文标题命名的单篇 Raw 总结。用于论文精读和来源摘要任务；PDF 和全部解析过程产物留在 `.import_files/`，实际引用图像写入 vault 的 assets 图像目录。不用于跨论文 Wiki 沉淀、项目调研报告或方案设计。

2026-07-102

sunday-note-lint

Sunday514/SundayNoteAgent

检查知识库健康度并编排 lint 维护。用于用户明确要求 lint、清理、合并、去重、修复或维护 Wiki 与个人上下文时，生成维护计划、写维护日志、创建 worker subagent 执行具体写入任务并复核结果；主 agent 不直接改写普通 Wiki 正文。

2026-07-052

sunday-note-query

Sunday514/SundayNoteAgent

使用已有个人知识库上下文回答、判断、规划、推荐或讨论。用于用户询问个人记录、知识库内容、历史决策、已有项目、个人偏好、长期目标、近期计划、推荐偏好、工作流、规则文档、过往方案，或开放问题的答案可能被既有个人上下文改变，例如“适不适合我”“下一步怎么做”“推荐什么”“之前怎么定的”“按我的记录来看”。优先最少证据检索；不要用于通用知识、普通技术问答、纯外部事实查询、当前对话已足够回答的问题、资料摄取或知识库维护。

2026-07-042

Ingest

判断规则

先判断资料是否值得沉淀，再决定去向。

只有相对 LLM 默认知识和普通互联网搜索都有增量的信息，才是高价值候选。

增量不要求信息完全独有；更深入、更有组织、密度更高、更贴近用户项目或包含已确认判断，也算增量。

仅当需要判断普通搜索可替代性或外部事实可靠性时，才搜索核验；资料价值来自用户项目上下文、个人事实或已确认判断时，不默认搜索。

工作流

读取路径配置解析 Raw、Routine、Wiki、Journal、Schema 路径；不要假设目录名。

按判断规则评估资料价值和去向。

区分来源事实、agent 推断和需要用户确认的问题，避免把外部观点或模型推理写成用户已确认判断。

对 Wiki 候选，优先建议更新已有同主题页面，并按既有 Wiki header 处理字段；涉及长期兴趣、近期计划、推荐偏好、当前项目或明确不感兴趣方向时，优先建议更新个人上下文页面，而不是新建零散偏好页。

只有候选会影响核心导航或维护历史时，才建议更新 index 或 maintenance log。

给出来源、价值判断、建议去向和待确认问题；需要写入时，按知识库写入规则确认后再修改或创建文件。

Wiki header 更新规则

更新已有页面：用标题、topic、keywords 和正文主题识别同主题页面；正文结论或来源实质变化时更新 last_updated、update_count 和 sources。

创建新候选：生成最小 header；last_updated 写当天，update_count: 1，last_queried: ""，query_count: 0，sources 指向当前资料。

topic 写单一稳定主题，用于 query 判断页面归属和合并边界，不用 ingest 材料临时改写已有主题。

keywords 写 3-8 个能帮助 query 命中的真实检索词，包含实体名、项目名、术语、常用问法或中英文变体，不写任务动词、泛词和临时状态词。

结构原则

不套固定模板；按材料类型、用途和未来使用场景选择结构，只重组会影响理解、判断或复用的部分。

需要回答问题或形成建议时，可用 SCQA 梳理背景、冲突、问题和回答。

需要表达结论时，可用金字塔原则组织：核心判断 -> 分组理由 -> 来源证据。

需要拆分复杂内容时，分组尽量清楚，避免混合不同主题、层级或来源。

Wiki 正文不保存来源结构复述；不要写“本文 / 本章 / 本节 / 主要介绍了 / 内容包括 / 围绕……展开”等只描述材料结构的句子。

每个写入 Wiki 的段落必须包含可独立复用的知识增量：事实、判断、关系、约束、经验模式、已确认结论、来源证据或待确认问题。

追加已有 Wiki 时，优先合并到最相关段落或新增短条目；正文只写可复用知识，因果解释、适用条件和反例必须是知识本身，不写“本次补充 / 基于以上 / 下面整理 / 我将更新”等写入过程、分析步骤、解释性铺垫或 agent 操作说明。

写入 Wiki 时，用户可读内容写在正文；仅供 agent 维护、继续编译、待确认或复查的内容写入 Obsidian 注释块 %% agent ... %%。