@optima-chat/optima-agent 0.8.99 → 0.8.100

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

@@ -1,42 +1,37 @@
 ---
 name: ingesting-sources
-description: Use when new source material needs to be incorporated into a maintained knowledge base.
+description: "将新素材收录到知识库。当用户说'收录这篇文章'、'把这个加到知识库'时使用。"
 ---
 
 # Ingesting Sources
 
-这个 skill 负责把原始材料做第一次落库，进入持续维护的 wiki 结构。它的产物不只是摘要，而是一页来源页，以及一份清晰的“还有哪些页面需要随之更新”的映射。
+把原始材料做第一次落库，进入持续维护的 wiki 结构。产物不只是摘要，而是一页来源页，以及一份"还有哪些页面需要随之更新"的映射。
 
-## 职责
+## 启动 SOP
 
-- 从 `raw/` 读取新来源
-- 在 `wiki/sources/` 中创建或更新对应页面
-- 抽取关键事实、实体和主题
-- 标出 wiki 其他位置中受影响的页面
+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 的契约
 
-## 不负责
+## Ingest 流程
 
-- 全量维护性清理
-- 泛化问答
-
-## 工作规则
-
-来源页不仅要说明来源说了什么，还要说明它会如何影响 wiki 的其他部分。
-
-## 流程
-
-使用这个 skill 时，按以下顺序进行：
-
-1. 在 `raw/` 中定位来源文件
+1. 在 `~/kb/<slug>/raw/` 中定位来源文件
 2. 仔细阅读来源，提取主要论点、证据、实体和开放问题
-3. 在 `wiki/sources/` 中创建或更新对应页面
+3. 在 `~/kb/<slug>/wiki/sources/` 中创建或更新对应页面
 4. 列出哪些 entity、overview 和 analysis 页面受到影响
-5. 如果任务范围包含来源页之外的更新，就交给 `updating-related-pages` 的行为处理，或执行一次有边界的相关页更新
-6. 如果这个来源是首次进入 wiki，则更新 `index.md` 和 `log.md`
+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: <来源名>"`
 
 ## 来源页内容
 
-除非仓库已经有更强的既有格式，否则来源页应至少包含：
+来源页应至少包含：
 
 - 来源标题
 - 简短摘要
@@ -48,9 +43,7 @@ description: Use when new source material needs to be incorporated into a mainta
 
 ## 抽取规则
 
-在 ingest 过程中：
-
-- 将来源明确表达的内容与你自己的综合推断区分开
+- 将来源明确表达的内容与综合推断区分开
 - 不要把大段原文直接复制进 wiki
 - 优先写成简洁、可链接、之后可更新的陈述
 - 当来源含混或不完整时，显式记录不确定性
@@ -58,7 +51,7 @@ description: Use when new source material needs to be incorporated into a mainta
 
 ## 何时创建相关页面
 
-在 ingest 过程中，出现下列情况时应建议新建页面：
+出现下列情况时应建议新建页面：
 
 - 某个人、组织、产品或概念很重要，但还没有稳定页面
 - 来源引入了一个新的 recurring topic
@@ -72,5 +65,3 @@ description: Use when new source material needs to be incorporated into a mainta
 - 一页可用的 `wiki/sources/` 页面
 - 一份清晰的受影响页面列表
 - 足够明确的结构，使下一步 update 很自然
-
-如果 ingest 最终只留下了一段模糊摘要，而没有连到 wiki 的其他部分，那它就是不完整的。

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

@@ -1,80 +1,79 @@
 ---
 name: initializing-kb
-description: Use when creating a new markdown-based knowledge base, or when an existing repository needs to be turned into a structured knowledge base with clear page types and maintenance rules.
+description: "创建新知识库或初始化 ~/kb/ 工作空间。当用户说'建个知识库'、'我想整理XX的知识'时使用。"
 ---
 
 # Initializing KB
 
-这个 skill 用来定义一个基于 Markdown 的知识库的运行契约。它的主要产物是一份可用的 `AGENTS.md`，以及少量与之匹配的模板调整，使仓库真正可维护。
+创建一个基于 Markdown 的知识库。主要产物是 `~/kb/<slug>/` 目录和其中的 `AGENTS.md`。
 
-## 职责
+## 核心：~/kb/ 工作目录
 
-- 定义页面类型
-- 定义命名约定
-- 定义 ingest、query 和 lint 工作流
-- 创建或更新 `AGENTS.md`
+所有知识库都在 `~/kb/` 下，每个知识库一个子目录。
 
-## 不负责
-
-- ingest 具体来源
-- 大范围 wiki 维护
+```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. 询问用户要创建什么主题的知识库
 
-## 流程
+## 首次初始化
 
-使用这个 skill 时，按以下顺序进行：
+如果 `~/kb/` 不存在：
 
-1. 检查当前仓库布局
-2. 确认 `raw/`、`wiki/`、`index.md`、`log.md` 和 `AGENTS.md` 是否已经存在
-3. 判断现有结构是可小修复用，还是需要更强约束的重整
-4. 定义这个仓库所需的最小页面类型集合
-5. 编写或更新 `AGENTS.md`
-6. 做少量与规则匹配的模板调整，保证仓库布局和规则一致
+1. `mkdir -p ~/kb`
+2. 创建 `~/kb/REGISTRY.md`：
 
-除非知识库规模和内容已经明确需要，否则不要发明庞大的分类体系。
+   ```markdown
+   # 知识库注册表
 
-## 默认结构
+   | slug | 主题 | 状态 | 创建日期 | 说明 |
+   |------|------|------|----------|------|
+   ```
 
-除非仓库已经有更成熟的既有结构，否则优先采用这个默认形态：
+3. 创建 `~/kb/PROGRESS.md`：
 
-```text
-raw/
-wiki/
-  overview/
-  entities/
-  sources/
-  analyses/
-index.md
-log.md
-AGENTS.md
-```
+   ```markdown
+   # 知识库工作日志
+   ```
 
-## 页面模型
+4. `cd ~/kb && git init && git add -A && git commit -m "init kb workspace"`
 
-默认页面职责如下：
+## 创建知识库
 
-- `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`
+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: <主题>"`
 
