@optima-chat/optima-agent 0.9.12 → 0.9.14

package/.claude/skills/ingesting-sources/SKILL.md

@@ -1,94 +1,94 @@
----
-name: ingesting-sources
-description: "将新素材收录到知识库。当用户说'收录这篇文章'、'把这个加到知识库'时使用。"
----
-
-# Ingesting Sources
-
-把原始材料做第一次落库，进入持续维护的 wiki 结构。产物不只是摘要，而是一页来源页，以及一份"还有哪些页面需要随之更新"的映射。
-
-## 启动 SOP
-
-1. `ls ~/kb/REGISTRY.md`
-   - 不存在 → 告诉用户"还没有知识库，需要先创建一个"，引导使用 initializing-kb
-2. 读 `~/kb/REGISTRY.md` — 获取所有 active 的 KB 列表
-3. 确定目标 KB：
-   - 用户明确指定了 KB slug 或主题 → 直接用
-   - 只有一个 active KB → 用它
-   - 多个 active → 根据用户问题匹配 `主题` + `说明` 字段；无法判断时列出让用户选
-4. 读 `~/kb/<slug>/AGENTS.md` 了解该 KB 的契约
-
-## 获取素材到 raw/
-
-用户可能通过以下方式提供素材：
-
-- 本地文件路径 → `cp <path> ~/kb/<slug>/raw/<命名后的文件名>`
-- URL → 下载到 `~/kb/<slug>/raw/`（用 WebFetch 或 curl）
-- 直接贴图/附件 → 保存到 `~/kb/<slug>/raw/`
-
-文件命名规则：`YYYY-MM-DD-short-description.{ext}`，保留原始扩展名。
-
-## 按类型读取素材
-
-| 类型 | 扩展名 | 读取方式 |
-|------|--------|----------|
-| 文本 | `.md` `.txt` | 直接读取 |
-| PDF | `.pdf` | 直接读取（Claude 原生支持） |
-| 图片 | `.png` `.jpg` `.webp` `.gif` | 用 Read 工具查看图片，生成文本描述 |
-| 音频 | `.mp3` `.wav` `.m4a` | 加载 gen skill，调 ASR 转文字 |
-| 视频 | `.mp4` `.mov` `.webm` | 加载 ffmpeg skill 提取音频 → ASR 转文字；提取关键帧 → 查看描述 |
-
-如果素材类型不在上表中，尝试直接读取；读不了就告诉用户不支持该格式。
-
-## Ingest 流程
-
-1. 确认素材已在 `~/kb/<slug>/raw/` 中（如不在，先执行上方"获取素材"步骤）
-2. 按上方类型表读取素材内容
-3. 提取主要论点、证据、实体和开放问题
-4. 在 `~/kb/<slug>/wiki/sources/` 中创建或更新对应页面
-4. 列出哪些 entity、overview 和 analysis 页面受到影响
-5. 如果任务范围包含来源页之外的更新，交给 updating-related-pages 处理，或执行一次有边界的相关页更新
-6. 如果这个来源是首次进入 wiki，更新 `~/kb/<slug>/index.md` 和 `~/kb/<slug>/log.md`
-7. 追加 `~/kb/PROGRESS.md`
-8. `cd ~/kb && git add -A && git commit -m "[<slug>] ingest: <来源名>"`
-
-## 来源页内容
-
-来源页应至少包含：
-
-- 来源标题
-- 来源类型（文本 / 图片 / 音频 / 视频 / PDF）
-- 原始文件路径（`raw/` 下的相对路径）
-- 简短摘要
-- 关键论点
-- 关键证据或观察
-- 相关实体、主题或概念
-- 对既有理解产生的冲突、修正或压力
-- 指向受影响页面的链接
-
-对于多媒体来源，描述就是 source page 的核心内容。如果描述不够准确，直接编辑 source page 或重新 ingest 即可——source page 是可变的，raw/ 里的原始文件才是不可变的。
-
-## 抽取规则
-
-- 将来源明确表达的内容与综合推断区分开
-- 不要把大段原文直接复制进 wiki
-- 优先写成简洁、可链接、之后可更新的陈述
-- 当来源含混或不完整时，显式记录不确定性
-- 遇到冲突要记录，不要静默抹平
-
-## 何时创建相关页面
-
-出现下列情况时应建议新建页面：
-
-- 某个人、组织、产品或概念很重要，但还没有稳定页面
-- 来源引入了一个新的 recurring topic
-- 来源实质性改变了某个既有 overview
-- 形成的综合结果已经明显值得进入 `wiki/analyses/`
-
-## 最小交付标准
-
-一次成功的 ingest 至少应留下：
-
-- 一页可用的 `wiki/sources/` 页面
-- 一份清晰的受影响页面列表
-- 足够明确的结构，使下一步 update 很自然
+---
+name: ingesting-sources
+description: "将新素材收录到知识库。当用户说'收录这篇文章'、'把这个加到知识库'时使用。"
+---
+
+# Ingesting Sources
+
+把原始材料做第一次落库，进入持续维护的 wiki 结构。产物不只是摘要，而是一页来源页，以及一份"还有哪些页面需要随之更新"的映射。
+
+## 启动 SOP
+
+1. `ls ~/kb/REGISTRY.md`
+   - 不存在 → 告诉用户"还没有知识库，需要先创建一个"，引导使用 initializing-kb
+2. 读 `~/kb/REGISTRY.md` — 获取所有 active 的 KB 列表
+3. 确定目标 KB：
+   - 用户明确指定了 KB slug 或主题 → 直接用
+   - 只有一个 active KB → 用它
+   - 多个 active → 根据用户问题匹配 `主题` + `说明` 字段；无法判断时列出让用户选
+4. 读 `~/kb/<slug>/AGENTS.md` 了解该 KB 的契约
+
+## 获取素材到 raw/
+
+用户可能通过以下方式提供素材：
+
+- 本地文件路径 → `cp <path> ~/kb/<slug>/raw/<命名后的文件名>`
+- URL → 下载到 `~/kb/<slug>/raw/`（用 WebFetch 或 curl）
+- 直接贴图/附件 → 保存到 `~/kb/<slug>/raw/`
+
+文件命名规则：`YYYY-MM-DD-short-description.{ext}`，保留原始扩展名。
+
+## 按类型读取素材
+
+| 类型 | 扩展名 | 读取方式 |
+|------|--------|----------|
+| 文本 | `.md` `.txt` | 直接读取 |
+| PDF | `.pdf` | 直接读取（Claude 原生支持） |
+| 图片 | `.png` `.jpg` `.webp` `.gif` | 用 Read 工具查看图片，生成文本描述 |
+| 音频 | `.mp3` `.wav` `.m4a` | 加载 gen skill，调 ASR 转文字 |
+| 视频 | `.mp4` `.mov` `.webm` | 加载 ffmpeg skill 提取音频 → ASR 转文字；提取关键帧 → 查看描述 |
+
+如果素材类型不在上表中，尝试直接读取；读不了就告诉用户不支持该格式。
+
+## Ingest 流程
+
+1. 确认素材已在 `~/kb/<slug>/raw/` 中（如不在，先执行上方"获取素材"步骤）
+2. 按上方类型表读取素材内容
+3. 提取主要论点、证据、实体和开放问题
+4. 在 `~/kb/<slug>/wiki/sources/` 中创建或更新对应页面
+4. 列出哪些 entity、overview 和 analysis 页面受到影响
+5. 如果任务范围包含来源页之外的更新，交给 updating-related-pages 处理，或执行一次有边界的相关页更新
+6. 如果这个来源是首次进入 wiki，更新 `~/kb/<slug>/index.md` 和 `~/kb/<slug>/log.md`
+7. 追加 `~/kb/PROGRESS.md`
+8. `cd ~/kb && git add -A && git commit -m "[<slug>] ingest: <来源名>"`
+
+## 来源页内容
+
+来源页应至少包含：
+
+- 来源标题
+- 来源类型（文本 / 图片 / 音频 / 视频 / PDF）
+- 原始文件路径（`raw/` 下的相对路径）
+- 简短摘要
+- 关键论点
+- 关键证据或观察
+- 相关实体、主题或概念
+- 对既有理解产生的冲突、修正或压力
+- 指向受影响页面的链接
+
+对于多媒体来源，描述就是 source page 的核心内容。如果描述不够准确，直接编辑 source page 或重新 ingest 即可——source page 是可变的，raw/ 里的原始文件才是不可变的。
+
+## 抽取规则
+
+- 将来源明确表达的内容与综合推断区分开
+- 不要把大段原文直接复制进 wiki
+- 优先写成简洁、可链接、之后可更新的陈述
+- 当来源含混或不完整时，显式记录不确定性
+- 遇到冲突要记录，不要静默抹平
+
+## 何时创建相关页面
+
+出现下列情况时应建议新建页面：
+
+- 某个人、组织、产品或概念很重要，但还没有稳定页面
+- 来源引入了一个新的 recurring topic
+- 来源实质性改变了某个既有 overview
+- 形成的综合结果已经明显值得进入 `wiki/analyses/`
+
+## 最小交付标准
+
+一次成功的 ingest 至少应留下：
+
+- 一页可用的 `wiki/sources/` 页面
+- 一份清晰的受影响页面列表
+- 足够明确的结构，使下一步 update 很自然

