@optima-chat/optima-agent 0.9.13 → 0.9.15

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

@@ -1,65 +1,65 @@
----
-name: updating-related-pages
-description: "在 ingest 后同步更新知识库的关联页面。通常由 ingesting-sources 触发，不单独使用。"
----
-
-# Updating Related Pages
-
-在来源 ingest 之后，同步 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 的契约
-
-## 更新流程
-
-1. 从来源页或 ingest 产出的 affected-page 列表开始
-2. 确认哪些 entity、overview 和 analysis 页面需要更新
-3. 优先更新现有页面，而不是先新建页面
-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: <更新了哪些页面>"`
-
-## 更新规则
-
-更新既有页面时：
-
-- 保持页面的稳定职责
-- 把新信息合并进正确的 section，而不是随手堆一段笔记
-- 当新来源改变了先前理解时，要让修正过程可见
-- 让 source-backed 内容与综合推断保持可区分
-- 优先使用可链接的短陈述，而不是长段无结构文字
-
-## 冲突处理
-
-如果新来源与旧页面冲突：
-
-- 不要无解释地删除旧结论
-- 记录新的证据
-- 更新当前理解
-- 让之后的读者仍然看得出分歧在哪里
-
-## 何时创建新页面
-
-只有在下列情况下才应新建页面：
-
-- 新信息引入了一个 recurring concept，但还没有稳定 landing page
-- 某个 analysis 或 comparison 已经有独立长期价值
-- 现有页面已经过宽，无法干净吸收这次更新
-
-## 最小交付标准
-
-一次成功的 related-page update 至少应留下：
-
-- 被同步更新过的相关页面
-- source、entity、overview 和 analysis 页面之间清晰的交叉链接
-- 在适用时，对"理解发生变化"有可见处理
+---
+name: updating-related-pages
+description: "在 ingest 后同步更新知识库的关联页面。通常由 ingesting-sources 触发，不单独使用。"
+---
+
+# Updating Related Pages
+
+在来源 ingest 之后，同步 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 的契约
+
+## 更新流程
+
+1. 从来源页或 ingest 产出的 affected-page 列表开始
+2. 确认哪些 entity、overview 和 analysis 页面需要更新
+3. 优先更新现有页面，而不是先新建页面
+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: <更新了哪些页面>"`
+
+## 更新规则
+
+更新既有页面时：
+
+- 保持页面的稳定职责
+- 把新信息合并进正确的 section，而不是随手堆一段笔记
+- 当新来源改变了先前理解时，要让修正过程可见
+- 让 source-backed 内容与综合推断保持可区分
+- 优先使用可链接的短陈述，而不是长段无结构文字
+
+## 冲突处理
+
+如果新来源与旧页面冲突：
+
+- 不要无解释地删除旧结论
+- 记录新的证据
+- 更新当前理解
+- 让之后的读者仍然看得出分歧在哪里
+
+## 何时创建新页面
+
+只有在下列情况下才应新建页面：
+
+- 新信息引入了一个 recurring concept，但还没有稳定 landing page
+- 某个 analysis 或 comparison 已经有独立长期价值
+- 现有页面已经过宽，无法干净吸收这次更新
+
+## 最小交付标准
+
+一次成功的 related-page update 至少应留下：
+
+- 被同步更新过的相关页面
+- source、entity、overview 和 analysis 页面之间清晰的交叉链接
+- 在适用时，对"理解发生变化"有可见处理

package/.claude/skills/video-edit/SKILL.md