-统一优先使用 ISO 日期和 kebab-case。
-
-## `AGENTS.md` 必须定义什么
+## AGENTS.md 内容
 
 至少应包含：
 
@@ -89,6 +88,24 @@ AGENTS.md
 - 何时应新建页面，而不是继续扩写旧页
 - 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 应该让这些决策变得容易：
@@ -98,5 +115,3 @@ AGENTS.md
 - 一个高价值答案应该写回哪里
 - 冲突信息应如何呈现
 - 之后如何再次找到这些页面
-
-如果更新完 `AGENTS.md` 之后这些决策仍然模糊，说明 schema 还没有完成。

package/.claude/skills/kol-outreach/SKILL.md

@@ -1,450 +1,232 @@
 ---
 name: kol-outreach
-description: "KOL 建联全自动化：从 TikTok 发现潜在 KOL、提取 bio email、发送个性化 outreach、自动处理 KOL 回信并维护本地状态。当用户说'帮我找 KOL'、'{产品} KOL 建联'、'KOL 进展如何'，或消息中出现 [KOL_INBOUND:{campaignId}] / [KOL_INBOUND] 时，使用此 skill。"
+description: |
+  KOL outreach automation: discover TikTok KOLs, extract emails, send personalized outreach, handle replies, negotiate deals.
+  Trigger: user says '帮我找 KOL', 'KOL 建联', 'KOL 进展', or message contains [KOL_INBOUND:{campaignId}] / [KOL_INBOUND].
 ---
 
 # KOL 建联
 
-## 概述
+端到端 TikTok KOL 建联自动化：发现、触达、谈判、成交。
 
-本 skill 用于在 TikTok 上完成 KOL 建联的完整操作流程：发现、触达、回信处理、进度维护。
+## 核心：~/kol-outreach/ 工作目录
 
-- 所有业务状态都保存在 `~/kol-outreach/`
-- 运行时默认零打扰，优先按已固化配置执行
-- 本 skill 只负责操作，不解释系统实现
+所有状态都在 `~/kol-outreach/`（单个 git repo）。每次会话只做一件事。
 
-## 工作规则
+**每次会话启动**：
+
+1. 检查 `~/kol-outreach/BRAND.md` 是否存在且已完整填写 — 不存在或未完成则走初始化
+2. 读 `CAMPAIGNS.md` — 了解所有 campaign 状态
+3. `git -C ~/kol-outreach log --oneline -5` — 最近变更
+4. 根据用户意图 + 文件状态决定本次操作
+
+| 文件 | 层级 | 用途 |
+|------|------|------|
+| `BRAND.md` | merchant | 品牌素材、兜底话术、升级关键词 |
+| `MERCHANT_LIMITS.md` | merchant | 日发信配额（跨 campaign 共享） |
+| `CAMPAIGNS.md` | merchant | campaign 索引 |
+| `PROGRESS.md` | merchant | 跨 campaign 关键事件 |
+| `campaigns/{id}/CONFIG.md` | campaign | 商品、预算、条款、运行参数 |
+| `campaigns/{id}/KOLS.md` | campaign | KOL 状态索引（status: `pending_outreach` / `awaiting_reply` / `in_progress` / `deal_reached` / `needs_merchant_followup` / `rejected` / `expired` / `send_error` / `no_contact`） |
+| `campaigns/{id}/TEMPLATES.md` | campaign | 邮件模板（LLM 只填变量） |
+| `campaigns/{id}/PROGRESS.md` | campaign | 本 campaign 事件日志 |
+| `campaigns/{id}/CONVERSATIONS/{username}.md` | campaign | 每个 KOL 的完整对话 |
 