package/.claude/skills/initializing-kb/SKILL.md

@@ -1,117 +1,117 @@
----
-name: initializing-kb
-description: "创建新知识库或初始化 ~/kb/ 工作空间。当用户说'建个知识库'、'我想整理XX的知识'时使用。"
----
-
-# Initializing KB
-
-创建一个基于 Markdown 的知识库。主要产物是 `~/kb/<slug>/` 目录和其中的 `AGENTS.md`。
-
-## 核心：~/kb/ 工作目录
-
-所有知识库都在 `~/kb/` 下，每个知识库一个子目录。
-
-```text
-~/kb/
-├── REGISTRY.md
-├── PROGRESS.md
-├── <slug>/
-│   ├── AGENTS.md
-│   ├── index.md
-│   ├── log.md
-│   ├── raw/
-│   └── wiki/
-│       ├── overview/
-│       ├── entities/
-│       ├── sources/
-│       └── analyses/
-└── .git/
-```
-
-## 启动 SOP
-
-1. `ls ~/kb/REGISTRY.md`
-   - 不存在 → 初始化根目录（见下方"首次初始化"）
-   - 存在 → 读 `REGISTRY.md`，了解已有的知识库
-2. 询问用户要创建什么主题的知识库
-
-## 首次初始化
-
-如果 `~/kb/` 不存在：
-
-1. `mkdir -p ~/kb`
-2. 创建 `~/kb/REGISTRY.md`：
-
-   ```markdown
-   # 知识库注册表
-
-   | slug | 主题 | 状态 | 创建日期 | 说明 |
-   |------|------|------|----------|------|
-   ```
-
-3. 创建 `~/kb/PROGRESS.md`：
-
-   ```markdown
-   # 知识库工作日志
-   ```
-
-4. `cd ~/kb && git init && git add -A && git commit -m "init kb workspace"`
-
-## 创建知识库
-
-1. 询问用户知识库主题
-2. 从主题生成 kebab-case slug 建议（不带 `-kb` 后缀）
-3. 校验 slug：
-   - 匹配 `^[a-z0-9][a-z0-9-]{0,29}$`
-   - 不与 `REGISTRY.md` 已有 slug 重复
-   - 让用户确认或修改
-4. `mkdir -p ~/kb/<slug>`
-5. 检查当前素材（如果用户指定了已有目录或文件）
-6. 确定所需的最小页面类型集合
-7. 创建 `AGENTS.md`（见下方"AGENTS.md 内容"）
-8. 创建 `index.md`、`log.md`、`raw/`、`wiki/overview/`、`wiki/entities/`、`wiki/sources/`、`wiki/analyses/`
-9. 追加 `~/kb/REGISTRY.md` 新行
-10. `cd ~/kb && git add -A && git commit -m "[<slug>] init: <主题>"`
-
-## AGENTS.md 内容
-
-至少应包含：
-
-- 仓库目标
-- `raw/` 的 source-of-truth 规则
-- 页面类型及其职责
-- ingest 工作流
-- query 工作流
-- lint 工作流
-- 编辑规则
-- 命名约定
-- 何时应新建页面，而不是继续扩写旧页
-- agent 修改后的输出要求
-
-## 页面模型
-
-默认页面职责：
-
-- `wiki/sources/`：每个来源一页
-- `wiki/entities/`：每个跨多个来源反复出现的稳定实体或概念一页
-- `wiki/overview/`：每个主题或认知领域一页
-- `wiki/analyses/`：长期有效的答案、比较、综合或决策记录
-
-避免混淆这些角色。
-
-## 命名规则
-
-- 来源页：`YYYY-MM-DD-short-source-name.md`
-- 分析页：`YYYY-MM-DD-short-analysis-name.md`
-- 实体页：`kebab-case-entity-name.md`
-- 综述页：`kebab-case-topic-name.md`
-
-## 好的结果
-
-一个好的 schema 应该让这些决策变得容易：
-
-- 新来源应该落到哪里
-- 一个概念什么时候值得拥有独立实体页
-- 一个高价值答案应该写回哪里
-- 冲突信息应如何呈现
-- 之后如何再次找到这些页面
+---
+name: initializing-kb
+description: "创建新知识库或初始化 ~/kb/ 工作空间。当用户说'建个知识库'、'我想整理XX的知识'时使用。"
+---
+
+# Initializing KB
+
+创建一个基于 Markdown 的知识库。主要产物是 `~/kb/<slug>/` 目录和其中的 `AGENTS.md`。
+
+## 核心：~/kb/ 工作目录
+
+所有知识库都在 `~/kb/` 下，每个知识库一个子目录。
+
+```text
+~/kb/
+├── REGISTRY.md
+├── PROGRESS.md
+├── <slug>/
+│   ├── AGENTS.md
+│   ├── index.md
+│   ├── log.md
+│   ├── raw/
+│   └── wiki/
+│       ├── overview/
+│       ├── entities/
+│       ├── sources/
+│       └── analyses/
+└── .git/
+```
+
+## 启动 SOP
+
+1. `ls ~/kb/REGISTRY.md`
+   - 不存在 → 初始化根目录（见下方"首次初始化"）
+   - 存在 → 读 `REGISTRY.md`，了解已有的知识库
+2. 询问用户要创建什么主题的知识库
+
+## 首次初始化
+
+如果 `~/kb/` 不存在：
+
+1. `mkdir -p ~/kb`
+2. 创建 `~/kb/REGISTRY.md`：
+
+   ```markdown
+   # 知识库注册表
+
+   | slug | 主题 | 状态 | 创建日期 | 说明 |
+   |------|------|------|----------|------|
+   ```
+
+3. 创建 `~/kb/PROGRESS.md`：
+
+   ```markdown
+   # 知识库工作日志
+   ```
+
+4. `cd ~/kb && git init && git add -A && git commit -m "init kb workspace"`
+
+## 创建知识库
+
+1. 询问用户知识库主题
+2. 从主题生成 kebab-case slug 建议（不带 `-kb` 后缀）
+3. 校验 slug：
+   - 匹配 `^[a-z0-9][a-z0-9-]{0,29}$`
+   - 不与 `REGISTRY.md` 已有 slug 重复
+   - 让用户确认或修改
+4. `mkdir -p ~/kb/<slug>`
+5. 检查当前素材（如果用户指定了已有目录或文件）
+6. 确定所需的最小页面类型集合
+7. 创建 `AGENTS.md`（见下方"AGENTS.md 内容"）
+8. 创建 `index.md`、`log.md`、`raw/`、`wiki/overview/`、`wiki/entities/`、`wiki/sources/`、`wiki/analyses/`
+9. 追加 `~/kb/REGISTRY.md` 新行
+10. `cd ~/kb && git add -A && git commit -m "[<slug>] init: <主题>"`
+
+## AGENTS.md 内容
+
+至少应包含：
+
+- 仓库目标
+- `raw/` 的 source-of-truth 规则
+- 页面类型及其职责
+- ingest 工作流
+- query 工作流
+- lint 工作流
+- 编辑规则
+- 命名约定
+- 何时应新建页面，而不是继续扩写旧页
+- agent 修改后的输出要求
+
+## 页面模型
+
+默认页面职责：
+
+- `wiki/sources/`：每个来源一页
+- `wiki/entities/`：每个跨多个来源反复出现的稳定实体或概念一页
+- `wiki/overview/`：每个主题或认知领域一页
+- `wiki/analyses/`：长期有效的答案、比较、综合或决策记录
+
+避免混淆这些角色。
+
+## 命名规则
+
+- 来源页：`YYYY-MM-DD-short-source-name.md`
+- 分析页：`YYYY-MM-DD-short-analysis-name.md`
+- 实体页：`kebab-case-entity-name.md`
+- 综述页：`kebab-case-topic-name.md`
+
+## 好的结果
+
+一个好的 schema 应该让这些决策变得容易：
+
+- 新来源应该落到哪里
+- 一个概念什么时候值得拥有独立实体页
+- 一个高价值答案应该写回哪里
+- 冲突信息应如何呈现
+- 之后如何再次找到这些页面