以下是对提供的技能说明文档的中文翻译，保持原有格式不变：
name: reduce description: 从源材料中提取结构化知识。全面提取是默认行为——每个服务于领域的洞见都会被提取。对于领域相关的源材料，跳过率必须低于10%。如果领域相关的源材料完全没有提取，则是BUG。触发词包括 “/reduce”, “/reduce [file]”, “extract insights”, “mine this”, “process this”。 version: “1.0” generated_from: “arscontexta-v1.6” user-invocable: true allowed-tools: Read, Write, Grep, Glob, mcp__qmd__vector_search context: fork
运行时配置（步骤0 — 在任何处理之前）
阅读这些文件以配置特定于领域的的行为：
-
ops/derivation-manifest.md— 词汇映射，提取类别，平台提示- 使用
vocabulary.notes表示笔记文件夹名称 - 使用
vocabulary.inbox表示收件箱文件夹名称 - 使用
vocabulary.note表示输出中的笔记类型名称 - 使用
vocabulary.note_plural表示复数形式 - 使用
vocabulary.reduce表示输出中的过程动词 - 使用
vocabulary.cmd_reflect表示下一阶段命令名称 - 使用
vocabulary.cmd_reweave表示回溯命令名称 - 使用
vocabulary.cmd_verify表示验证命令名称 - 使用
vocabulary.extraction_categories表示领域特定的提取表 - 使用
vocabulary.topic_map表示MOC/主题地图引用 - 使用
vocabulary.topic_maps表示复数形式
- 使用
-
ops/config.yaml— 处理深度，管道链，选择性processing.depth: deep | standard | quickprocessing.chaining: manual | suggested | automaticprocessing.extraction.selectivity: strict | moderate | permissive
-
ops/queue/queue.json— 当前任务队列（用于手工交接模式）
如果这些文件不存在（预初始化调用或独立使用），则使用通用默认值：
- depth: standard
- chaining: suggested
- selectivity: moderate
- 笔记文件夹：
notes/ - 收件箱文件夹：
inbox/
任务（阅读此内容否则会失败）
你是提取引擎。原始源材料进入。结构化，原子化的{vocabulary.note_plural}退出。两者之间的一切都是你的判断 — 而且这个判断必须倾向于提取，而不是拒绝。
核心区别
| 概念 | 它意味着什么 | 示例 |
|---|---|---|
| 拥有知识 | 金库包含信息 | “我们在文件夹中存储笔记” |
| 表达推理 | 金库解释为什么某事像可遍历的{vocabulary.note}一样工作 | “文件夹结构之所以能够反映认知块，是因为…” |
**拥有知识与表达它不是一回事。**即使信息嵌入在系统中，金库可能缺乏解释为什么它有效的外部推理。这种推理就是你提取的内容。
全面提取原则
**对于领域相关的源材料，默认进行全面提取。**这意味着：
-
提取全部核心{vocabulary.note_plural} — 直接断言领域，可以独立作为原子命题。
-
提取全部证据和验证 — 如果源材料确认一种方法，那么这种确认就是{vocabulary.note}。即使结论已经知道，证据也是可提取的，因为推理路径很重要。
-
提取全部模式和方法 — 技术，工作流程，实践。命名模式是可引用的。未命名的直觉不是。
-
提取全部紧张关系 — 矛盾，权衡，冲突。这些是智慧，不是问题。
-
提取全部丰富内容 — 如果源材料为现有的{vocabulary.note_plural}添加细节，创建丰富任务。近重复几乎总是增加价值。
"我们已经知道这个"意味着我们需要这种表述，而不是我们应该跳过它。
提取问题（针对每个候选项提问）
“未来的会议会从这个推理作为一个可检索的{vocabulary.note}中受益吗？”
如果YES -> 提取到适当类别 如果NO -> 验证它是否真的离题，然后再跳过
无效跳过理由（这些是BUGS）
- “验证现有的方法” — 验证是证据。提取它们。
- “已经在系统配置中捕获” — 配置是实现，不是表述。为什么需要一个{vocabulary.note}。
- “我们已经这样做了” — 做不等于解释。需要外部化解释。
- “显而易见” — 对谁来说显而易见？未来的会议需要明确的推理。
- “近重复” — 近重复几乎总是增加细节。创建丰富任务。
- “不是一个声明” — 它是一个实施想法吗？紧张？验证？那些都是可提取的。
有效跳过理由（很少）
- 完全离题（与{vocabulary.domain}无关）
- 太模糊，无法采取行动（适用于一切，不同意任何事）
- 纯粹的总结，没有可提取的洞察力
- 字面上完全相同的文本已经存在（不是"同一主题" — 完全相同）
对于领域相关的源材料：跳过率 < 10%。零提取=BUG。
立即执行
目标：$ARGUMENTS
立即解析：
- 如果目标包含文件路径：从该文件中提取洞察力
- 如果目标包含
--handoff：输出RALPH HANDOFF块+任务条目在末尾 - 如果目标为空：扫描{vocabulary.inbox}/中的未处理项目，挑选一个
- 如果目标是"inbox"或"all"：顺序处理所有收件箱项目
执行以下步骤：
- 完全阅读源文件 — 理解它包含什么
- 源大小检查： 如果源超过2500行，停止。计划350-1200行的块。用新鲜上下文处理每个块。见"大源处理"部分。
- 寻找服务于领域的洞察力（见下面的提取类别）
- 对于每个候选项：
- Tier 1（首选）：使用
mcp__qmd__vector_search查询"[claim as sentence]“，集合=”{vocabulary.notes_collection}"，限制=5 - Tier 2（CLI回退）：
qmd vsearch "[claim as sentence]" --collection {vocabulary.notes_collection} -n 5 - Tier 3如果qmd不可用：使用关键字grep重复检查
- 如果存在重复：评估是否丰富或跳过
- 分类为OPEN（需要更多调查）或CLOSED（独立，准备好）
- Tier 1（首选）：使用
- 输出提取报告，包括标题，分类，提取理由
- 等待用户批准后再创建文件
- 如果目标中有
--handoff：为每个声明创建任务文件，更新队列，输出RALPH HANDOFF块
**现在开始。**参考下面的方法 — 用于指导，而不是输出。
观察捕获（工作期间，而不是结束时）
当你遇到摩擦，惊喜，方法论洞察，流程差距或矛盾 — 立即捕获：
| 观察 | 行动 |
|---|---|
| 任何观察 | 在 ops/observations/ 中创建原子笔记，标题为散文句 |
| 紧张：内容与现有{vocabulary.note}矛盾 | 在 ops/tensions/ 中创建原子笔记，标题为散文句 |
处理过程中的学习部分总结了你已经记录的内容。
Reduce
从源材料中提取可组合的{vocabulary.note_plural}到{vocabulary.notes}/。
哲学
提取背后的原因，而不仅仅是关于什么有效的观察。
这是管道的提取阶段。你接收原始内容并提取服务于金库领域的洞察力。任务是构建外部化，可检索的推理 — 一个可以遍历，连接和构建的原子命题图。
核心区别：
| 概念 | 示例 | 需要提取的内容 |
|---|---|---|
| 我们这样做 | “We tag notes with topics” | — （不足够） |
| 我们解释为什么 | “topic tagging enables cross-domain navigation because…” | 这个 |
金库不仅仅是一个实现。它是为什么实现有效的论述。
提取问题：
- 基本思考：“这是一个独立的可组合声明吗？”
- 更好的思考：“这服务于{vocabulary.domain}吗？”
- 最好的思考：“未来的会议会从这个推理作为一个可检索的{vocabulary.note}中受益吗？”
如果YES -> 提取到适当类别（即使"我们已经知道这个"） 如果NO -> 跳过（对于领域相关的源材料 — 真正离题的很少）
**规则：**没有表述的实现是不完整的。如果我们做了某事但缺乏解释为什么它有效的{vocabulary.note}，那么这种表述需要提取。
提取类别
需要提取什么
{DOMAIN:extraction_categories}
**结构不变：**每个领域的提取都有这些通用类别，无论领域如何：
| 类别 | 寻找什么 | 输出类型 | 需要门吗？ |
|---|---|---|---|
| 核心领域{vocabulary.note_plural} | 关于{vocabulary.domain}的直接断言 | {vocabulary.note} | NO |
| 模式 | 跨源的重复结构 | {vocabulary.note} | NO |
| 比较 | 不同方法的比较，X vs Y，权衡 | {vocabulary.note} | NO |
| 紧张 | 矛盾，冲突，未解决的权衡 | 紧张笔记 | NO |
| 反模式 | 什么破坏，什么避免，失败模式 | 问题笔记 | NO |
| 丰富 | 为现有{vocabulary.note_plural}添加细节的内容 | 丰富任务 | NO |
| 开放问题 | 值得跟踪的未解决问题 | {vocabulary.note}（开放） | NO |
| 实施想法 | 要构建的技术，工作流程，功能 | 方法论笔记 | NO |
| 验证 | 确认方法有效的证据 | {vocabulary.note} | NO |
| 离题的一般内容 | 与{vocabulary.domain}无关的洞察 | 应用选择性门 | YES |
**重要：**类别1-9绕过选择性门。它们直接提取到适当的输出类型。选择性门仅用于过滤一般源中的离题内容。
类别检测信号
在每个源中寻找这些信号：
核心领域信号：
- 直接断言：“关键洞察是…”, “这意味着…”, “模式是…”
- 证据：“研究表明…”, “数据表明…”, “研究确认…”
- 命名方法：任何命名的系统，技术或框架，与{vocabulary.domain}相关
比较信号：
- “X vs Y”, “权衡…”, “首选X当…”, “不像Y，这个…”
- “选择X当…”, “取决于…”
紧张信号：
- "与…"相反，“然而…”, "与…"的问题，“失败时…”
- “另一方面…”, "但这与…"冲突
反模式信号：
- “系统失败当…”, “反模式是…”, “避免这个因为…”
- 警告，警示性例子，失败事后分析
丰富信号：
- 内容涵盖与现有{vocabulary.note}相似的领域
- 新例子，证据，或为已建立的声明提供的框架
- 对已经浅层次捕获的内容的更深入解释
实施信号：
- “我们可以构建…”, “将使…”, “一个工具…”, “模式为…”
- 可操作的技术，具体的工作流程
验证信号：
- “这支持…”, “证据表明…”, “验证…”, “确认…”
- 将现有实践与理论联系起来的研究
任务镜头（必需）
对于每个候选项，问：“这服务于{vocabulary.domain}吗？”
- YES -> 提取到适当类别（门不适用）
- NO -> 应用选择性门（仅限离题过滤）
**对于领域相关的源：**几乎所有内容都是YES。门几乎不适用。跳过率 < 10%。
选择性门（用于离题内容过滤）
**关键：**这个门用于过滤不服务于{vocabulary.domain}的内容。它仅适用于一般（离题）源的标准声明。
不要使用门拒绝：
- 实施想法（"不是一个声明"是错误的 — 它是路线图）
- 紧张（"不是一个声明"是错误的 — 它是智慧）
- 丰富（"重复"是错误的 — 它增加了细节）
- 验证（"已经知道"是错误的 — 它是证据）
- 开放问题（"不可测试"是错误的 — 它是方向）
对于一般源的标准声明，验证所有四个标准都通过：
1. 独立
声明在没有源上下文的情况下是可以理解的。有人冷读这个{vocabulary.note}可以把握它争论的内容，而不需要知道它来自哪里。
失败：“作者关于方法论的第三点” 通过：“显式结构击败隐式约定”
2. 可组合
这个{vocabulary.note}将从其他地方链接。{vocabulary.note_plural}作为APIs。如果你不能想象在另一个{vocabulary.note}中写since [[this claim]]...，那么它不是可组合的。
失败：某人论点的总结 通过：你可以在自己的论点中调用的声明
3. 新颖
在金库中尚未捕获。语义重复检查和现有的{vocabulary.note_plural}扫描都清楚。
失败：与现有{vocabulary.note}语义上等价 通过：真正新的角度尚未表述
4. 连接
与金库中现有的思考相关。孤立的洞察力如果不连接到任何内容，就会腐烂。
失败：关于不相关领域的有趣观察 通过：扩展，矛盾或深化现有的{vocabulary.note_plural}
如果任何标准失败：不要提取。
工作流程
1. 定位
在阅读源之前，了解已经存在的内容：
# 从现有笔记中获取描述
for f in {vocabulary.notes}/*.md; do
[[ -f "$f" ]] && echo "=== $(basename "$f" .md) ===" && rg "^description:" "$f" -A 0
done
扫描描述以了解当前的{vocabulary.note_plural}。这可以防止重复提取，并有助于识别连接点和丰富机会。
2. 完整阅读源
阅读整个源。了解它包含什么，它争论什么，它服务哪个领域。
计划提取：
- 你期望从这个源中得到多少{vocabulary.note_plural}？
- 哪些类别将被代表？
- 这是领域相关的（全面提取）还是一般的（门适用）？
明确信号短语要寻找：
- “关键洞察是…”
- “这意味着…”
- “模式是…”
- "与…"相反
- “含义…”
- “这里真正重要的是…”
- “真正的问题是…”
- “这表明…”
隐含信号（最好的洞察力经常隐藏在）：
- 暗示解决方案的问题
- 揭示有效方法的约束
- 暗示方法的失败
- 包含原则的旁白
- 揭示心智模型的偏离
你正在寻找的：
- 可以争论的断言
- 适用于这个特定源之外的模式
- 改变你对某事思考的洞察力
- 将在其他地方调用的声明
3. 首先分类，然后路由（强制性）
停止。在任何过滤之前，确定每个候选项的类别。
这是防止过度拒绝的关键步骤。首先分类，然后路由到适当的提取路径。
| 类别 | 如何识别 | 路由到 |
|---|---|---|
| 核心领域{vocabulary.note} | 关于{vocabulary.domain}的直接断言 | -> {vocabulary.note}（跳过选择性门） |
| 实施想法 | 描述要构建的功能，工具，系统或工作流程 | -> 方法论笔记（跳过选择性门） |
| 紧张/挑战 | 描述冲突，风险或权衡 | -> 紧张笔记（跳过选择性门） |
| 验证 | 确认方法有效的证据 | -> {vocabulary.note}（跳过选择性门） |
| 近重复 | 语义搜索找到相关的金库{vocabulary.note} | -> 评估是否丰富任务 |
| 离题声明 | 一般洞察力不是关于{vocabulary.domain} | -> 应用选择性门 |
**关键：**实施想法，紧张，验证和领域{vocabulary.note_plural}不需要通过4标准选择性门。门仅用于离题过滤。
**为什么这很重要：**选择性门旨在过滤一般洞察力。但实施想法（“构建小径功能”），紧张（“优化与可读性的权衡”）和验证（“研究确认我们的方法”）是不同的输出类型，服务于不同的目的。将选择性门应用于它们是类别错误。
4. 语义搜索重复和丰富
对于每个候选项，运行重复检测：
mcp__qmd__vector_search query="[proposed claim as sentence]" collection="{vocabulary.notes_collection}" limit=5
如果MCP不可用，运行：
qmd vsearch "[proposed claim as sentence]" --collection {vocabulary.notes_collection} -n 5
如果qmd CLI不可用，回退到关键字grep重复检查。
**为什么使用vector_search（向量语义）而不是关键字搜索：**重复检测是关键字搜索最难的地方。关于"系统中的摩擦"的声明将不会通过关键字匹配找到"对变化的抵抗"，即使它们可能是语义重复，向量搜索（~5s）捕获了关键字搜索完全错过的相同概念的不同单词的重复。对于30-50个候选项的批次，这总共增加了~3分钟 — 值得在{vocabulary.cmd_reflect}期间而不是发现重复。
**分数是信号，不是决定。**对于任何标题或片段相关的结果：
- 阅读完整的{vocabulary.note}
- 比较：这是用不同的话说的同一个声明吗？
- 问：“源添加了什么现有{vocabulary.note}缺少的内容？”
丰富判断（默认丰富）：
| 情况 | 行动 |
|---|---|
| 确切文本已经存在 | 跳过（真正相同 — 罕见） |
| 相同的声明，不同的词，源没有添加任何内容 | 跳过（通过重新阅读现有{vocabulary.note}验证） |
| 相同的声明，源有更多细节/例子/框架 | -> 丰富任务（更新现有{vocabulary.note}） |
| 同一主题，不同的声明 | -> 提取为新的{vocabulary.note}，标记为交叉链接 |
| 相关机制，不同的范围 | -> 提取为新的{vocabulary.note}，标记为交叉链接 |
**默认丰富。**如果源提到了相同的主题，它几乎肯定增加了一些东西。真正相同的内容是罕见的。
当语义搜索发现重叠时的强制性协议：
- 阅读完整的现有{vocabulary.note}（不仅仅是标题/描述）
- 问：“源添加了什么现有{vocabulary.note}缺少的内容？”
- 新例子 -> 丰富
- 更深入的框架 -> 丰富
- 引用/证据 -> 丰富
- 不同的角度 -> 丰富
- 具体的实施细节 -> 丰富
- 字面上相同 -> 跳过（罕见）
- 如果源添加了任何内容：创建丰富任务
- 只有在源完全没有添加新内容时才跳过（通过这个声明验证）
**近重复是机会，不是拒绝。**创建丰富任务是正确的行为。如果你在没有丰富任务的情况下跳过近重复，你可能是错误的。
5. 对每个提取进行分类
每个提取的候选项都进行分类：
- CLOSED — 独立的声明，设计决策，可以立即处理
- OPEN — 需要更多调查，可测试的假设，需要证据
分类影响下游处理，但不会影响是否提取。开放和封闭的候选项都提取。
6. 展示发现
按类别报告你找到了什么。包括计数：
提取扫描完成。
摘要：
- {vocabulary.note_plural}: N
- 实施想法：N
- 紧张：N
- 丰富任务：N
- 验证：N
- 开放问题：N
- 跳过：N
- 总输出：N
---
声明（{vocabulary.note_plural}）：
1. [声明作为句子] — 连接到 [[现有笔记]]
2. [声明作为句子] — 扩展 [[现有笔记]]
...
实施想法（方法论笔记）：
1. [功能/模式] — 它使什么成为可能，为什么重要
...
紧张（紧张笔记）：
1. [X vs Y] — 冲突，为什么重要
...
丰富任务（更新现有{vocabulary.note_plural}）：
1. [[现有笔记]] — 源添加了[缺少的内容]
...
跳过（真的没有什么可添加的）：
- [描述] — 为什么没有可提取的
**等待用户批准后再创建文件。**永远不要自动提取。
7. 提取（用户批准后）
对于每个批准的{vocabulary.note}：
a. 制作标题
标题就是声明。用确切的词表达概念。
测试：“这个{vocabulary.note}争论[标题]”
- 必须在语法上讲得通
- 必须是你可以同意或不同意的东西
- 可组合性优于简洁性 — 如果概念需要，一个完整的句子是可以的
- 小写与空格
- 没有打破文件系统的标点：. * ? + [ ] ( ) { } | \ ^
好的：“显式结构击败隐式约定以导航代理” 好的：“小差异通过重复选择复合” 坏的：“上下文管理策略”（主题标签，不是声明）
b. 编写{vocabulary.note}
---
description: [~150字符详细说明声明，增加信息超过标题]
type: [claim | methodology | problem | learning | tension]
created: YYYY-MM-DD
[领域特定的字段来自派生宣言]
---
# [散文标题命题]
[正文：150-400字显示推理]
使用连接词：因为，但，因此，这意味着，然而。
在适当的时候承认不确定性。
考虑最强烈的反对意见。
展示通往结论的路径，不仅仅是结论。
---
源：[[源文件名]]
相关笔记：
- [[相关声明]] — [为什么它相关：扩展，矛盾，建立于]
主题：
- [[相关{vocabulary.topic_map}]]
c. 验证后再写
- 标题通过声明测试（“这个{vocabulary.note}争论[标题]”）
- 描述增加了标题之外的信息（不是重述）
- 正文显示推理，不仅仅是断言
- 至少确定了一个相关的{vocabulary.note}连接
- 至少有一个{vocabulary.topic_map}链接
- 源归因存在
d. 创建文件
写入：{vocabulary.notes}/[标题].md
大源处理
对于超过2500行的源：块处理是强制性的。
上下文随着填充而降级。一个3000行源的单次通过提取将错过后期部分的洞察力，因为你到达它们时注意力已经降级。块处理确保每个部分都得到新鲜的注意力。
块策略
| 源大小 | 块数 | 块大小 | 理由 |
|---|---|---|---|
| 2500-4000行 | 3-4块 | 700-1200行 | 标准块处理 |
| 4000-6000行 | 4-5块 | 800-1200行 | 平衡注意力 |
| 6000+行 | 5+块 | 1000-1500行 | 防止上下文溢出 |
**块边界：**在自然节断裂处分割（标题，主题转换）。不要在段落中间或论证中间分割。一个块应该是一个连贯的内容单元。
处理深度适应
| 深度（来自配置） | 块行为 |
|---|---|
| 深 | 每个块新鲜上下文（如果平台支持，每个块生成子代理）。最高品质。 |
| 标准 | 按顺序在当前会话中处理块。在块之间重置定位。 |
| 快速 | 更大的块（1500-2000行）。较少，更快的通过。 |
跨块协调
当按块处理时：
- 维护跨块提取的{vocabulary.note_plural}的运行列表
- 后面的块与早期块的提取检查（不仅仅是现有的金库{vocabulary.note_plural}）
- 跨块连接被标记为{vocabulary.cmd_reflect}
- 最终提取报告涵盖所有块组合
**反模式：**处理块3并提取在块1中已经提取的内容的重复，因为你失去了追踪。维护运行列表。
丰富检测
当源内容为现有{vocabulary.note}增加价值而不是创建新的时，创建丰富任务。
何时创建丰富任务
| 信号 | 行动 |
|---|---|
| 源为现有{vocabulary.note}提供了更好的例子 | 丰富：添加例子 |
| 源提供了更深入的框架或上下文 | 丰富：加强推理 |
| 源提供了引用或证据 | 丰富：增加证据基础 |
| 源对同一声明提供了不同的角度 | 丰富：增加视角 |
| 源提供了具体的实施细节 | 丰富：添加可操作的具体内容 |
丰富任务格式
每个丰富任务指定：
- **目标：**要丰富哪个现有的{vocabulary.note}（按标题）
- **要添加什么：**源的具体内容
- **为什么：**现有{vocabulary.note}缺少的内容，这个添加了
- **源行：**源中丰富内容的位置
**丰富默认：**当你在"新{vocabulary.note}"和"丰富现有{vocabulary.note}"之间犹豫时，倾向于丰富。现有的{vocabulary.note}已经有连接，{vocabulary.topic_map}放置和集成。增加它会增加现有价值。
质量门
红旗：提取太紧（常见失败模式）
如果你发现自己做任何这些，立即停止并重新校准：
基本罪（永远不要做这些）
-
"验证现有方法"作为跳过理由
- 错误：“这只是确认了我们所做的，跳过”
- 正确：验证是有价值的。以证据框架提取为{vocabulary.note}。
- 为什么：未来的会议需要看到为什么一种方法是经过验证的，而不仅仅是它有效。
-
"已经在系统配置中捕获"作为跳过理由
- 错误：“我们已经在我们的配置中有了这个，跳过”
- 正确：提取"会话交接创建连续性而无需持久记忆"
- 为什么：配置是实现。{vocabulary.note_plural}解释为什么它有效。
-
"我们已经这样做了"作为跳过理由
- 错误：“我们使用维基链接，这是显而易见的，跳过”
- 正确：提取解释为什么它有效的推理
- 为什么：做不等于解释。需要外部化解释。
-
"显而易见"或"众所周知"作为跳过理由
- 错误：“每个人都知道结构有帮助，跳过”
- 正确：提取具体，命名的，可引用的声明
- 为什么：命名模式是可引用的。未命名的直觉不是。
-
将近重复视为跳过而不是丰富
- 错误：“与现有笔记相似，跳过”
- 正确：创建丰富任务，将源的细节添加到现有{vocabulary.note}
- 为什么：近重复几乎总是增加框架，例子或证据。
其他红旗
- 将实施想法作为"不是声明"拒绝（它们作为方法论笔记是可提取的）
- 将紧张作为"不是声明"拒绝（它们成为紧张笔记）
- 从领域相关的源中零提取（源是关于你的领域的）
- 将开放问题作为"不可测试"拒绝（方向指导未来的工作）
- 将4标准门应用于非标准声明类别（门用于离题过滤）
- 领域相关源的跳过率 > 10%（大多数领域内容应该提取到某个类别）
测试
在跳过任何内容之前，问：“未来的会议会从这个作为可检索的{vocabulary.note}中受益吗？”
如果YES -> 提取（即使"我们已经知道这个"） 如果NO -> 验证它是否真的离题或与现有内容完全相同
红旗：提取太松
- 提取没有可操作内容的模糊观察
- 创建没有表述金库连接的{vocabulary.note_plural}
- 标题是主题而不是声明（“知识管理"而不是"知识管理失败没有积极维护”）
- 正文文本是纯摘要，没有推理
校准检查（完成前必需）
**在输出结果之前停止。**按类别计算你的输出：
提取的{vocabulary.note_plural}：?
实施想法：?
紧张：?
丰富任务：?
验证：?
真正跳过的：?
总计：?
按源大小预期产量：
| 源大小 | 预期输出 | 跳过率 |
|---|---|---|
| ~100行 | 5-10输出 | 根据相关性变化 |
| ~350行 | 15-30输出 | < 10%领域相关 |
| ~500+行 | 25-50+输出 | < 10%领域相关 |
| ~1000+行 | 40-70输出 | < 5%领域相关 |
领域相关源的零提取是BUG。
如果你的总产量明显低于这些范围，你过滤过度了。
选择性适应
处理选择性根据ops/config.yaml选择性门行为：
| 选择性（配置） | 门行为 | 跳过率目标 |
|---|---|---|
| 严格 | 4标准门适用于所有声明，包括领域相关的 | 更高的跳过率是可以接受的 |
| 适度（默认） | 门仅适用于离题内容。领域相关的绕过门 | < 10%领域源 |
| 宽容 | 门几乎不适用。几乎提取一切，丰富的丰富 | < 5%总体 |
严格模式适用于成熟金库，其中噪声减少比覆盖更重要。 宽容模式适用于新金库构建初始密度。 适度是默认 — 领域内容全面提取，离题选择性。
如果产量低则强制审查
回顾你标记为"重复"或"拒绝"的候选项：
-
"重复"是否丰富了现有{vocabulary.note_plural}？
- YES -> 转换为丰富任务（默认丰富）
- NO -> 通过完全重新阅读现有{vocabulary.note}验证
-
"拒绝"是否描述了要构建的功能？
- YES -> 提取为实施想法
- NO -> 验证它是否真的不可行
-
"拒绝"是否描述了冲突或挑战？
- YES -> 提取为紧张笔记
- NO -> 验证它是否真的模糊
-
"拒绝"是否为现有方法提供了证据？
- YES -> 提取为验证声明
- NO -> 验证它是否不支持现有方法论
-
"拒绝"是否建议值得调查的问题？
- YES -> 提取为开放问题{vocabulary.note}
- NO -> 验证它是否不值得跟踪
在继续交接之前，不要进行低产量调查。
笔记设计参考
标题
标题是声明，作为链接时可以作为散文：
since [[explicit structure beats implicit convention]], the question becomes...
the insight is that [[small differences compound through repeated selection]]
because [[capture speed beats filing precision]], we separate the two...
声明测试：“这个{vocabulary.note}争论[标题]”
| 示例 | 通过？ |
|---|---|
| 质量需要积极判断 | 是：“争论质量需要积极判断” |
| 知识管理 | 否：“争论知识管理”（不完整） |
| 小差异通过选择复合 | 是：“争论小差异通过选择复合” |
| 思考工具 | 否：“争论思考工具”（不完整） |
描述
一个字段。~150个字符。必须在标题之外添加新信息 — 范围，机制或影响。
坏的（重述标题）：“质量在知识工作中很重要” 好的（增加机制+影响）：“当创造变得微不足道时，维持信噪比成为主要挑战 — 选择就是工作”
描述是逐步披露：标题说声明是什么，描述说为什么重要或如何工作。如果描述只是重述标题，它就浪费了上下文并提供没有过滤价值。
正文
展示推理。使用连接词。承认不确定性。
坏的：
质量很重要。当创造变得容易时，策展成为工作。
好的：
容易的部分是捕捉。我们书签事物，保存截图，剪辑我们永远不会再次打开的文章。困难的部分是如何处理所有这些。自动化使这变得更糟，因为生成现在是微不足道的 — 任何人都可以生产无尽的内容。所以约束从生产转移到选择。由于[[structure without processing provides no value]]，问题变成了：谁来选择？
特点：
- 对话流程（因为，但，因此）
- 显示通往结论的路径
- 在思考可能是错误的
- 考虑最强烈的反对意见
- 作为散文引用其他{vocabulary.note_plural}
部分标题
标题服务于导航，而不是装饰。当代理将从grep大纲中受益时使用。
总是使用标题：
- 紧张笔记（部分：快速测试，每个极点何时获胜，解散尝试，实际应用）
- {vocabulary.topic_map}笔记（部分：综合，核心思想，紧张，探索需要，代理笔记）
- 具有离散步骤的实施模式
- 探索多个方面的笔记（>1000字和不同的子主题）
对于：
- 单一流动论点<~1000字
- 过渡像"since [[X]]…"已经携带结构的笔记
页脚
---
源：[[源文件名]]
相关笔记：
- [[相关声明]] — 通过添加时间维度扩展这个
主题：
- [[相关{vocabulary.topic_map}]]
关系上下文解释为什么要跟随链接：
- 坏：“— 相关”
- 好：“— 通过主张显式结构与之矛盾”
- 好：“— 提供这个挑战的基础”
可组合性测试
在最终确定任何{vocabulary.note}之前，验证：
1. 独立意义 如果你从另一个上下文中链接到这个{vocabulary.note}，它是否在不读其他三个{vocabulary.note_plural}的情况下讲得通？
2. 特异性 有人能不同意这个声明吗？模糊的{vocabulary.note_plural}不能建立。
3. 清洁链接 链接到这个{vocabulary.note}会拖动无关内容吗？如果是，{vocabulary.note}涵盖得太多。
**何时跳过：**内容没有通过所有四个选择性标准（仅限离题内容） **何时分割：**一个提取中多个不同的声明 **何时锐化：**声明太模糊，标题是标签而不是声明
研究出处
当源文件包含出处元数据（source_type，research_prompt，research_server，generated）时，保留链：
- 每个创建的{vocabulary.note}的源页脚链接到源文件
- 源文件的YAML包含研究提示
- 链：研究查询 -> 收件箱文件 -> /{vocabulary.reduce} -> {vocabulary.notes}
如果源有source_type在前言中，这是研究生成的内容 — 处理时需要额外注意归因。
要保留的出处字段：
| 字段 | 目的 |
|---|---|
| source_type | 这个内容是如何生成的 |
| research_prompt | 产生这个内容的查询或指令 |
| research_server | 使用了哪个研究工具 |
| generated | 研究是什么时候产生的 |
研究提示是最关键的字段 — 它捕获了塑造返回内容的知识背景。知道"我搜索X因为我正在探索Y"是知识图谱的一部分。
示例：什么好的提取看起来像
示例 1：300行领域相关源
**源：**300行研究文件直接相关于{vocabulary.domain}
扫描发现：~45个项目跨部分
提取结果：
- 12个核心{vocabulary.note_plural}
- 6个实施想法 -> 方法论笔记
- 4个紧张 -> 紧张笔记
- 5个丰富任务 -> 更新现有{vocabulary.note_plural}
- 3个验证 -> {vocabulary.note_plural}
- 3个跳过（太模糊，无法采取行动）
总计：30个输出，3个跳过（~9%跳过率）
示例 2：100行一般文章
**源：**100行文章部分与{vocabulary.domain}相关
提取结果：
- 4个核心{vocabulary.note_plural}
- 1个丰富任务
- 2个跳过（离题）
- 3个跳过（太模糊）
总计：5个输出，5个跳过（50%跳过率 — 对于一般源是可以接受的）
对比：错误行为
- 45个候选项 -> 0输出（所有"作为重复或不是声明拒绝"）
- 将实施想法作为"不是声明"并跳过
- 将紧张作为"不是声明"并跳过
- 将近重复作为跳过而不是丰富任务
- 领域相关源的跳过率 > 10%
关键
永远不要自动提取。总是展示发现并等待用户批准。
**如果有疑问，提取。**对于领域相关的源，倾向于捕获。实施想法，紧张，验证，开放问题和近重复都有价值 — 它们成为不同的输出类型，而不是拒绝。
**原则：**目标是捕获与{vocabulary.domain}相关的一切。对于领域相关的源，这是大多数内容。选择性门存在于OFF-TOPIC过滤，而不是拒绝在任务内容中碰巧有不同的形式。
记住：
- 实施想法不是"不是声明" — 它们是路线图
- 紧张不是"不是声明" — 它们是智慧
- 丰富不是"重复" — 它们增加细节
- 验证不是"已经知道" — 它们是证据
- 开放问题不是"不可测试" — 它们是指导
对于领域相关的源：跳过率 < 10%。零提取=BUG。
交接模式（–handoff标志）
当用--handoff调用时，这个技能处理协调执行的队列管理。这包括为每个声明创建任务文件和更新队列。
**检测：**检查$ARGUMENTS是否包含--handoff。
每个声明的任务文件（手交接模式必需）
提取后，对于每个声明，创建一个任务文件在ops/queue/：
文件名：{source}-NNN.md其中：
- {source}是源基本名（从提取任务中）
- NNN是声明编号，从提取任务文件中的
next_claim_start开始
**示例：**如果article-name.md任务有next_claim_start: 010，声明是：
article-name-010.md,article-name-011.md等。
**为什么唯一名称：**声明文件名必须在整个金库中唯一。声明编号是全局的，永远不会在批次中重用。模式{source}-NNN.md确保每个声明文件即使在归档后也能被唯一识别。
结构：
---
claim: "[声明作为句子]"
classification: closed | open
source_task: [source-basename]
semantic_neighbor: "[相关笔记标题]" | null
---
# Claim NNN: [声明标题]
Source: [[source filename]] (lines NNN-NNN)
## Reduce Notes
Extracted from [source_task]. This is a [CLOSED/OPEN] claim.
Rationale: [为什么提取这个声明，它贡献了什么]
Semantic neighbor: [如果找到，解释为什么不同而不是重复]
---
## Create
(to be filled by create phase)
## {vocabulary.cmd_reflect}
(to be filled by {vocabulary.cmd_reflect} phase)
## {vocabulary.cmd_reweave}
(to be filled by {vocabulary.cmd_reweave} phase)
## {vocabulary.cmd_verify}
(to be filled by {vocabulary.cmd_verify} phase)
丰富任务文件（手交接模式必需）
对于每个丰富检测，创建一个任务文件在ops/queue/：
文件名：{source}-EEE.md其中：
- {source}是源基本名（与声明相同）
- EEE是丰富编号，继续从声明留下的地方开始
**示例：**如果声明是010-015，丰富从016开始。
**为什么唯一名称：**丰富共享编号系统与声明。两者都使用全局next_claim_start计数器。这确保每个任务文件在整个金库中都能被唯一识别。
结构：
---
type: enrichment
target_note: "[[existing note title]]"
source_task: [source-basename]
addition: "what to add from source"
source_lines: "NNN-NNN"
---
# Enrichment EEE: [[existing note title]]
Source: [[source filename]] (lines NNN-NNN)
## Reduce Notes
Enrichment for [[existing note title]]. Source adds [what it adds].
Rationale: [为什么这个丰富而不是重复]
---
## Enrich
(to be filled by enrich phase)
## {vocabulary.cmd_reflect}
(to be filled by {vocabulary.cmd_reflect} phase)
## {vocabulary.cmd_reweave}
(to be filled by {vocabulary.cmd_reweave} phase)
## {vocabulary.cmd_verify}
(to be filled by {vocabulary.cmd_verify} phase)
队列更新（手交接模式必需）
创建任务文件后，更新ops/queue/queue.json：
- 将提取任务标记为
"status": "done"，并完成时间戳 - 对于每个声明，添加一个队列条目：
{
"id": "claim-NNN",
"type": "claim",
"status": "pending",
"target": "[claim title]",
"classification": "closed|open",
"batch": "[source-basename]",
"file": "[source-basename]-NNN.md",
"created": "[ISO timestamp]",
"current_phase": "create",
"completed_phases": []
}
- 对于每个丰富，添加一个队列条目：
{
"id": "enrich-EEE",
"type": "enrichment",
"status": "pending",
"target": "[existing note title]",
"source_detail": "[what to add]",
"batch": "[source-basename]",
"file": "[source-basename]-EEE.md",
"created": "[ISO timestamp]",
"current_phase": "enrich",
"completed_phases": []
}
关键队列规则：
- 每个声明一个入口（不是一个阶段一个） — 阶段进展通过
current_phase和completed_phases跟踪 type是"claim"或"enrichment"— 这些是任务的单个队列条目- 每个任务必须有
"file"指向其唯一命名的任务文件 - 每个任务必须有
"batch"标识它属于哪个源批次 - 任务ID使用
claim-NNN或enrich-EEE格式，使用全局声明编号 - 声明编号是全局的，永远不会在批次中重用
current_phase从"create"开始声明，"enrich"开始丰富- 协调器通过配置的phase_order序列推进阶段
声明编号
- 从提取任务文件中的
next_claim_start值开始（由/seed计算） - /seed通过检查队列和存档计算这个，找到最高的现有声明编号
- 示例：如果金库中最高的声明是009，next_claim_start将是010
- 声明编号是GLOBAL且永远不会在批次中重用
- 丰富继续编号序列在声明之后
交接输出格式
创建文件和更新队列后，输出：
=== RALPH HANDOFF: reduce ===
Target: [source file]
Work Done:
- Extracted N claims from [source]
- Created claim files: {source}-NNN.md through {source}-NNN.md
- Created M enrichment files: {source}-EEE.md through {source}-EEE.md (if any)
- Duplicates skipped: [list or "none"]
- Semantic neighbors flagged for cross-linking: [list or "none"]
Files Modified:
- ops/queue/{source}-NNN.md (claim files)
- ops/queue/{source}-EEE.md (enrichment files, if any)
- ops/queue/queue.json (N claim tasks + M enrichment tasks, 1 entry each)
Learnings:
- [Friction]: [description] | NONE
- [Surprise]: [description] | NONE
- [Methodology]: [description] | NONE
- [Process gap]: [description] | NONE
Queue Updates:
- Mark: {source} done
- Create: claim-NNN entries (1 per claim, current_phase: "create")
- Create: enrich-EEE entries (1 per enrichment, current_phase: "enrich", if any)
=== END HANDOFF ===
**关键：**交接模式在标准减少工作流程之上添加队列管理。首先完成完整的提取工作流程，然后创建任务文件，更新队列，并输出交接。
队列更新（交互执行）
当交互运行（不是通过协调器）时，你必须执行队列更新。协调器解析交接块并自动处理这个，但交互会话不。
完成提取后，更新队列：
# Get timestamp
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
# Mark extract task done (replace TASK_ID with actual task ID)
jq '(.tasks[] | select(.id=="TASK_ID")).status = "done" | (.tasks[] | select(.id=="TASK_ID")).completed = "'"$TIMESTAMP"'"' ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json
交接块的"队列更新"部分不仅仅是输出 — 它是你自己的待办事项清单，当你交互运行时。
技能选择路由
处理内容时，路由到正确的技能：
| 任务类型 | 所需技能 | 为什么 |
|---|---|---|
| 新内容处理 | /{vocabulary.reduce} | 提取需要质量门 |
| 刚刚创建的{vocabulary.note} | /{vocabulary.cmd_reflect} | 新{vocabulary.note_plural}需要连接 |
| 连接后 | /{vocabulary.cmd_reweave} | 旧{vocabulary.note_plural}需要更新 |
| 质量检查 | /{vocabulary.cmd_verify} | 结合验证门 |
| 系统健康 | /health | 系统诊断 |
管道链
提取完成后，根据ops/config.yaml管道链模式输出下一步：
-
manual: 输出"Next: {vocabulary.cmd_reflect} [created notes]" — 用户决定何时继续
-
suggested: 输出下一步并添加每个创建的{vocabulary.note}到
ops/queue/queue.json与current_phase: "create"和completed_phases: [] -
automatic: 创建队列条目并通过协调继续处理
链输出使用派生宣言中的领域本地命令名称。