-- outbound 只用 `scout outreach send`
-- onboarding 时只用 `scout outreach brand-slug check|claim`
-- 所有业务状态只从 `~/kol-outreach/` 读取和写回
-- 单会话单任务：每次 session 只做一种动作
-- 每次关键状态变更后都要 `git add` + `git commit`
-- 所有对外邮件都必须走模板渲染；LLM 只能产出结构化变量或结构化决策
-
-## 工作目录文件
-
-优先关注这些文件：
-
-- merchant 级
-  - `~/kol-outreach/BRAND.md`
-  - `~/kol-outreach/MERCHANT_LIMITS.md`
-  - `~/kol-outreach/CAMPAIGNS.md`
-  - `~/kol-outreach/PROGRESS.md`
-- campaign 级
-  - `~/kol-outreach/campaigns/{campaignId}/CONFIG.md`
-  - `~/kol-outreach/campaigns/{campaignId}/KOLS.md`
-  - `~/kol-outreach/campaigns/{campaignId}/TEMPLATES.md`
-  - `~/kol-outreach/campaigns/{campaignId}/PROGRESS.md`
-  - `~/kol-outreach/campaigns/{campaignId}/CONVERSATIONS/{username}.md`
-
-## Session 分流
-
-每次 session 开始时，按这个顺序判断要走哪条流程：
-
-1. 如果用户消息包含 `[KOL_INBOUND:{campaignId}]` 或 `[KOL_INBOUND]`，走「流程 D：KOL 回信处理」
-2. 否则，检查 `~/kol-outreach/BRAND.md` 是否存在
-   - 不存在：先走「流程 A：Merchant onboarding」，再走「流程 B：Campaign onboarding」
-3. 如果 merchant 已存在，则按用户意图分流
-   - 用户要为新产品建联：走「流程 B：Campaign onboarding」
-   - 用户要开始建联或发送 outreach：走「流程 C：发现 KOL + 首发 Outreach」
-   - 用户要查看状态或进展：走「流程 E：查询进度」
-
-## Inbound 前置条件
-
-进入流程 D 前，先检查：
-
-1. `BRAND.md`
-2. 对应 campaign 目录
-3. 可匹配的 `KOLS.md` / `CONVERSATIONS/*.md`
-
-缺任何一项，都不要继续正常谈判；直接转状态恢复或人工跟进。
-
----
-
-## 流程 A：商家初始化
-
-1. 初始化工作目录：
-
-   ```bash
-   mkdir -p ~/kol-outreach/campaigns
-   cp -r $CLAUDE_SKILL_DIR/template/merchant/. ~/kol-outreach/
-   cd ~/kol-outreach && git init && git add -A && git commit -m "init merchant workspace"
-   ```
-
-2. 填 `BRAND.md`
-   - 询问：`brand_name`
-   - 从 `brand_name` 生成 kebab-case 的 `brand_slug` 建议
-   - 调 `scout outreach brand-slug check {slug}`
-   - 如果可用，让商家确认；如果被占用，让商家从建议里选或自己改
-   - 成功后调 `scout outreach brand-slug claim`
-   - 继续询问：`brand_website`、`brand_social`、`default_contact_name`、`default_brand_pitch`
-   - 提供默认兜底话术和默认双语 `escalation_keywords`，让商家确认或修改
-   - 写回 `BRAND.md`
-   - `git add BRAND.md && git commit -m "setup BRAND.md"`
-
-3. 填 `MERCHANT_LIMITS.md`
-   - 默认 `max_daily_sends: 50`
-   - 初始化 `sent_today: 0`
-   - 初始化 `date_utc: $(date -u +%Y-%m-%d)`
-   - 写回并 commit
-
-4. 告诉商家：merchant 级配置已完成，继续创建第一个 campaign。
-
----
-
-## 流程 B：创建 Campaign
-
-1. 确定 `campaignId`
-   - 询问商家要为哪个商品建联
-   - 从商品标题生成 kebab-case slug 建议
-   - 校验：
-     - 与 `CAMPAIGNS.md` 现有 campaign 不重复
-     - 匹配 `^[a-z0-9][a-z0-9-]{0,29}$`
-   - 让商家确认或修改
-
-2. 创建 campaign 目录
-
-   ```bash
-   mkdir -p ~/kol-outreach/campaigns/{campaignId}
-   cp -r $CLAUDE_SKILL_DIR/template/campaign/. ~/kol-outreach/campaigns/{campaignId}/
-   cd ~/kol-outreach && git add -A && git commit -m "init campaign {campaignId}"
-   ```
-
-3. 分段填写 `CONFIG.md`
-   - 依次填写：
-     - campaign 元信息
-     - 商品
-     - 目标 KOL 画像
-     - 预算与报价
-     - 合作条款边界
-     - 兜底话术覆写
-     - 运行参数
-   - 严格校验：
-     - `max_price >= target_price >= first_offer`
-     - `max_step <= max_price - first_offer`
-     - `total_budget >= max_price`
-   - 任一不满足：说明原因，给出调整建议，重新问
-   - 每个大段写完后都要写文件并 commit
-
-4. 更新 `CAMPAIGNS.md`
-   - 追加一行新 campaign，`status=active`
-
-5. `git commit -m "[{campaignId}] campaign ready"`
-
-6. 告诉商家 campaign 已就绪，并询问是否立即开始发现 KOL。
-
----
-
-## 流程 C：发现 KOL 与首发 Outreach
-
-先按这个顺序执行：
-
-- 先定 campaign
-- 再检查并行上限和 merchant 日配额
-- 先发现 KOL，再补拉 bio / email
-- LLM 只产出模板变量，不直接写邮件正文
-- 每发出一封邮件，都要立刻写回并 commit
-
-1. 确定 campaign
-   - 如果用户指定 campaign，用指定值
-   - 如果用户未指定，读 `CAMPAIGNS.md`
-     - 只有一个 active：用它
-     - 多个 active：列出让商家选
-
-2. 读取所需文件
-   - `CONFIG.md`
-   - `KOLS.md`
-   - `BRAND.md`
-   - `MERCHANT_LIMITS.md`
-   - `TEMPLATES.md`
-
-3. 检查并行上限
-   - `in_flight = KOLS.md 中 status ∈ {awaiting_reply, in_progress} 的行数`
-   - `available_slots = max_concurrent_kols - in_flight`
-   - `available_slots <= 0`：告诉商家当前已达并行上限，退出
-   - `target_new = min(CONFIG.target_kols_this_round, available_slots)`
-
-4. 检查 merchant 日发信配额
-   - 读取 `MERCHANT_LIMITS.md`
-   - 如果 UTC 日期变了，先归档昨天计数，再把 `sent_today` 重置为 0
-   - `daily_budget = max_daily_sends - sent_today`
-   - `daily_budget <= 0`：告诉商家今日配额已用完，退出
-   - `本轮发送量 = min(target_new, daily_budget)`
-
-5. 调 `scout tiktok creators`
-
-   ```bash
-   scout tiktok creators \
-     --follower-count "<CONFIG.follower_count_range>" \
-     --country "<CONFIG.region>" \
-     --limit <本轮发送量 * 3> \
-     --format json
-   ```
-
-6. 过滤候选人
-   - `engagement_rate < 2%` 丢弃
-   - 已在 `KOLS.md` 的 `username` 丢弃
-   - 粉丝量不在目标区间的丢弃
-
-7. 补拉 bio / email 并写 `KOLS.md`
-   - 对每个候选 KOL 调 `scout tiktok creator-products @username --limit 5`
-   - 如果 creators 结果没带 bio，就从这里补拉
-   - 用正则从 bio 提取 email
-   - 有 email：
-     - 追加到 `KOLS.md`
-     - `status=pending_outreach`
-   - 没 email：
-     - 追加到 `KOLS.md`
-     - `status=no_contact`
-   - `git commit -m "[{campaignId}] discovered N KOLs"`
-
-8. 发送首发 outreach
-   - 只处理 `status=pending_outreach`，并限制在本轮发送量内
-   - 读取 `TEMPLATES.md` 中的 `first_outreach_v1`
-   - 让 LLM 只输出模板变量 JSON，例如：
-
-     ```json
-     {
-       "kol_first_name": "...",
-       "opener_line": "...",
-       "fit_reason": "...",
-       "product_one_liner": "..."
-     }
-     ```
-
-   - 用模板渲染正文，不要直接自由写 body
-   - 终检：
-     - body 不含 `forbidden_phrases`
-     - body 长度 `<= 2000`
-   - 任一不过：
-     - 写 `KOLS.md` 为 `send_error`
-     - 记 `PROGRESS.md`
-     - 跳过该 KOL
-
-9. 调 `scout outreach send`
-
-   ```bash
-   echo '{
-     "to": "kol_email",
-     "subject": "Collaboration opportunity with <brand_name>",
-     "body": "<rendered body>",
-     "from_merchant_id": "<merchantId>",
-     "from_campaign_id": "<campaignId>",
-     "from_brand_slug": "<BRAND.brand_slug>",
-     "from_brand_name": "<BRAND.brand_name>",
-     "from_contact_name": "<effective contact_name>"
-   }' | scout outreach send
-   ```
-
-10. 写回状态
-    - 在 `CONVERSATIONS/{username}.md` 追加 Round 1
-    - 把返回的 `message_id` 写入 conversation
-    - 更新 `KOLS.md`
-      - `pending_outreach -> awaiting_reply`
-      - `offer = first_offer`
-    - 更新 `MERCHANT_LIMITS.md`
-      - `sent_today += 1`
-    - 追加本 campaign 的 `PROGRESS.md`
-    - 重要事件同步追加 merchant `PROGRESS.md`
-    - `git commit -m "[{campaignId}] outreach sent to @{username}"`
-
-11. 告诉商家本次发送结果。
-
----
-
-## 流程 D：处理 KOL 回信
-
-先按这个顺序执行：
-
-- 先确定 campaign 和 KOL
-- 先做预检，再决定是否调用 LLM
-- LLM 只输出结构化决策，不直接写邮件正文
-- 任何校验不过都降级为 `escalate`
-- 每轮处理完都要写回文件、commit，并调用 `sentinel report`
-
-1. 读取本次 inbound 的消息内容
-   - 从当前消息中读取：
-     - `From`
-     - `Subject`
-     - `Message-ID`
-     - `In-Reply-To`
-     - `References`
-     - `Body`
-
-2. 确定 campaign
-   - 如果消息包含 `[KOL_INBOUND:{campaignId}]`：只处理该 campaign
-   - 如果消息包含 `[KOL_INBOUND]`：稍后在步骤 3 通过 `from_email` 匹配 campaign
-
-3. 按 `from_email` 匹配 KOL
-   - `campaignId` 已知：只读该 campaign 的 `KOLS.md`
-   - `campaignId` 未知：遍历 `~/kol-outreach/campaigns/*/KOLS.md`
-   - 匹配结果：
-     - 唯一匹配：继续
-     - 多个匹配：选 `last_update` 最新的 campaign
-     - 无匹配：按 orphan inbound 处理并退出
-   - 同一 campaign 内同一 email 有多条记录时，取 `status` 非终态的活跃记录
-
-4. 读取所需文件
-   - `CONFIG.md`
-   - `BRAND.md`
-   - `CONVERSATIONS/{username}.md`
-
-5. 先做预检
-   - `rounds >= CONFIG.max_rounds`：`escalate`
-   - 对话时长 `>= CONFIG.max_days`：`expired`
-   - 最新回信 body 命中 `escalation_keywords`：`escalate`
-   - 最后一条 inbound round 的 `message_id` 与本次 `in_reply_to` 不一致：按幂等性异常处理
-
-6. 如果预检触发异常
-   - 用 `escalate_fallback_v1` 模板渲染兜底回复
-   - 调 `scout outreach send` 发出回复
-   - 更新 `KOLS.md` 为 `needs_merchant_followup`
-   - 写 `PROGRESS.md`
-   - `git commit`
-   - `sentinel report --condition-met true --summary "layer2 escalate" --action-taken "..."`
-   - 退出
-
-7. 调用 LLM 生成结构化决策
-   - 输入：`CONFIG.md`、`BRAND.md`、`CONVERSATIONS/{username}.md`、最新回信、模板变量列表
-   - 输出 JSON，例如：
-
-     ```json
-     {
-       "action": "counter_offer | accept | decline | clarify | escalate",
-       "new_price": 200,
-       "final_price": 250,
-       "concessions": ["video_retention_90d"],
-       "template_id": "counter_offer_v1",
-       "template_vars": {},
-       "reasoning": "..."
-     }
-     ```
-
-8. 校验 LLM 输出
-   - `action ∈ {counter_offer, accept, decline, clarify, escalate}`
-   - 如果 `counter_offer`
-     - `CONFIG.first_offer <= new_price <= CONFIG.max_price`
-     - `new_price - previous_offer <= CONFIG.max_step`
-   - 如果 `accept`
-     - `CONFIG.first_offer <= final_price <= CONFIG.max_price`
-     - `committed_so_far + final_price <= CONFIG.total_budget`
-   - `concessions` 只能来自允许集合
-   - `template_id` 必须存在于本 campaign 的 `TEMPLATES.md`
-   - 任一不通过：降级为 `escalate`
-
-9. 渲染模板并终检
-   - 用 `template_id + template_vars` 渲染最终 body
-   - 终检：
-     - body 不含 `forbidden_phrases`
-     - body 长度 `<= 2000`
-   - 不通过：降级为 `escalate`
-
-10. 发送回复
-    - 调 `scout outreach send`
-    - 带上：
-      - `in_reply_to = KOL 的 message_id`
-      - `references = 原 references + KOL 的 message_id`
-    - 拿到新 `message_id`
-
-11. 写回状态
-    - 在 `CONVERSATIONS/{username}.md` 追加新一轮，保留完整 LLM decision JSON
-    - 更新 `KOLS.md`
-      - 更新 `rounds`
-      - 更新 `current_offer`
-      - 更新 `last_update`
-      - `accept -> deal_reached`
-      - 其他正常回复 -> `awaiting_reply`
-    - 更新 `MERCHANT_LIMITS.md`
-      - `sent_today += 1`
-    - 如果 `action == accept`
-      - 给商家注册邮箱发送 `deal_confirmation_v1`
-      - 在 merchant `PROGRESS.md` 记录达成合作
-    - 追加 campaign `PROGRESS.md`
-    - `git commit -m "[{campaignId}] round N {action} with @{username}"`
-
-12. 调 `sentinel report`
-
-   ```bash
-   sentinel report --condition-met true --summary "..." --action-taken "..."
-   ```
-
----
-
-## 流程 E：查询进展
-
-1. 读 `CAMPAIGNS.md`
-
-2. 确定范围
-   - 用户指定 campaign：只汇报该 campaign
-   - 未指定且只有一个 active：只汇报该 campaign
-   - 未指定且有多个 active：先给跨 campaign 摘要，再提示用户可继续查看单个 campaign
-
-3. 跨 campaign 摘要
-   - 对每个 campaign 读 `KOLS.md`
-   - 统计：
-     - `in_flight`
-     - `deal_reached`
-     - `needs_merchant_followup`
-   - 读 `CONFIG.md` 的 `total_budget`，计算已承诺预算
-   - 读 `MERCHANT_LIMITS.md` 的今日 `sent_today`
-   - 以 markdown 表格汇报
-
-4. 单 campaign 详情
-   - 读 `KOLS.md` 按 `status` 分桶
-   - 对每个 `needs_merchant_followup`，读对应 `CONVERSATIONS/{username}.md`，总结 KOL 诉求
-   - 读 campaign `PROGRESS.md` 最近 5 条
-   - 输出：
-     - 关键统计
-     - 需要人工处理的事项
-     - 最近进展
-
----
-
-## 异常处理
-
-- `scout outreach send` 返回 `ok: false`
-  - 更新 `KOLS.md` 为 `send_error`
-  - 记 `PROGRESS.md`
-  - 不要中断其他 KOL 的处理
-
-- LLM 结构化输出格式错误
-  - 重试 1 次
-  - 仍失败：降级为 `escalate`
-
-- unknown campaign
-  - 写 merchant `PROGRESS.md`
-  - `sentinel report --condition-met false --summary "unknown campaign"`
-  - 退出
+## Session 路由
+
+按优先级依次判断：
+
+| 条件 | 流程 |
+|------|------|
+| 消息含 `[KOL_INBOUND:{campaignId}]` 或 `[KOL_INBOUND]` | → 回信处理 |
+| `~/kol-outreach/BRAND.md` 不存在 | → 商家初始化 → 创建 Campaign |
+| 用户提到了新商品 + 该商品无对应 campaign | → 创建 Campaign |
+| 用户要求发送 outreach / 开始建联 | → 发现 + Outreach |
+| 用户问进展 / 状态 / 数据 | → 查询进度 |
+
+**Campaign 定位**：用户指定了 campaign 用指定值；未指定时读 `CAMPAIGNS.md`——只有一个 active 就用它，多个则列出让商家选。
+
+## 商家初始化
+
+只在 `~/kol-outreach/BRAND.md` 不存在或未完整填写时执行。
+
+1. `cp -r $CLAUDE_SKILL_DIR/template/merchant/. ~/kol-outreach/` 并 `git init`
+2. 对话式填写 `BRAND.md`：
+   - `brand_name` → 生成 `brand_slug` 建议 → `scout outreach brand-slug check` 验证全局唯一 → 冲突则换 → `scout outreach brand-slug claim` 锁定
+   - 填完品牌基础、兜底话术、升级关键词（中英双语必填）、禁用词
+3. 填写 `MERCHANT_LIMITS.md`（默认 `max_daily_sends: 50`）
+4. `git add -A && git commit -m "merchant onboarding complete"`
+5. 继续创建第一个 campaign
+
+## 创建 Campaign
+
+1. 确定 `campaignId`：从商品标题生成 kebab-case slug，校验唯一且匹配 `^[a-z0-9][a-z0-9-]{0,29}$`
+2. `cp -r $CLAUDE_SKILL_DIR/template/campaign/. ~/kol-outreach/campaigns/{campaignId}/`
+3. 对话式填写 `CONFIG.md`，**逐段确认**：
+   - 商品信息 → KOL 画像 → 预算报价 → 合作条款 → 运行参数
+   - 预算校验：`max_price >= target_price >= first_offer`，`max_step <= max_price - first_offer`，`total_budget >= max_price`
+   - 不通过则说明原因、给建议、重新问（不退出）
+4. 更新 `CAMPAIGNS.md` 追加新行
+5. `git add -A && git commit -m "[{campaignId}] campaign ready"`
+6. 问商家是否立即开始发现 KOL
+
+## 发现 KOL + 首发 Outreach
+
+**前置检查**（任一不过则告知商家并退出）：
+- campaign 状态为 `active`
+- 本 campaign 在谈 KOL 数（`awaiting_reply` + `in_progress`）< `max_concurrent_kols`
+- merchant 今日发信数（`MERCHANT_LIMITS.md`）< `max_daily_sends`
+  - UTC 跨天时先归档昨天计数、重置 `sent_today=0`
+
+**发现**：
+
+1. `scout tiktok creators --follower-count <range> --country <region> --limit <N> --format json`
+2. 过滤：`engagement < 2%` 丢弃、已在 `KOLS.md` 丢弃、粉丝量不在区间丢弃
+3. 对每个候选：`scout tiktok creator-products @username --limit 5`，从 bio 提取 email
+4. 写入 `KOLS.md`：有 email → `pending_outreach`，无 email → `no_contact`
+5. `git commit -m "[{campaignId}] discovered N KOLs"`
+
+**Outreach**：
+
+对每个 `pending_outreach` KOL（不超过本轮发送量）：
+
+1. 读 `TEMPLATES.md` 的 `first_outreach_v1`
+2. 产出模板变量 JSON（`kol_first_name`, `opener_line`, `fit_reason`, `product_one_liner`）
+3. 渲染模板 → 终检（见「护栏」Layer 4）→ `scout outreach send`，JSON 必须包含：
+   `to`, `subject`, `body`, `from_merchant_id`, `from_campaign_id`, `from_brand_slug`, `from_brand_name`, `from_contact_name`
+4. 发送成功（`ok: true`）→ 写 `CONVERSATIONS/{username}.md`（Round 1）+ 更新 `KOLS.md` → `awaiting_reply` + `MERCHANT_LIMITS.md` sent_today +1
+5. 发送失败（`ok: false`）→ 标 `send_error`，不计入 sent_today，跳过该 KOL，不中断其他
+
+全部完成后：`git commit -m "[{campaignId}] outreach sent to N KOLs"` + 更新 PROGRESS.md
+
+## 处理 KOL 回信
+
+触发：消息含 `[KOL_INBOUND:{campaignId}]` 或 `[KOL_INBOUND]`。
+
+1. 从消息中提取 `From`, `Subject`, `Message-ID`, `In-Reply-To`, `Body`
+2. 定位 KOL：
+   - `campaignId` 已知 → 读该 campaign 的 `KOLS.md`，按 `from_email` 匹配
+   - `campaignId` 未知 → 遍历所有 `campaigns/*/KOLS.md`，按 `from_email` 匹配，多个取 `last_update` 最新
+   - 无匹配 → 写 PROGRESS.md + `sentinel report --condition-met false` + 退出
+3. 读 `CONFIG.md` + `BRAND.md` + `CONVERSATIONS/{username}.md`
+4. **预检**（见「护栏」Layer 2）→ 任一触发则发 `escalate_fallback_v1` 并退出
+5. 按「谈判策略」产出结构化决策 JSON
+6. **后验**（见「护栏」Layer 3）→ 不通过则降级为 escalate
+7. 渲染模板 → **终检**（见「护栏」Layer 4）→ `scout outreach send`
+   - 回信必须带 `in_reply_to`（KOL 的 `message_id`）和 `references`（`CONVERSATIONS` 里的完整 message-id chain）
+8. 写回 `CONVERSATIONS/{username}.md` + `KOLS.md` + `MERCHANT_LIMITS.md`
+9. 如果 `accept` → 发 `deal_confirmation_v1`，标 `deal_reached`
+10. `git commit -m "[{campaignId}] round N {action} @{username}"`
+11. `sentinel report --condition-met true --summary "..." --action-taken "..."`
+
+## 查询进度
+
+- **多 campaign**：读每个 campaign 的 `KOLS.md`，按 status 分桶统计，输出 markdown 表格 + merchant 级 `sent_today` 信息
+- **单 campaign**：读 `KOLS.md` 全表 + `PROGRESS.md` 最近 5 条。对每个 `needs_merchant_followup`，读 `CONVERSATIONS/{username}.md` 最后一轮，总结 KOL 诉求
+- 只读不写，不 commit
+
+## 谈判策略
+
+处理 KOL 回信时，产出一个结构化决策 JSON：
+
+```json
+{
+  "action": "counter_offer | accept | decline | clarify | escalate",
+  "new_price": null,
+  "final_price": null,
+  "concessions": [],
+  "template_id": "...",
+  "template_vars": {},
+  "reasoning": "..."
+}
+```
+
+**决策框架**：
+
+| KOL 回应 | 判断 | action |
+|----------|------|--------|
+| KOL 报价 ≤ `first_offer` | 低于预期，直接接受 | `accept` |
+| KOL 报价 ≤ `target_price` | 在目标范围内，可接受 | `accept` |
+| KOL 报价 ≤ `max_price` | 超出目标但可谈，渐进加价 | `counter_offer` |
+| KOL 报价 > `max_price` | 超预算，回一次低价试探 | `counter_offer`（报 `target_price`） |
+| KOL 连续 2 轮报价 > `max_price` | 已试探过，差距太大 | `decline` |
+| KOL 对之前的 counter 再次还价，且 ≤ `max_price` | 拉锯中，评估是否值得让步 | `counter_offer` 或 `accept` |
+| KOL 明确拒绝合作 | 尊重意愿 | `decline` |
+| KOL 问非价格问题（产品细节、时间线等） | 信息补充 | `clarify` |
+| KOL 提到超出授权范围的话题 | 不要硬答 | `escalate` |
+
+**出价规则**：
+
+- 首次 counter：从 `first_offer` 开始
+- 每轮加价不超过 `max_step`
+- 绝不超过 `max_price`
+- 加 concession 时优先用 `allowed_uses` 里的授权项（转发、二创等）作为附加价值，而非直接加钱
+- 本 campaign 已承诺预算（`deal_reached` 的 offer 总和）+ 本次报价不能超 `total_budget`
+
+**tone**：
+
+- 专业友好，不卑不亢
+- 不要用 "unfortunately" / "sadly" — 直接说 "our budget is..."
+- 每封回信开头用一句话承接 KOL 上一封的内容（`acknowledge_line`）
+- 永远不要透露 `max_price`、`total_budget`、或谈判策略
+
+## 护栏
+
+四层防线。任一层失败都**不问商家**——自动降级为发兜底话术 + 标记 `needs_merchant_followup`。
+
+### Layer 1 — Onboarding 校验
+
+写 `BRAND.md` / `CONFIG.md` 时执行：
+- 所有必填字段非空
+- `brand_slug` 全局唯一（通过 `scout outreach brand-slug check`）
+- `max_price >= target_price >= first_offer`
+- `max_step <= max_price - first_offer`
+- `total_budget >= max_price`
+- `escalation_keywords` 中英双语都有
+- 不通过 → 继续追问，不退出 onboarding
+
+### Layer 2 — 回信预检（调 LLM 前）
+
+- `rounds >= max_rounds` → `needs_merchant_followup`
+- `now - started >= max_days` → 标 `expired`，**不发邮件**，直接退出
+- KOL 回信命中 `escalation_keywords`（中英双语匹配） → 发 `escalate_fallback_v1`
+- `in_reply_to` 与 conversation 最后一条 inbound 的 `message_id` 不一致 → 发 `escalate_fallback_v1`
+
+### Layer 3 — 决策后验（产出 JSON 后）
+
+- `action` 必须在白名单内
+- `counter_offer`: `first_offer <= new_price <= max_price`，`new_price - previous_offer <= max_step`
+- `accept`: `first_offer <= final_price <= max_price`，`committed + final_price <= total_budget`
+- `concessions ⊆ allowed_terms`
+- `template_id` 存在于 `TEMPLATES.md`
+- 任一不通过 → 降级 `escalate`，不重试
+
+### Layer 4 — 内容终检（发送前）
+
+- body 不含 `forbidden_phrases`
+- body 长度 ≤ 2000 字符
+- 不通过 → 不发送，降级 `escalate`
+
+## 允许的命令
+
+- `scout tiktok creators` / `scout tiktok creator-products`
+- `scout outreach send` / `scout outreach brand-slug check|claim`
+- `sentinel report`
 