@@ -1,138 +1,123 @@
----
-name: video-edit
-description: "剪辑用户【已有的】口播视频——去除卡顿停顿让视频更流畅紧凑。
-
-  必备前提：用户已经有视频文件（拍好的、上传的、或给出文件路径）。
-
-  触发：用户上传/给出视频文件 + 说'剪一下'/'去卡顿'/'变流畅'/
-  '剪辑'/'剪短点'/'加字幕'/'cut'/'edit'/'trim'/'让视频更紧凑'。"
----
-
-# Video-Edit Skill — 让视频变流畅
-
-用户给原始视频，你交付剪好的成片。**中间所有步骤对用户透明**。
-
-## 用户怎么说，你交付什么
-
-**默认所有剪辑都带字幕**——中文短视频（TikTok / 小红书 / 视频号）99% 需要字幕，"剪一下"的潜台词就是"给我能直接发的成片"。
-
-| 用户说 | 你交付 |
-|---|---|
-| "剪一下" / "去卡顿" / "变流畅" | `<video>_subbed.mp4`（剪 + 字幕） |
-| "剪成 X 秒短视频" / "30 秒" | `<video>_subbed.mp4`（压到目标时长 + 字幕） |
-| "加字幕"（不需要剪） | `<video>_subbed.mp4`（仅字幕） |
-| "剪一下不要字幕" / "无字幕版" | `<video>_edited.mp4` |
-
-只有当用户提到平台但**没说目标时长**时（如"剪成 TikTok"无时长），才追问"目标多长？"。
-其他情况**直接动手**，不要废话。
-
-## 你的内部流程（用户不需要知道）
-
-### 默认剪辑（剪 + 字幕，最常见）
-
-```bash
-video-edit both <video>
-video-edit review <video>
-# review 通过后烧字幕：
-video-edit subtitle <video>
-```
-
-**3 关审片**全过才烧字幕交付：
-
-**第 1 关：声学审片（review 报告给）**
-- 全 OK → 进入第 2 关
-- 有 HARD issue（dead air / 切到字中间 / 重复内容）→ **你自己**编辑 `<video>.work/cut_proposal.md`，把问题段行首加 `#`，重跑 `cut` → `review`
-- **修复尝试上限**：≤ 2 次重剪还有同样的 HARD → 停止循环，按现状继续，**不主动**告诉用户残留小问题（黑盒交付原则；用户问起再答）
-- **小残留静音容忍**：唯一 HARD 是 `residual-silence-at-cut < 0.15s`（切点淡化固有产物，再剪也修不掉）→ 直接接受
-
-**第 2 关：语义审片（你自己做，必做）**
-
-成片"实际说出来的话" ≠ 你保留的 phrase 拼接（有转写误差 + 切点丢字）。**你自己跑**：
-
-```bash
-# 重转写成片（调用远程 GPU whisper API）
-curl -s -X POST ${WHISPER_API_URL:-http://111.17.197.107:8000}/transcribe \
-  -F "file=@<video>_edited.mp4" \
-  -F "language=zh" > <video>.work/edited_audit.json
-
-cat <video>.work/edited_audit.json
-cat <video>.work/cut_proposal.md   # 看未被 # 注释的行
-```
-
-**对比检查**（任一发现 → HARD，回去改 proposal 重剪，同样 ≤ 2 次上限）：
-- 句子被切半（"我们..."没下文 / "因为..."没结果）
-- 指代物丢失（"这个" / "那种" / "上面那个" 但前文没了）
-- 承诺没兑现（"我说三个"但成片只剩两个）
-- 词义跳段（前一句说苹果，下一句说香蕉，承接句被剪）
-- 转写误差导致字错（whisper 把 "义乌" 转成 "亿物"）
-- **切点接合不顺**：成片转写的 words 里相邻 word gap > 0.4s 的位置（不是天然停顿）说明拼接生硬
-
-**两关全过 → 跑 subtitle 烧字幕 → 交付**
-
-`subtitle` 命令传**原片路径**即可（脚本会自动用 `_edited.mp4` 做输入），输出固定是 `<原片>_subbed.mp4`。
-
-如果第 1 关 review 显示语音占比 > 90%（说明几乎没卡顿要删，但用户原片可能有 NG 重录或跑题），改走"限时长精剪"路径让你自己决定删哪些短语——`both` 只删停顿，删不掉 NG / 废话。
-
-### 限时长精剪（用户给了目标时长）
-
-```bash
-video-edit analyze <video>
-```
-
-读 `<video>.work/cut_proposal.md`，**你自己**做这些判断：
-- 找钩子句放最前
-- 删跑题、删 NG、删填充词
-- 压到目标时长
-- 把要删的行首加 `#`，保存
-
-然后：
-```bash
-video-edit cut <video>
-video-edit review <video>
-```
-
-**剪完同样走"默认剪辑"里的 2 关审片**（声学 + 语义），全过再跑 `video-edit subtitle` → 交付 `<原片>_subbed.mp4`。
-
-限时长场景为了压时长更激进地删，**比默认剪辑更需要**这两关 — 不要跳过。
-
-### 仅字幕（用户明确说不剪）
-
-```bash
-video-edit subtitle <video>
-```
-
-没有 `_edited.mp4` 时，命令直接对原片烧字幕，输出 `<原片>_subbed.mp4`。
-
-### 无字幕版（用户明确说不要字幕）
-
-只跑 `both` + `review`，**不跑 subtitle**，交付 `<原片>_edited.mp4`。
-
-## 交付怎么说
-
-简洁，**只说结果**：
-
-- ✅ "剪好了，xxx_subbed.mp4，时长 23 秒"（默认带字幕的情况）
-- ✅ "无字幕版剪好了，xxx_edited.mp4，时长 23 秒"（用户要无字幕时）
-- ❌ "我用了 video-edit analyze，然后编辑了 cut_proposal.md..."
-- ❌ "review 显示 3 个 WARN，但都不影响..."
-
-review 自动修过的问题不用提；改了几次也不用提。
-
-## 不要做的事
-
-- ❌ 用户说"剪一下"就追问平台/钩子/时长——直接动手
-- ❌ 用户说"剪一下"只交付 `_edited.mp4` 不烧字幕——**默认带字幕**，除非用户明说不要
-- ❌ 让用户编辑 cut_proposal.md——**你来编辑**
-- ❌ 把命令名暴露给用户——简单交付即可
-- ❌ 编造命令（仅 5 个：both / analyze / cut / review / subtitle）
-- ❌ 用户说"剪掉前 X 秒"/"剪掉中间一段"——这是定点裁剪不是去卡顿停顿，video-edit 不做这个；直接告诉用户"我擅长去卡顿停顿，定点裁剪请用别的方式"
-
-## 命令参考（你内部用）
-
-| 命令 | 用途 |
-|---|---|
-| `video-edit both <video>` | 一键自动剪辑 |
-| `video-edit analyze <video>` | 生成 `<video>.work/cut_proposal.md` |
-| `video-edit cut <video>` | 按 proposal 剪辑 |
-| `video-edit review <video>` | 检查 `<video>_edited.mp4`，输出 review_report.md |
-| `video-edit subtitle <video>` | 烧字幕。传**原片路径**即可，自动找 `_edited.mp4` 做输入；输出固定是 `<原片>_subbed.mp4`（不会带 `_edited`） |
+---
+name: video-edit
+description: "剪辑用户【已有的】口播视频——去除卡顿停顿让视频更流畅紧凑。
+
+  必备前提：用户已经有视频文件（拍好的、上传的、或给出文件路径）。
+
+  触发：用户上传/给出视频文件 + 说'剪一下'/'去卡顿'/'变流畅'/
+  '剪辑'/'剪短点'/'加字幕'/'cut'/'edit'/'trim'/'让视频更紧凑'。"
+---
+
+# Video-Edit Skill — 让视频变流畅
+
+用户给原始视频，你交付剪好的成片。
+
+## 用户怎么说，你交付什么
+
+**默认所有剪辑都带字幕**——中文短视频（TikTok / 小红书 / 视频号）99% 需要字幕，"剪一下"的潜台词就是"给我能直接发的成片"。
+
+| 用户说 | 你交付 |
+|---|---|
+| "剪一下" / "去卡顿" / "变流畅" | `<video>_subbed.mp4`（剪 + 字幕） |
+| "剪成 X 秒短视频" / "30 秒" | `<video>_subbed.mp4`（压到目标时长 + 字幕） |
+| "加字幕"（不需要剪） | `<video>_subbed.mp4`（仅字幕） |
+| "剪一下不要字幕" / "无字幕版" | `<video>_edited.mp4` |
+
+只有当用户提到平台但**没说目标时长**时（如"剪成 TikTok"无时长），才追问"目标多长？"。
+其他情况**直接动手**，不要废话。
+
+## 核心原则：一键出片，不满意再调
+
+用户说"剪一下"，你**直接出成片**，不要中途停下来问确认。像开拍 app 一样：上传 → 自动出片 → 不满意再调。
+
+**不满意时的调整**：用户看完成片说"第X段不该删"/"XX那句话留着"，你编辑 `cut_proposal.md`（去掉/加上 `#` 注释），重跑 `cut` + `subtitle`，几秒出新版。
+
+## 你的内部流程
+
+### 默认剪辑（剪 + 字幕，最常见）
+
+一步到位，不要分步等确认：
+```bash
+video-edit both <video>
+video-edit subtitle <video>
+```
+
+`both` = analyze + cut，一口气完成转写、静音检测、生成 proposal、执行剪辑。
+`subtitle` 从原始转写推算字幕时间轴（不会重新调 whisper），烧录输出 `<原片>_subbed.mp4`。
+
+### 用户要求调整时
+
+用户看完成片说某段不对：
+1. 读 `<video>.work/cut_proposal.md`
+2. 编辑对应行（`#` 注释 = 删除，去掉 `#` = 保留）
+3. 删除 `<video>.work/subs.ass`（让 subtitle 重新生成）
+4. 重跑：
+```bash
+video-edit cut <video>
+video-edit subtitle <video>
+```
+
+这两步纯本地（不调 whisper），几秒完成。
+
+### 限时长精剪（用户给了目标时长）
+
+```bash
+video-edit analyze <video>
+```
+
+读 `<video>.work/cut_proposal.md`，**你自己**做这些判断：
+- 找钩子句放最前
+- 删跑题、删 NG、删填充词
+- 压到目标时长
+- 把要删的行首加 `#`，保存
+- 删除 `<video>.work/subs.ass`
+
+然后：
+```bash
+video-edit cut <video>
+video-edit subtitle <video>
+```
+
+### 仅字幕（用户明确说不剪）
+
+```bash
+video-edit subtitle <video>
+```
+
+没有 `_edited.mp4` 时，命令直接对原片烧字幕，输出 `<原片>_subbed.mp4`。
+
+### 无字幕版（用户明确说不要字幕）
+
+```bash
+video-edit both <video>
+```
+
+交付 `<原片>_edited.mp4`，不跑 subtitle。
+
+## 交付怎么说
+
+简洁，**只说结果**：
+
+- ✅ "剪好了，xxx_subbed.mp4，时长 23 秒"
+- ✅ "无字幕版剪好了，xxx_edited.mp4，时长 23 秒"
+- ❌ "我用了 video-edit analyze，然后编辑了 cut_proposal.md..."
+- ❌ "review 显示 3 个 WARN，但都不影响..."
+
+## 不要做的事
+
+- ❌ 用户说"剪一下"就追问平台/钩子/时长——直接 `both` + `subtitle`
+- ❌ 用户说"剪一下"只交付 `_edited.mp4` 不烧字幕——**默认带字幕**
+- ❌ 剪之前停下来展示方案等确认——**直接出片**，不满意再调
+- ❌ 把命令名、cut_proposal.md 路径暴露给用户——内部实现细节
+- ❌ 编造命令（仅 5 个：both / analyze / cut / review / subtitle）
+- ❌ 用户说"剪掉前 X 秒"/"剪掉中间一段"——定点裁剪不是去卡顿，告诉用户"我擅长去卡顿停顿，定点裁剪请用别的方式"
+
+## 命令参考（你内部用）
+
+| 命令 | 用途 |
+|---|---|
+| `video-edit both <video>` | **默认用这个**：analyze + cut 一步到位 |
+| `video-edit analyze <video>` | 仅转写 + 生成 proposal（限时长精剪时用） |
+| `video-edit cut <video>` | 按 proposal 剪辑，生成 `_edited.mp4` |
+| `video-edit review <video>` | 诊断用：检查 `_edited.mp4`，输出 review_report.md |
+| `video-edit subtitle <video>` | 烧字幕。传**原片路径**，自动找 `_edited.mp4` 做输入，输出 `<原片>_subbed.mp4` |