-- orphan inbound / unknown KOL
-  - 写对应 `PROGRESS.md`
-  - `sentinel report --condition-met false`
-  - 退出
+## 常见错误
 
-- git commit 失败
-  - 说明冲突原因
-  - 修复后重试
-  - 不要擅自 reset
+❌ 自由撰写邮件正文 → ✅ 只产出模板变量 JSON，用 TEMPLATES.md 渲染
 
-- UTC 日期跨天
-  - 读 `MERCHANT_LIMITS.md` 时先归档昨天计数，再继续
+❌ 一次 session 混做多个流程 → ✅ 单会话单任务
 
----
+❌ 每一小步都 git commit → ✅ 每个逻辑动作完成后 commit 一次（发现、outreach、单个回信处理）
 
-## 允许使用的命令
+❌ 护栏失败后重试 LLM → ✅ 直接降级为 escalate
 
-只使用这些命令：
+❌ 透露 max_price / total_budget / 谈判策略 → ✅ 只透露当前报价
 
-- `scout tiktok creators`
-- `scout tiktok creator-products`
-- `scout outreach send`
-- `scout outreach brand-slug check|claim`
-- `sentinel report`
+❌ expired 的 KOL 还发邮件 → ✅ 标 expired 直接退出，不发信
 
-不要这样做：
+❌ 修改不属于当前任务的 campaign 状态 → ✅ 只操作当前 campaign
 
-- 不要绕过模板直接自由写外发邮件
-- 不要跳过本地 workspace 状态检查
-- 不要一次 session 混做多个流程
-- 不要修改不属于本次任务的 campaign 状态
+❌ scout outreach send 失败就中断全部 → ✅ 标 send_error 跳过该 KOL，继续其他

package/.claude/skills/linting-the-wiki/SKILL.md

@@ -1,45 +1,36 @@
 ---
 name: linting-the-wiki
-description: Use when a maintained knowledge base needs a health check for gaps, stale claims, contradictions, missing links, or indexing issues.
+description: "检查知识库健康度。当用户说'检查知识库'、'知识库有什么问题'时使用。"
 ---
 
 # Linting The Wiki
 
-这个 skill 用来检查 wiki 随时间推移后的完整性和可维护性。
+检查 wiki 随时间推移后的完整性和可维护性。
 
-## 职责
+## 启动 SOP
 
-- 识别 orphan pages
-- 识别断链或缺失链接
-- 识别过时或已被覆盖的结论
-- 识别矛盾
-- 识别索引覆盖不足
-- 识别值得通过 web search 或补充来源来填补的数据空白
-- 提出或执行有边界的修复
+1. `ls ~/kb/REGISTRY.md`
+   - 不存在 → 告诉用户"还没有知识库，需要先创建一个"，引导使用 initializing-kb
+2. 读 `~/kb/REGISTRY.md` — 获取所有 active 的 KB 列表
+3. 确定目标 KB：
+   - 用户明确指定了 KB slug 或主题 → 直接用
+   - 用户说"全部 lint" → 遍历所有 active KB
+   - 只有一个 active KB → 用它
+   - 多个 active → 列出让用户选
+4. 读 `~/kb/<slug>/AGENTS.md` 了解该 KB 的契约
 
-## 不负责
+## Lint 流程
 
-- 初始 schema 设计
-- 无边界 wiki 重写
-
-## 工作规则
-
-lint 的目标是让维护债务变得可见。如果某条结论已经过时或被冲突信息挑战，这件事应该很容易被发现。
-
-## 流程
-
-使用这个 skill 时，按以下顺序进行：
-
-1. 检查 `index.md`、关键 wiki 目录和一组有代表性的页面
+1. 检查 `~/kb/<slug>/index.md`、关键 wiki 目录和一组有代表性的页面
 2. 先识别结构性问题，再决定是否动手修改
 3. 按类型归类问题：链接、覆盖度、过时、矛盾、重复、页面规模或索引问题
 4. 除非用户要求更大范围修复，否则只应用小而明确的修补
 5. 清楚报告仍未解决的问题
+6. 追加 `~/kb/PROGRESS.md`
+7. `cd ~/kb && git add -A && git commit -m "[<slug>] lint: <发现N个问题，修复M个>"`
 
 ## 要检查什么
 
-应检查：
-
 - 没有入链或出链的页面
 - 被反复提及但没有独立页面的实体或概念
 - 本应并入 overview 的 analysis 页面，或反过来的情况
@@ -57,7 +48,7 @@ lint 的目标是让维护债务变得可见。如果某条结论已经过时或
 - 澄清过时标签
 - 就地标出矛盾
 
-不要把 lint 变成无边界重写。如果需要更深层次的结构调整，要明确说出来，并在边界处停下，除非用户明确要求继续。
+不要把 lint 变成无边界重写。需要更深层次调整时，明确说出来并停下，除非用户明确要求继续。
 
 ## 最小交付标准
 

package/.claude/skills/querying-the-wiki/SKILL.md

@@ -1,38 +1,33 @@
 ---
 name: querying-the-wiki
-description: Use when answering questions against an existing wiki-like knowledge base and deciding whether the result should be preserved.
+description: "从已有知识库中查询和回答问题。当用户提到的话题可能在 ~/kb/ 的某个知识库中有覆盖时使用。"
 ---
 
 # Querying The Wiki
 
-这个 skill 通过把“维护后的 wiki”视为主要知识层来回答问题。
+通过把维护后的 wiki 视为主要知识层来回答问题。
 
-## 职责
+## 启动 SOP
 
-- 从 `index.md` 开始
-- 阅读相关 wiki 页面
-- 优先基于维护后的 wiki 回答
-- 在适当时把长期有效的结果回写到 `wiki/analyses/` 或 overview 页面
+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 的契约
 
-## 不负责
+## 查询流程
 
-- 把每个问题都转成新的 ingest
-- 大规模维护性重构
-
-## 工作规则
-
-如果一个答案之后大概率还会有用，就应把它保存在 wiki 中，而不是只留在聊天里。
-
-## 流程
-
-使用这个 skill 时，按以下顺序进行：
-
-1. 阅读 `index.md`
+1. 读 `~/kb/<slug>/index.md`
 2. 找到最相关的 wiki 页面
-3. 优先基于这些维护后的页面回答
+3. 优先基于维护后的页面回答
 4. 只有在 wiki 不完整或含混时才回到 raw sources
 5. 判断这个答案是否应该被保留
-6. 如果应该，就把它写进 `wiki/analyses/` 或对应 overview 页面
+6. 如果应该，写进 `~/kb/<slug>/wiki/analyses/` 或对应 overview 页面
+7. 追加 `~/kb/PROGRESS.md`
+8. `cd ~/kb && git add -A && git commit -m "[<slug>] query: <一句话>"`
 
 ## Query 规则
 
@@ -42,7 +37,7 @@ description: Use when answering questions against an existing wiki-like knowledg
 - 当答案依赖不完整或过时的 wiki 覆盖时，要说清楚
 - 把 source-backed 内容与综合推断区分开
 - 标出这个问题是否暴露了 wiki 的结构性空缺
-- 尽量在答案中显式引用所使用的 wiki 页面；如果回看了 raw sources，也要说明
+- 在答案中显式引用所使用的 wiki 页面；如果回看了 raw sources，也要说明
 
 ## 何时保留结果
 
@@ -53,14 +48,12 @@ description: Use when answering questions against an existing wiki-like knowledg
 - 这个答案形成了可长期复用的综合
 - 这个答案解决了当前 wiki 尚未解释清楚的混乱点
 
-独立的长期输出应进入 `wiki/analyses/`。如果这个答案主要是在改进某个主题的现有综述，则应写入对应 overview 页面。
+独立的长期输出应进入 `wiki/analyses/`。如果主要是改进某个主题的现有综述，则写入对应 overview 页面。
 
 ## 最小交付标准
 
 一次成功的 query 至少应产出：
 
 - 一个直接回答用户问题的结果
-- 在答案中或答案后明确引用使用了哪些 wiki 页面
+- 在答案中明确引用使用了哪些 wiki 页面
 - 清楚说明这个结果是否值得被保留
-
-如果答案暴露了长期缺口，却没有说明 wiki 该在哪里补强，这次 query 就是不完整的。

package/.claude/skills/updating-related-pages/SKILL.md

@@ -1,40 +1,33 @@
 ---
 name: updating-related-pages
-description: Use when newly ingested source material affects existing entity pages, overview pages, or cross-references in the wiki.
+description: "在 ingest 后同步更新知识库的关联页面。通常由 ingesting-sources 触发，不单独使用。"
 ---
 
 # Updating Related Pages
 
-这个 skill 用来在来源 ingest 之后，同步 wiki 的其他部分。
+在来源 ingest 之后，同步 wiki 的其他部分。
 
-## 职责
+## 启动 SOP
 
-- 更新相关 entity 页面
-- 更新相关 overview 页面
-- 增加或修复交叉链接
-- 显式记录冲突
-- 更新 `index.md`
-- 追加 `log.md`
+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 的契约
 
-## 不负责
-
-- 独自承担完整 ingest 流程
-- 替代 query 行为
-
-## 工作规则
-
-当新证据改变已有认知时，不要静默覆盖旧结论。应把修正过程明确写出来。
-
-## 流程
-
-使用这个 skill 时，按以下顺序进行：
+## 更新流程
 
 1. 从来源页或 ingest 产出的 affected-page 列表开始
 2. 确认哪些 entity、overview 和 analysis 页面需要更新
 3. 优先更新现有页面，而不是先新建页面
-4. 为这些变更后的页面补齐或修复交叉链接
-5. 如果创建了新的长期页面，则更新 `index.md`
-6. 如果这次变更实质性影响了 wiki，则在 `log.md` 中追加记录
+4. 为变更后的页面补齐或修复交叉链接
+5. 如果创建了新的长期页面，更新 `~/kb/<slug>/index.md`
+6. 如果这次变更实质性影响了 wiki，在 `~/kb/<slug>/log.md` 中追加记录
+7. 追加 `~/kb/PROGRESS.md`
+8. `cd ~/kb && git add -A && git commit -m "[<slug>] update: <更新了哪些页面>"`
 
 ## 更新规则
 
@@ -55,8 +48,6 @@ description: Use when newly ingested source material affects existing entity pag
 - 更新当前理解
 - 让之后的读者仍然看得出分歧在哪里
 
-页面要体现“理解是如何变化的”，而不只是“它发生了变化”。
-
 ## 何时创建新页面
 
 只有在下列情况下才应新建页面：
@@ -65,12 +56,10 @@ description: Use when newly ingested source material affects existing entity pag
 - 某个 analysis 或 comparison 已经有独立长期价值
 - 现有页面已经过宽，无法干净吸收这次更新
 
-如果对现有页面做一次聚焦更新会让 wiki 更清楚，那就不要新建页面。
-
 ## 最小交付标准
 
 一次成功的 related-page update 至少应留下：
 
-- 被同步更新过的相关页面，而不是只有一张孤立来源页
+- 被同步更新过的相关页面
 - source、entity、overview 和 analysis 页面之间清晰的交叉链接
-- 在适用时，对“理解发生变化”这件事有可见处理
+- 在适用时，对"理解发生变化"有可见处理

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@optima-chat/optima-agent",
-  "version": "0.8.99",
+  "version": "0.8.100",
   "description": "基于 Claude Agent SDK 的电商运营 AI 助手",
   "type": "module",
   "main": "dist/src/index.js",