清理(.claude): 移除已迁移为 skills 的旧版命令文件

- 删除 .claude/commands/ 下 10 个命令文件，对应能力已迁移为 arno-* skills
2026-07-31 13:07:45 +08:00
parent 6ef0d3a091
commit 391fa484dc
10 changed files with 0 additions and 1537 deletions
@@ -1,182 +0,0 @@
---
-name: arno-anl-article
-description: 对单篇文章进行批判性阅读，提取事实与观点，输出结构化分析报告。在工作管理项目中，可用于深度理解行业动态、技术文章、政策法规等参考材料。触发词：分析文章、文章分析、深度阅读、提取观点、文章总结、批判性阅读。
-argument-hint: <文章文件路径>
---
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-用户输入为**单篇**本地 Markdown 文件的路径（绝对路径）。
-
-## 概述
-
-对单篇文章进行批判性阅读和结构化分析，提取事实与观点，给出独立评价，输出独立的 `_分析.md` 文件。本技能聚焦于"提炼可迁移的认知增量"，而非罗列文章内容。
-
-方法论参照 Vivek Nair《How to be good at research》中"文献阅读能力"框架：
-> 读书不要摘抄结论，核心拷问三个问题：作者的假设是什么？证据能否支撑结论？这个研究的边界和缺陷在哪里。
-
-## 执行流程
-
-### 第一步：读取文章
-
-使用 Read 工具读取目标文章全文内容。
-
-### 第二步：价值判断
-
-快速评估文章的认知价值，决定分析深度：
-
-| 判断维度 | 追问 | 高价值信号 |
-|----------|------|-----------|
-| 创新性 | 提供了什么"不知道的东西"？ | 挑战共识、提出新框架、解释反常 |
-| 可迁移性 | 结论能否跨场景复用？ | 可操作的方法论或思维模型 |
-| 论据质量 | 证据能否支撑结论？ | 实验数据、工程验证、一手经验 |
-| 边界意识 | 是否说明适用范围？ | 明确指出局限性和前提假设 |
-
- **高价值**（≥2 项高价值信号）→ 深度分析，完整输出
- **中等价值**（1 项）→ 标准分析
- **低价值**（0 项）→ 简要摘要，仍产出分析文件但篇幅精简
-
-### 第三步：批判性阅读
-
-对文章内容进行三个核心追问：
-
-1. **作者的假设前提是什么？** —— 建立在哪些未经证明的前提之上？如果前提不成立，结论是否仍有效？
-2. **论据是否支撑结论？** —— 证据链条是否完整？是否存在逻辑跳跃或选择性举证？
-3. **该研究的边界和缺陷在哪里？** —— 结论的适用范围是什么？哪些场景下结论可能失效？
-
-### 第四步：知识分类
-
-将文章观点归类：
-
-| 类别 | 定义 | 输出标记 |
-|------|------|---------|
-| **共识** | 业界广泛认同的观点 | 标注"业界共识" |
-| **争议** | 存在不同声音的方向 | 保留对立观点 |
-| **未探索** | 作者指出的空白 | 标注为后续关注线索 |
-| **范式突破** | 挑战现有框架的新思路 | **粗体突出** |
-
-### 第五步：提取事实与观点
-
-从文章中分离：
-
- **事实**：可验证的数据、事件、案例、实验结果
- **观点**：作者的判断、推论、建议、预测
- **金句**：可直接引用的精炼表达（2-5 句）
-
-### 第六步：生成分析报告
-
-分析报告保存为独立 Markdown 文件。
-
-**文件名**：`<原文文件名（不含.md）>_分析.md`，保存在原文同一目录。
-
-**模板**：
-
-```markdown
-# 📊 文章分析：<文章标题>
-
-> **原文**：<原文文件名>  
-> **分析日期**：<yyyy-MM-dd>
-
---
-
-## 一、文章概要
-
-| 属性 | 内容 |
-|------|------|
-| 标题 | <文章标题> |
-| 来源 | <公众号名称> |
-| 作者 | <作者名> |
-| 发布日期 | <yyyy-MM-dd> |
-| 价值评级 | ⭐⭐⭐ 高 / ⭐⭐ 中 / ⭐ 低 |
-
-**一句话概要**：<用一句话概括文章真正想说什么>
-
---
-
-## 二、事实提取
-
-从文章中提取的可验证信息：
-
-1. <事实 1>
-2. <事实 2>
-3. ...
-
-> 如无可验证事实，标注"本文以观点输出为主，无可独立验证的事实陈述"。
-
---
-
-## 三、观点提取
-
-作者的核心论断和判断：
-
-1. **<观点 1>** — <简要说明>
-2. **<观点 2>** — <简要说明>
-3. ...
-
---
-
-## 四、批判性分析
-
-### 4.1 作者假设前提
-
-<作者立论建立在哪些假设之上？>
-
-### 4.2 论据与逻辑
-
-<证据是否支撑结论？逻辑链条是否完整？>
-
-### 4.3 边界与局限
-
-<结论适用范围？哪些场景不适用？作者是否明确指出？>
-
---
-
-## 五、知识分类
-
-| 观点 | 分类 | 说明 |
-|------|------|------|
-| <观点简述> | 共识 / 争议 / 未探索 / **范式突破** | <分类理由> |
-
---
-
-## 六、可引用金句
-
-> "<金句 1>"
-
-> "<金句 2>"
-
---
-
-## 七、总体评价
-
-**亮点**：
- <优点 1>
- <优点 2>
-
-**不足**：
- <不足 1>
-
-**适用场景**：<结论适用于什么场景、什么人群>
-
-**关联建议**：<可进一步阅读的方向或文章>
-```
-
-### 模板规则
-
-1. 每个章节必须填写，不可省略
-2. 低价值文章可精简"批判性分析"和"知识分类"章节
-3. 观点提取必须忠实原文，区分"作者的结论"和"分析者的推断"
-4. 金句必须来自原文，不可改写
-5. 文件名中如有特殊字符，沿用原文的文件名安全规则（`_` 替换）
-
-## 关键指令
-
-1. **忠实原文**：不注入自己的观点，不选择性筛选结论
-2. **区分事实与观点**：事实可验证，观点是判断
-3. **批判性阅读**：不止于摘抄，追问假设、证据、边界
-4. **独立输出**：分析报告保存为独立的 `_分析.md` 文件，不修改原文
-5. **简洁有力**：每条要点控制在 1-3 行，金句直接引用
@@ -1,286 +0,0 @@
---
-name: 文章摘要
-description: 读取指定文章的 markdown 内容或链接，编写介绍和要点说明，格式与 知识/金鹏.md 中的文章列表一致
---
-
-## 核心原则（来自《How to be good at research》方法论）
-
-执行本命令时，始终遵循以下研究级质量标准：
-
-1. **区分信息与洞见**：不被动收纳信息，批判性阅读——追问作者的假设、论据、边界
-2. **区分工具与目标**：摘要的目标是"提炼可迁移的认知增量"，不是"罗列文章内容"
-3. **忠实原文**：不注入自己的观点，不选择性筛选结论迎合预设判断
-4. **延迟满足**：宁愿花时间写一个能串联多篇文章的深度摘要，不追求快速产出浅层概括
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-用户可以提供：
- 文章 URL（支持微信公众号、知乎、GitHub 等）
- 本地 markdown 文件路径
- 或直接粘贴的文章内容
-
-## 执行流程
-
-### 1. 读取文章内容
-
- **URL**：使用 `mcp__web-reader__webReader` 或 `WebFetch` 获取文章内容
- **本地文件**：使用 `Read` 工具读取
- **GitHub 仓库**：使用 `mcp__zread__get_repo_structure` 了解项目结构
-
-### 2. 价值判断（选题能力）
-
-在深入分析之前，快速评估文章的认知价值，这决定后续处理的深度：
-
-| 判断维度 | 追问 | 高价值信号 | 低价值信号 |
-|----------|------|-----------|-----------|
-| 创新性 | 这篇文章提供了什么"不知道的东西"？ | 挑战现有共识、提出新框架、解释反常现象 | 汇总已知信息、无独立观点 |
-| 可迁移性 | 结论能否跨场景复用？ | 提炼出可操作的方法论或思维模型 | 纯案例堆砌、无抽象提炼 |
-| 论据质量 | 作者的证据能否支撑结论？ | 有实验数据、工程验证、一手经验 | 纯观点输出、无实证支撑 |
-| 边界意识 | 作者是否说明了结论的适用范围？ | 明确指出局限性和前提假设 | 绝对化断言、无边界说明 |
-
- **高价值文章**（2 项以上高价值信号）→ 按体系内文章组处理，深度批判性阅读
- **中等价值文章**（1 项高价值信号）→ 按独立文章处理，标准分析
- **低价值文章**（无高价值信号）→ 简短摘要，不生成配图，不进入体系
-
-### 3. 批判性阅读（文献阅读能力）
-
-对文章进行深度分析，**不只是提取信息，而是追问**：
-
-#### 3a. 三个核心追问
-
-1. **作者的假设前提是什么？**——这篇文章建立在哪些未经证明的前提之上？如果前提不成立，结论是否仍然有效？
-2. **论据是否支撑结论？**——作者提供的证据链条是否完整？是否存在逻辑跳跃或选择性举证？
-3. **该研究的边界和缺陷在哪里？**——结论的适用范围是什么？作者是否明确指出了局限性？哪些场景下结论可能失效？
-
-#### 3b. 知识分类
-
-将文章观点归类到以下维度之一：
-
-| 类别 | 定义 | 摘要中的标记方式 |
-|------|------|-----------------|
-| **共识** | 业界已形成广泛认同的观点 | 用"业界共识"等表述说明 |
-| **争议** | 存在不同声音、尚无定论的方向 | 在要点中保留对立观点 |
-| **未探索方向** | 作者指出的空白或待解决问题 | 在要点末尾注明，作为后续关注线索 |
-| **范式突破** | 挑战现有框架的新思路 | 用**粗体**突出，作为核心命题优先考虑 |
-
-#### 3c. 提取关键要素
-
-在完成批判性追问和知识分类后，提取：标题和链接、来源/作者、核心论点、关键要点（3-8 个）、可引用金句。
-
-### 4. 草稿先行（学术写作能力）
-
-**写作不是收尾工作，而是梳理思路的工具。** 在编写正式摘要之前，先用 3-5 句话写一个"草稿摘要"：
-
- 这篇文章**真正想说什么**？（一句话核心命题）
- 它**为什么重要**？（跟现有认知有什么不同）
- 它**跟已有文章有什么关系**？（呼应、补充还是挑战？）
- 它**的局限是什么**？（什么场景下不适用）
-
-这个草稿**不进入最终输出**，目的是强迫自己在写正式摘要前理清逻辑。如果草稿写不清楚，说明对文章的理解还不够深——回到第 3 步重新阅读。
-
-### 5. 提取核心观点并构建体系
-
-**最关键的一步**，在编写具体内容之前完成：
-
-1. **提取核心命题**：基于批判性阅读和草稿的梳理，提炼一个能串联所有关联文章的核心命题，2-6 字（如"驾驭AI""智能体工程化"）。核心命题不应只是主题标签，而应体现文章的**独特认知贡献**
-2. **划分层级**：将关联文章按递进逻辑分层——总纲→实践层（团队/流程/产品）→战略层（组织）→根基层（文明/哲学），每层一个 2-3 字标签
-3. **排序**：体系内按层级递进排列，独立工具/项目放在最后
-4. **确定父条目**：为核心命题创建一个父条目——标题用核心命题，链接用首篇文章 URL，配一张代表图片和一句金句标签
-
-### 6. 自我批判检查点（学术沟通能力）
-
-在编写最终输出之前，用以下问题自查：
-
- **核心命题是否精准？** 是否只是换了个说法重复文章标题，还是真正抓住了文章的独特认知贡献？
- **关联是否真实？** 文章之间的"呼应""补充"关系是真实存在的，还是为了凑体系生造的联系？
- **是否有偷换概念？** 是否把工具/技术细节当成了核心认知贡献？（区分工具与目标）
- **金句是否可引用？** 加粗的句子如果单独拿出来，是否仍然有意义、有冲击力？
- **遗漏了什么？** 文章中最反常识、最容易被忽略的细节是否被覆盖了？
-
-如果任何一项自查不通过，回到第 4 或第 5 步修正。
-
-### 7. 生成文章配图
-
-摘要编写完成后，**必须**调用即梦 AI（Dreamina）为父条目或独立文章生成配图。
-
-**两图体系**：
-
-| 图片 | 尺寸 | 用途 | 文件命名 | 在摘要中的位置 |
-|------|------|------|---------|---------------|
-| **文章题图** | 16:9 横版 ≥2K，显示宽度 ≤1000px | 文章详情页展开查看 | `YYYYMMDD-NNN.png` | 第二行（金句标签上方） |
-| **列表标题图** | 160×90 像素 | 文章列表中作为条目缩略图展示 | `YYYYMMDD-NNN-thumb.png` | 第一行（紧接标题链接之后） |
-
-列表标题图由大图裁切生成（不单独调用即梦），确保两图视觉一致。
-
-#### 7a. 构建生成提示词
-
-从文章分析结果中提取以下元素构建文生图提示词：
-
- **核心命题**（2-6 字）作为画面主题
- **关键要点**（3-5 个核心概念）转化为视觉元素
- **文章调性**决定视觉风格：
-
-| 文章类型 | 风格建议 |
-|---------|---------|
-| AI/技术类 | 深蓝科技色调，光晕效果，扁平化商务风 |
-| 商业/战略类 | 暖色商务色调，简约现代，数据可视化元素 |
-| 人文/哲学类 | 柔和暖色调，抽象意境，留白设计 |
-
-提示词模板（16:9 横版，适合文章题图）：
-```
-一张关于"{核心命题}"的主题配图，{关键概念转化成的视觉元素}。{风格要求}。适合作为技术文章的题图，简洁有力。
-```
-
-> 只需生成一张 16:9 大图，160×90 列表标题图在步骤 7d 从大图裁切得到。
-
-#### 7b. 调用即梦生成大图
-
-使用 `Skill` 工具调用 `arno-dreamina` 技能，传入提示词和下载路径：
-
-```
-Skill: arno-dreamina
-Args: 生成一张16:9横版文章配图，提示词：{构建的提示词}。下载到 知识/金鹏/{YYYYMMDD}/{YYYYMMDD}-{NNN}.png
-```
-
-#### 7c. 确认大图与占位一致
-
-下载完成后确认：
- 图片本地路径与摘要中 `![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)` 占位一致
- 日期与文章日期匹配
- 父条目配图用 `-001`，子文章按序编号
-
-#### 7d. 生成列表标题图（160×90）
-
-从大图裁切生成 160×90 像素的**列表标题图**，用于在文章列表中展示。
-
-```bash
-convert "<大图路径>" -resize 160x90^ -gravity center -extent 160x90 "<同目录>/<YYYYMMDD>-<NNN>-thumb.png"
-```
-
-参数说明：
- `-resize 160x90^`：按 160×90 等比缩放，`^` 确保填满目标尺寸
- `-gravity center -extent 160x90`：居中裁切到精确 160×90
- 输出文件命名：大图 `YYYYMMDD-NNN.png` → 缩略图 `YYYYMMDD-NNN-thumb.png`
-
-确认 `convert`（ImageMagick）可用；若不可用则改用 `ffmpeg`：
-
-```bash
-ffmpeg -i "<大图路径>" -vf "scale=160:90:force_original_aspect_ratio=increase,crop=160:90" "<缩略图路径>" -y
-```
-
-若两者均不可用，回退到 Python Pillow：
-
-```python
-from PIL import Image
-img = Image.open("<大图路径>")
-w, h = img.size
-target = 160/90
-if w/h > target:
-    nw = int(h * target); img = img.crop(((w-nw)//2, 0, (w+nw)//2, h))
-else:
-    nh = int(w / target); img = img.crop((0, (h-nh)//2, w, (h+nh)//2))
-img.resize((160, 90), Image.LANCZOS).save("<缩略图路径>")
-```
-
-### 8. 输出格式
-
-#### 8a. 体系内文章组（有关联的文章，用父条目分组）
-
-```markdown
- [核心命题](首篇文章URL)
- ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png)  ← 列表标题图（160×90）
- ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)           ← 文章题图（16:9 大图，width=1000）
- 金句标签（核心命题的精髓表达，一句话）
-    - 层级标签： [文章标题](子文章URL)
-        - 定位描述——用一句话说明本文在体系中的位置，**粗体**突出关键词
-        - 来源名称
-        - 具体要点一
-        - 具体要点二
-        - **关键洞察或金句（加粗）**
-    - 层级标签： [下一个文章标题](URL)
-        - 来源名称
-        - 定位描述——承上启下，用"这与XX呼应""与XX一样"等词语串联
-        - 具体要点...
-```
-
-**规则**：
- 父条目缩进 0，子文章标题行缩进 4 空格，子文章内容缩进 8 空格
- **层级标签在子文章标题前面**：`层级标签： [文章标题](URL)`，如 `总纲： [驾驭AI：...](url)`、`团队层： [角色分工：...](url)`
- 子文章标题：`动作名词：具体内容`，不超过 20 字
- 来源行只写平台/作者名（如 `腾讯云`、`极客鑫`），**不在此处加层级标签**
- 总纲的定位描述放在来源之前（因为它是全组的总起），其他子文章的定位描述放在来源之后
- 定位描述承上启下，用关联词串联上下文
-
-#### 8b. 独立文章（不属任何体系的工具项目或单篇文章）
-
-```markdown
- [文章标题](URL)
-    - ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png)  ← 列表标题图（160×90）
-    - ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)           ← 文章题图（16:9 大图，width=1000）
-    - 来源名称
-    - 一句话核心摘要
-    - 补充要点
-```
-
-**规则**：
- 缩进 4 空格，不加层级标签
- GitHub 项目：简要说明用途、技术亮点
-
-### 标题命名
-
-| 类型 | 格式 | 示例 |
-|------|------|------|
-| 父条目 | 核心命题，2-6 字 | `驾驭AI` |
-| 体系内子文章 | `动作名词：具体内容`，≤20 字 | `角色分工：gstack 的虚拟工程团队` |
-| 独立文章 | 简洁直白，≤15 字 | `实时数字人` |
-
-### 描述编写
-
-1. **粗体**用于：核心命题、关键洞察、金句、颠覆性结论、范式突破
-2. 每条要点控制在 1-2 行
-3. 忠实原文观点，区分"作者的结论"和"我们的推断"
-4. 子文章定位描述必须说明该文在体系中的位置，并与前文建立**真实的**关联（不为了体系完整而生造联系）
-5. 对"争议"类观点保留对立声音，不一边倒呈现
-
-### 注意事项
-
- **两图顺序固定**：列表标题图（160×90，`-thumb.png`）在前，文章题图（16:9 大图，`.png`，显示宽度 ≤1000px）在后——渲染列表时优先展示小图，展开详情时展示大图
- 列表标题图 160×90 像素，由大图裁切生成（不单独调用即梦），确保两图视觉一致
- 父条目和独立文章均需生成大图 + 列表标题图；体系内子文章不单独生成配图
- 图片日期与文章日期一致，父条目配图用 `-001`，按文章出现顺序递增
- 多个相关链接（GitHub、官网等）用缩进放在描述最后
-
-## 执行后复盘（标准化复盘流程）
-
-每次执行本命令后，必须按以下结构化流程复盘。参照"实验迭代能力"的标准化原则——无论成功还是失败，都固定记录核心变量。
-
-### 1. 记录执行变量
-
-| 变量 | 说明 |
-|------|------|
-| 输入类型 | URL / 本地文件 / 粘贴内容 / GitHub 仓库 |
-| 价值判断 | 高 / 中 / 低，判断依据 |
-| 文章数量 | 单篇 / 多篇关联 / 独立 |
-| 是否形成体系 | 是 / 否，原因 |
-
-### 2. 分析执行过程
-
-分析本次执行过程的优点和缺点：
-
- **优点**：哪些步骤/设计执行顺畅、达到预期效果？
- **缺点**：哪些步骤/设计存在问题或可改进之处？
- **反常识发现**：执行中是否有预期之外的情况？例如预期能形成体系的文章实际关联薄弱，或被判断为低价值的文章实际有意外亮点？
-
-### 3. 评估是否需要更新命令
-
-基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。
-
-### 4. 如需更新，提出建议并由人类确认
-
-如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。
-
-> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。
@@ -1,275 +0,0 @@
---
-name: arno-dl-wx
-description: 批量下载微信公众号文章全文，以发布日期为前缀保存为 Markdown 文件到 `资料/文章/` 目录，逐篇自动调用 `arno-anl-article` 生成批判性分析报告，最后验证内容完整性。在工作管理项目中，可用于收集行业动态、技术文章、政策法规等公众号文章作为参考材料。触发词：下载公众号文章、批量获取微信公众号、微信文章下载、公众号全文保存、wx批量下载、行业文章下载、公众号归档。
-argument-hint: <链接列表>
---
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-用户输入为一批微信公众号文章链接（每行一个或多个），以及可选的目标保存目录。若未指定目标目录，默认保存到 `资料/文章/` 目录。
-
-链接格式：`https://mp.weixin.qq.com/s/<文章ID>`
-
-## 概述
-
-批量获取微信公众号文章全文内容，以主智能体-子智能体协作模式，依次逐个下载每篇文章，保存为 `yyyy-MM-dd_文章标题.md` 格式的 Markdown 文件（以文章发布日期为前缀），最后验证全部内容的完整性和章节连贯性。
-
-## 标准输出模板
-
-每篇保存的文章 MUST 遵循以下统一格式：
-
-```markdown
-# <文章标题>
-
-> **来源**：<公众号名称>  
-> **作者**：<作者名>  
-> **发布日期**：<yyyy-MM-dd>  
-> **原文链接**：<URL>
-
---
-
-<文章正文内容，保留原始 Markdown 格式>
-```
-
-### 模板字段说明
-
-| 字段 | 提取来源 | 缺省值 |
-|------|----------|--------|
-| `文章标题` | 文章正文最大号文字或首行加粗文字 | 无（必填） |
-| `公众号名称` | web-reader 返回的 `og:site_name` 或文章顶部公众号名称 | `微信公众平台` |
-| `作者名` | web-reader 返回的 `author` / `og:article:author` 元数据，或文章开头署名 | `未知` |
-| `发布日期` | 页面 `create_time` 时间戳转换，或文章顶部日期标注 | 当前日期 |
-| `原文链接` | 用户提供的链接 | 无（必填） |
-| `文章正文` | web-reader 返回的正文内容，保留原始段落、标题、加粗、列表等格式 | — |
-
-### 模板规则
-
-1. 元数据块使用 `>` 块引用格式，字段间用两个空格 `  ` 换行（Markdown 软换行）
-2. 元数据与正文之间用 `---` 分隔线隔开
-3. 正文保留原始 Markdown 格式不变
-4. 正文中如有图片链接（`![Image]` 格式），保留不删除
-
-## 适用场景
-
- 批量下载系列连载文章（如书籍章节、课程讲义）
- 保存微信公众号专栏的全部文章
- 归档公众号内容以供离线阅读或二次处理
- **家庭管理场景**：收集家庭教育方法、健康养生知识、理财技巧、家庭关系建设等公众号文章，作为家庭参考资料的积累
-
-## 架构模式
-
-采用 **主智能体 → 子智能体串行调度** 模式：
-
-```
-主智能体（协调者）
-  ├─ 子智能体 #1 → 获取文章 1 → 保存 → 关闭
-  │     └─ 主智能体 → 调用 arno-anl-article 分析文章 1
-  ├─ 子智能体 #2 → 获取文章 2 → 保存 → 关闭
-  │     └─ 主智能体 → 调用 arno-anl-article 分析文章 2
-  ├─ ...
-  └─ 子智能体 #N → 获取文章 N → 保存 → 关闭
-        └─ 主智能体 → 调用 arno-anl-article 分析文章 N
-            │
-            └─ 主智能体验证全部文章完整性
-```
-
-### 为什么串行而非并行
-
-1. 微信公众号有反爬机制，并发请求容易触发限流
-2. 子智能体之间无共享状态依赖，但需要确保编号连续不混乱
-3. 串行执行方便追踪进度、定位问题
-
-## 执行流程
-
-### 第一步：初始化
-
-1. 解析用户提供的链接列表，确认总链接数 N
-2. 确认目标目录存在，不存在则创建
-3. 告知用户共 N 篇文章待下载
-
-```bash
-mkdir -p "<目标目录>"
-```
-
-### 第二步：串行调度子智能体
-
-对每个链接依次执行：
-
-**启动子智能体**，传入以下任务指令：
-
-```text
-你的任务是获取以下微信公众号文章的完整内容并保存。
-
-**链接**: `<文章URL>`
-**序号**: <当前序号>/<总文章数N>
-**目标目录**: `<目标目录>`
-
-**执行步骤**:
-
-1. 使用 mcp__web-reader__webReader 工具获取该链接的完整文章内容。
-   - 微信公众号文章 WebFetch 通常无法访问，直接使用 web-reader。
-   - 如果内容被截断，尝试调整参数或分段获取。
-
-2. 从获取的内容中提取文章元数据：
-   - **标题**：文章中最大号的文字或第一行加粗文字
-   - **发布日期**：优先从页面 HTML 中的 `create_time` Unix 时间戳转换（`date -d @<timestamp> '+%Y-%m-%d'`），其次从文章顶部日期标注提取；如都无法获取，使用当前日期
-   - **公众号名称**：从 `og:site_name` 元数据或文章顶部公众号名称提取，缺省为 `微信公众平台`
-   - **作者名**：从 `author` / `og:article:author` 元数据或文章开头署名提取，缺省为 `未知`
-
-3. 将完整文章内容按照**标准输出模板**保存为 Markdown 文件：
-   - 文件名格式：`yyyy-MM-dd_文章标题.md`（日期为该文章发布日期）
-   - 文件名中空格和特殊字符（包括中文标点如 `，。！？；：""''、【】《》—…、` 及英文标点 `/ \ : * ? " < > |`）全部替换为 `_`
-   - 多个连续 `_` 合并为一个，末尾 `_` 去除
-   - 保存路径：`<目标目录>/yyyy-MM-dd_文章标题.md`
-   - **严格遵循标准输出模板**：
-     ```
-     # <文章标题>
-
-     > **来源**：<公众号名称>  
-     > **作者**：<作者名>  
-     > **发布日期**：<yyyy-MM-dd>  
-     > **原文链接**：<文章URL>
-
-     ---
-
-     <文章正文内容>
-     ```
-   - 元数据块使用 `>` 块引用，字段间用两个空格换行
-   - 元数据与正文之间用 `---` 分隔线隔开
-   - 正文保留原始格式（段落、标题层级、加粗、列表等），图片链接保留不删除
-
-4. 检查保存的文件内容字数，与原文内容字数进行比对。
-   - 使用 `wc -c` 或字符计数工具
-   - 差异应在 1% 以内（允许 Markdown 格式化标记带来的微小差异）
-   - 如果差异过大，说明内容可能被截断，需重新获取
-
-5. 完成后向主智能体报告：
-   - 文章标题、作者、公众号、发布日期
-   - 保存的文件名
-   - 原文字数 vs 保存字数
-   - 是否完整获取
-```
-
-**关键约束**：
- **每次只启动 1 个子智能体**，等待其完成后才启动下一个
- 子智能体使用 `general-purpose` 类型
- 子智能体完成后自动关闭，不保留上下文
-
-### 第三步：逐篇分析
-
-每篇文章下载完成后（子智能体报告后），**立即**调用 `arno-anl-article` 技能对该文章进行批判性分析：
-
-```bash
-# 使用 Skill 工具调用
-Skill: arno-anl-article
-Args: <目标目录>/<刚下载的文章文件名>.md
-```
-
-**分析产物**：
- 分析报告保存为 `<文章文件名（不含.md）>_分析.md`，与原文在同一目录
- 分析报告是独立文件，**不修改、不覆盖**原文
-
-**关键约束**：
- **分析必须在下一篇下载之前完成**，保持串行节奏
- 分析报告字数应与原文篇幅匹配（长文深度分析，短文简要分析）
- 分析报告文件名中的特殊字符与原文使用相同的 `_` 替换规则
-
-### 第四步：验证全部文章
-
-所有 N 篇文章下载并分析完成后，执行完整性检查：
-
-1. **文件清单检查**：确认目录下有 N 个文件，数量正确无缺漏
-
-```bash
-ls -1 "<目标目录>"/*.md
-```
-
-2. **文件大小检查**：确认每个文件非空，大小合理（微信公众号文章通常 3,000～15,000 字符）
-
-```bash
-wc -c "<目标目录>"/*.md
-```
-
-3. **首尾内容检查**：读取每篇文章的开头和结尾，验证：
-   - 文章有明确的标题
-   - 文章有自然的结尾（不是被截断的半句话）
-   - 如果文章是系列连载，检查相邻文章的章节衔接是否连贯
-
-```bash
-for f in "<目标目录>"/*.md; do
-  echo "=== $(basename "$f") ==="
-  head -2 "$f"
-  echo "..."
-  tail -3 "$f"
-  echo ""
-done
-```
-
-4. **连贯性检查**（可选，适用于系列连载）：
-   - 前一章的结尾是否自然引出下一章
-   - 章节编号是否连续（第1章 → 第2章 → …）
-   - 是否有内容重复或遗漏
-
-### 第五步：修复遗漏（如有）
-
-如果验证发现以下问题：
-
-| 问题类型 | 处理方式 |
-|----------|----------|
-| 文件缺失（某文件不存在） | 重新分配子智能体下载该链接 |
-| 内容截断（字数明显偏少） | 重新分配子智能体下载该链接 |
-| 内容异常（乱码、空内容） | 尝试不同工具重新获取 |
-| 日期错误（文件名日期与实际不符） | 调整文件名中的日期 |
-
-**原则**：不手动修复内容，只重新下载。
-
-### 第六步：输出汇总
-
-```markdown
-## 下载完成
-
- 目标目录: <目录路径>
- 文章总数: N 篇
- 总大小: XXXX 字节
- 完整率: N/N (100%)
-
-| 序号 | 发布日期 | 文章标题 | 字符数 | 下载 | 分析 |
-|------|----------|----------|--------|------|------|
-| 1 | 2026-06-29 | XXX | X,XXX | ✅ | ✅ |
-| 2 | 2026-06-29 | XXX | X,XXX | ✅ | ✅ |
-| ... | ... | ... | ... | ... | ... |
-```
-
-## 关键指令
-
-1. **串行调度**：每次只运行 1 个子智能体，等待完成后再启动下一个
-2. **使用 web-reader**：微信公众号文章 WebFetch 通常无法访问，直接使用 `mcp__web-reader__webReader`
-3. **日期命名**：文件名以文章发布日期 `yyyy-MM-dd` 为前缀，后接下划线 + 文章标题
-4. **文件名安全**：空格和特殊字符（中英文标点如 `，。！？；：""''、【】《》—…、` 及 `/ \ : * ? " < > |`）全部替换为 `_`，多个连续 `_` 合并为一个
-5. **标准模板**：每篇文章 MUST 严格遵循标准输出模板，含来源、作者、发布日期、原文链接四个元数据字段
-6. **字数比对**：每个子智能体必须比对原文字数与保存字数，发现差异 >1% 需重试
-7. **不修改原文**：保存时只添加模板元数据头部（标题、元数据块、分隔线），不改动正文内容
-8. **逐篇分析**：每篇下载完成后立即调用 `arno-anl-article` 生成独立分析报告，分析完成后才启动下一篇下载
-9. **验证优先**：全部下载和分析完成后必须执行第四步验证，不可跳过
-10. **遇错重下**：发现问题不手动修复，重新分配子智能体下载
-
-## 已知陷阱
-
- **WebFetch 不可用**：`WebFetch` 工具对 `mp.weixin.qq.com` 域名通常返回错误或被屏蔽内容，**必须使用 `mcp__web-reader__webReader`** 替代
- **内容截断**：极长文章（>15,000 字符）可能被 web-reader 截断，如遇此情况可尝试调整 `return_format` 或 `content_size` 参数
- **反爬限流**：短时间内大量请求可能触发微信反爬，串行执行天然规避此问题；若单篇文章也失败，等待 5-10 秒后重试
- **标题特殊字符**：文章标题可能含 `/`（如"无代码/低代码"）及各种中英文标点，文件名中必须替换为 `_`
- **URL 有效期**：微信公众号文章链接通常长期有效，但部分文章可能被删除或转为仅关注可见
- **图片丢失**：web-reader 返回的 Markdown 可能不含文章中的图片，如需保留图片需另行处理
-
-## 与项目现有工具的配合
-
-本技能聚焦于微信公众号文章的获取和归档。获取完成后，可配合以下项目技能进一步处理：
-
-| 后续操作 | 使用技能 |
-|----------|----------|
-| 文章批判性分析 | `arno-anl-article`（下载后自动调用） |
@@ -1,135 +0,0 @@
---
-name: Docker清理
-description: 清理 Docker 镜像构建临时文件和悬空资源
---
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-执行前**必须**处理用户输入（非空时）
-
-## 参数说明
-
-支持以下参数（可组合使用）：
-
- `cache` - 仅清理构建缓存
- `images` - 仅清理悬空镜像
- `volumes` - 仅清理未使用的卷
- `containers` - 额外清理已停止的容器
- `all` - 清理默认项目（构建缓存、悬空镜像、未使用的卷）
- `detail` 或 `详细` - 显示详细清理过程
-
-## 输出
-
-### 格式要求
-
-按以下格式输出清理结果：
-
-```markdown
-## Docker 清理报告
-
-### 清理前状态
-
-| 类型 | 总量 | 活跃 | 占用空间 | 可回收 |
-|------|------|------|----------|--------|
-| **镜像** | {数量} | {数量} | {大小} | {大小} ({百分比}%) |
-| **容器** | {数量} | {数量} | {大小} | {大小} ({百分比}%) |
-| **本地卷** | {数量} | {数量} | {大小} | {大小} ({百分比}%) |
-| **构建缓存** | {数量} | {数量} | {大小} | {大小} |
-
-### 清理内容
-
-执行以下清理：
-
- **构建缓存**：{清理的缓存大小}
- **悬空镜像**：{删除的镜像数量} 个
- **未使用的卷**：{清理的卷大小}
-
-{如果用户指定了 `containers` 参数，则添加：
- **已停止的容器**：{删除的容器数量} 个
-}
-
-### 清理后状态
-
-| 类型 | 总量 | 活跃 | 占用空间 | 可回收 |
-|------|------|------|----------|--------|
-| **镜像** | {数量} | {数量} | {大小} | {大小} ({百分比}%) |
-| **容器** | {数量} | {数量} | {大小} | {大小} ({百分比}%) |
-| **本地卷** | {数量} | {数量} | {大小} | {大小} ({百分比}%) |
-| **构建缓存** | {数量} | {数量} | {大小} | {大小} |
-
-### 清理总结
-
-**释放空间总计：约 {总大小}**
-
-{根据清理结果给出建议}
-```
-
-### 执行规则
-
-1. **默认行为** - 无参数时，仅清理构建缓存（不清理悬空镜像、未使用的卷、容器）
-2. **选择性清理** - 根据 $ARGUMENTS 中的参数执行对应清理
-3. **容器清理** - 仅当用户明确指定 `containers` 参数时才清理已停止的容器
-4. **详细模式** - 当 $ARGUMENTS 包含 "detail" 或 "详细" 时，显示详细的清理过程
-5. **安全检查** - 清理前先检查 Docker 状态，确认可清理内容
-6. **执行顺序** - 按以下顺序执行：
-   - 检查当前状态（`docker system df`）
-   - 清理构建缓存（`docker builder prune -a -f`）
-   - {如果指定了 `images` 参数} 清理悬空镜像（`docker image prune -f`）
-   - {如果指定了 `volumes` 参数} 清理未使用的卷（`docker volume prune -f`）
-   - {如果指定了 `containers` 参数} 清理已停止的容器（`docker container prune -f`）
-   - 显示清理后状态
-
-### 清理命令参考
-
-```bash
-# 检查磁盘使用情况
-docker system df
-
-# 清理构建缓存（默认执行）
-docker builder prune -a -f
-
-# 清理悬空镜像（需要明确指定）
-docker image prune -f
-
-# 清理未使用的卷（需要明确指定）
-docker volume prune -f
-
-# 清理已停止的容器（需要明确指定）
-docker container prune -f
-
-# 一次性清理所有未使用资源（包括容器，不推荐使用）
-docker system prune -a -f --volumes
-```
-
-### 注意事项
-
- **默认不清理容器**：已停止的容器不会在默认清理中删除，需明确指定 `containers` 参数
- 构建缓存清理后重新构建镜像会需要更多时间
- 删除的镜像和卷无法恢复，请谨慎操作
- 建议定期清理以保持系统整洁
- 显示可回收空间不代表实际释放空间，可能因层共享而不同
-
-## 执行后复盘
-
-每次执行本命令后，必须完成以下步骤：
-
-### 1. 分析执行过程
-
-分析本次执行过程的优点和缺点：
-
- **优点**：哪些步骤/设计执行顺畅、达到预期效果？
- **缺点**：哪些步骤/设计存在问题或可改进之处？
-
-### 2. 评估是否需要更新命令
-
-基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。
-
-### 3. 如需更新，提出建议并由人类确认
-
-如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。
-
-> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。
@@ -1,260 +0,0 @@
---
-name: 即梦AI生成
-description: 使用即梦（Dreamina）CLI 生成图片或视频，支持文生图、图生图、文生视频、图生视频、多图生视频、多模态生视频
-argument-hint: <生成需求描述>
---
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-## 概述
-
-即梦（Dreamina）是字节跳动旗下的 AI 创作平台。`dreamina` CLI 是其命令行入口，允许在任意环境中使用即梦的生成能力。
-
-详细文档：https://bytedance.larkoffice.com/wiki/FWTwwm0bGiishxkKOoScdHR2nsg
-
-## 前置条件
-
-### 安装 CLI
-
-```bash
-curl -fsSL https://jimeng.jianying.com/cli | bash
-```
-
-### 登录
-
-```bash
-dreamina login
-```
-
-若登录出错，可用 `--debug` 重试：
-
-```bash
-dreamina login --debug
-```
-
-登录状态存储于 `~/.dreamina_cli/`，优先复用已有登录状态。
-
-## 核心命令
-
-**关键原则：实际执行前必须先用 `-h` 查看子命令的具体参数**，不同命令支持的模型、比例、时长、分辨率可能不同。
-
-### 1. 查询额度
-
-```bash
-dreamina user_credit
-```
-
-### 2. 文生图（text2image）
-
-```bash
-dreamina text2image -h
-dreamina text2image --prompt "<描述词>" [其他参数]
-```
-
-### 3. 图生图（image2image）
-
-```bash
-dreamina image2image -h
-dreamina image2image --image "<图片路径>" --prompt "<描述词>" [其他参数]
-```
-
-### 4. 文生视频（text2video）
-
-```bash
-dreamina text2video -h
-dreamina text2video --prompt "<描述词>" [其他参数]
-```
-
-### 5. 图生视频（image2video）
-
-```bash
-dreamina image2video -h
-dreamina image2video --image "<图片路径>" [其他参数]
-```
-
-适用场景：基于单张图片生成动态视频（如让静态图动起来）。注意：分辨率继承输入图片比例，不支持 `--ratio` 参数。
-
-### 6. 多图生视频（multiframe2video）
-
-```bash
-dreamina multiframe2video -h
-dreamina multiframe2video --images "<图1>" "<图2>" ... [其他参数]
-```
-
-适用场景：多张图片串联成连贯故事视频（智能多帧流）。不支持模型选择。
-
-### 7. 多模态生视频（multimodal2video）
-
-```bash
-dreamina multimodal2video -h
-dreamina multimodal2video --prompt "<描述词>" [--image "<图>"] [--video "<视频>"] [--audio "<音频>"] [其他参数]
-```
-
-适用场景：旗舰视频模式，支持图片、视频、音频等多模态参考输入。支持 `--ratio` 参数控制输出比例，Pro 版额外支持 1080p。
-
-### 8. 查询异步任务结果（query_result）
-
-```bash
-dreamina query_result --submit_id <任务ID>
-```
-
-### 9. 查看历史任务（list_task）
-
-```bash
-dreamina list_task -h
-dreamina list_task [过滤参数]
-```
-
-## 工作会话（Session）
-
-```bash
-dreamina session -h
-dreamina session list
-dreamina session create "<名称>"
-dreamina session use <ID>
-```
-
-## 标准工作流程
-
-### 步骤 1：确认需求
-
-根据 `$ARGUMENTS` 判断生成类型：
-
-| 用户说 | 对应命令 |
-|--------|---------|
-| "生成一张...图片"、"画一个..." | `text2image` |
-| "把这张图变成...风格"、"基于这张图生成..." | `image2image` |
-| "生成一段...视频"、"做一个...动画" | `text2video` |
-| "让这张图动起来"、"这张图生成视频" | `image2video` |
-| "用这几张图做一个故事视频" | `multiframe2video` |
-| 同时提供图片+视频+音频参考 | `multimodal2video` |
-
-### 步骤 2：查看命令帮助
-
-```bash
-dreamina <子命令> -h
-```
-
-### 步骤 3：检查额度
-
-```bash
-dreamina user_credit
-```
-
-### 步骤 4：提交生成任务
-
- **明确告知用户**即将消耗额度
- **小批量**执行，每次提交少量任务便于审查
- **记录**每次测试的命令、参数、`submit_id`、最终状态
-
-### 步骤 5：轮询结果
-
-```bash
-dreamina query_result --submit_id <ID>
-```
-
- `gen_status` 为 `querying` → 保存 `submit_id`，稍后查询
- `gen_status` 为 `success` → 获取结果
- `gen_status` 为 `fail` → 查看 `fail_reason`，告知用户具体原因
-
-### 步骤 6：下载结果到本地
-
-下载到 `知识/金鹏/20260605/`。
-
-**命名格式**：`yyyyMMdd_00n.<扩展名>`
-
- `yyyyMMdd`：当前日期
- `00n`：图片序号，001, 002, ...
- `<扩展名>`：图片 `.png`，视频 `.mp4`
-
-示例：
- `20260605_001.png`
- `20260605_002.png`
- `20260605_003.mp4`
-
-```bash
-mkdir -p 知识/金鹏/20260605
-curl -o "知识/金鹏/20260605/20260605-001.png" "<image_url>"
-```
-
-### 步骤 7：输出结果
-
-向用户展示：
- 生成的图片/视频本地路径
- 使用的命令和参数
- `submit_id`（便于后续追溯）
-
-## 账户与模型
-
-### 账户信息
-
- **VIP 等级**：maestro（大师级，最高等级）
- 大部分图片模型（3.0/3.1/4.0/4.6/5.0）免费，仅 4.1（2 积分）和 4.5（4 积分）消耗积分
- 生成前用 `dreamina user_credit` 确认余额
-
-### 模型选择规则
-
-本账号为 VIP maestro，**所有生成始终使用最高质量模型**：
-
-| 命令 | 默认模型 | 备选 |
-|------|---------|------|
-| **text2image** / **image2image** | `5.0`（最新 4K，免费） | `4.6` |
-| **text2video** | `seedance2.0_vip`（70 积分） | `seedance2.0fast_vip` |
-| **image2video** / **multimodal2video** | `seedance2.0fast_vip`（55 积分） | `seedance2.0_vip`（追求极致或需 1080p 时） |
-
-关键约束：
- **非 VIP 模型不可用**：`seedance2.0` 排队 33 万+，`seedance2.0fast` 频繁触发并发限制
- 所有模型生成文字时均可能出现拼写错误，海报类需求需后期修图
- 首次使用前通过 `-h` 确认模型列表是否有更新
-
-> 详细模型对比测试数据与场景推荐矩阵见 `.claude/memory/dreamina.md`
-
-## 常见问题
-
-### AIGC 合规确认
-
-返回 `AigcComplianceConfirmationRequired` 时，需先在即梦 Web 端完成合规确认后重试。
-
-### 排队 / 并发限制
-
-通过 `query_result` 持续轮询，或更新 CLI：
-
-```bash
-curl -fsSL https://jimeng.jianying.com/cli | bash
-```
-
-### 日志排查
-
-日志位于 `~/.dreamina_cli/logs/`。
-
-## 注意事项
-
-1. **区分只读和付费操作**：`user_credit`、`query_result`、`list_task`、`-h` 只读；生成命令消耗额度
-2. **异步等待**：图片和视频生成是异步的，提交和查询分开执行
-3. **不同命令参数不通用**：不要假设某命令的模型、比例、时长、分辨率适用于其他命令
-4. **帮助优先**：不确定参数时，始终先用 `-h` 查看
-
-## 执行后复盘
-
-每次执行本命令后，必须完成以下步骤：
-
-### 1. 分析执行过程
-
-分析本次执行过程的优点和缺点：
-
- **优点**：哪些步骤/设计执行顺畅、达到预期效果？
- **缺点**：哪些步骤/设计存在问题或可改进之处？
-
-### 2. 评估是否需要更新命令
-
-基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。
-
-### 3. 如需更新，提出建议并由人类确认
-
-如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。
-
-> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。
@@ -1,181 +0,0 @@
---
-name: 提交代码
-description: 提交全部内容并推送到远程仓库（不检查路径）
---
-
-## 用户输入
-
-```text
-$ARGUMENTS
-```
-
-执行前**必须**处理用户输入（非空时）
-
-## 输出
-
-1. 分析本次需要提交的内容，按照**Git 提交规范**整理提交消息
-
-2. 提交全部内容并推送到远程仓库
-
-3. 使用以下格式输出
-
-```text
-项目根目录： xxx
-工作目录： xxx
-本地分支： xxx
-远程分支： xxx
-远程地址： xxx
-用户输入： $ARGUMENTS
-提交哈希： xxx
-提交时间： yyyy-MM-dd HH:MM:SS
-提交日志：
-
-{git日志}
-```
-
-## Git 提交规范
-
-遵循 Conventional Commits 标准，结合项目特定需求制定以下提交规范：
-
-### 提交消息格式
-
-```
-<类型>(<作用域>): <描述>
-
-[可选正文]
-
-[可选脚注]
-```
-
-### 提交类型
-
-**主要类型：**
- **功能 (`feat`)**: 添加新功能或增强现有功能
- **修复 (`fix`)**: 修复 bug 或错误行为
- **维护 (`chore`)**: 维护性任务（依赖更新、配置修改等）
- **文档 (`docs`)**: 文档更新、README、注释等
- **重构 (`refactor`)**: 代码重构（不改变外部行为）
- **测试 (`test`)**: 添加、修改或修复测试代码
- **格式 (`style`)**: 代码格式化、空白调整等
- **性能 (`perf`)**: 性能优化改进
- **构建 (`build`)**: 构建系统、工具链变更
-
-**扩展类型：**
- **安全 (`sec`)**: 安全相关修复或改进
- **依赖 (`deps`)**: 依赖包更新或添加
- **清理 (`clean`)**: 删除无用代码或文件
- **优化 (`perf`)**: 性能或代码优化改进
- **配置 (`config`)**: 配置文件修改
- **规格 (`spec`)**: speckit 规格文档更新
-
-**特殊类型：**
- **合并 (`merge`)**: 分支合并
- **进行 (`wip`)**: 工作进行中（开发中的临时提交）
- **回滚 (`revert`)**: 回滚之前的提交
- **发布 (`release`)**: 发布版本标签
-
-### 格式要求
-
-**标题行规则：**
- 使用祈使语气（"添加" 而不是 "添加了"）
- 长度不超过 50 个字符
- 类型后使用冒号和空格分隔：`功能: 添加用户认证`
- 可指定作用域：`功能(auth): 添加 JWT 验证`
-
-**正文内容（可选）：**
- 标题与正文之间留空行
- 说明"做什么"和"为什么"，而非"怎么做"
- 每行不超过 72 个字符
- 使用项目符号列出多个改动
-
-**脚注信息（可选）：**
- 标记破坏性变更：`破坏性变更: 详细说明`
- 关联 issue：`关联: #123` 或 `解决: #456`
- 标记不兼容变更：`不兼容: API 接口参数调整`
-
-### 提交示例
-
-#### 基础提交
-```bash
-功能: 添加用户登录功能
-修复: 修复内存泄漏问题
-文档: 更新 API 文档
-维护: 更新依赖版本
-```
-
-#### 带作用域的提交
-```bash
-功能(api): 添加用户认证接口
-功能(ui): 添加登录页面组件
-修复(服务端): 修复数据库连接超时
-测试(集成): 添加端到端测试用例
-```
-
-#### 详细描述的提交
-```bash
-功能: 实现实时消息推送
-
- 添加 WebSocket 连接管理
- 实现消息广播机制
- 添加离线消息存储
- 支持消息确认机制
-
-影响范围：
- 前端消息组件更新
- 服务端路由扩展
- 数据库表结构变更
-
-关联: #89
-```
-
-### Claude Code 提交行为规范
-
-**重要：Git 提交消息格式要求**
-
- **禁止**在提交消息中添加以下内容：
-  - `🤖 Generated with [Claude Code](https://claude.com/claude-code)`
-  - `Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>`
-  - 任何类似的 AI 工具签名或标识
-
- **原因**：保持 Git 提交历史的简洁性和专业性，避免冗余的元数据
-
- **正确示例**：
-  ```
-  文档: 添加用户认证功能
-
-  - 添加 JWT 验证中间件
-  - 实现登录登出接口
-  - 添加权限校验逻辑
-  ```
-
- **错误示例**（不要这样做）：
-  ```
-  文档: 添加用户认证功能
-
-  - 添加 JWT 验证中间件
-
-  🤖 Generated with [Claude Code](https://claude.com/claude-code)
-
-  Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
-  ```
-
-## 执行后复盘
-
-每次执行本命令后，必须完成以下步骤：
-
-### 1. 分析执行过程
-
-分析本次执行过程的优点和缺点：
-
- **优点**：哪些步骤/设计执行顺畅、达到预期效果？
- **缺点**：哪些步骤/设计存在问题或可改进之处？
-
-### 2. 评估是否需要更新命令
-
-基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。
-
-### 3. 如需更新，提出建议并由人类确认
-
-如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。
-
-> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。
@@ -1,70 +0,0 @@
---
-name: arno-util-lark-delegate
-description: 以金鹏身份向 SZIS bot 或 DIT bot 发飞书消息指派任务。目标 bot 侧的 Claude Code 通过 lark-consumer 实时收到并自动执行。当用户要让另一个项目的 CC 干活、跨项目委派、给 szis/dit 下任务时使用。触发词：委派、delegate、让szis、让dit、给szis发、给dit发、跨项目指派。
-argument-hint: '<szis|dit> <任务指令>'
-allowed-tools: Bash
---
-
-# arno-util-lark-delegate
-
-以金鹏（user）身份向 SZIS 或 DIT bot 的 P2P 会话发消息指派任务。目标 bot 侧的 Claude Code（lark-consumer 监听）会实时收到该消息，并自动 send-keys 到对端 CC 输入框执行。
-
-## 用户输入
-
-```
-$ARGUMENTS
-```
-
-格式：`<目标> <任务指令>`，目标取第一个词，仅接受 `szis` 或 `dit`；其余整体作为任务指令文本。
-
-## 执行流程
-
-### 第1步：解析目标与任务
-
- 从 `$ARGUMENTS` 取首词为 `TARGET`（szis|dit），其余为 `TASK`。
- `TARGET` 非 szis/dit 时，提示正确用法并退出，不要猜测发送。
-
-### 第2步：按目标选择 profile 与 chat_id 发送
-
-**向 SZIS bot 指派**（szis profile，金鹏已在 szis 授权 user 身份）：
-
-```bash
-lark-cli --profile szis im +messages-send --as user \
-  --chat-id oc_xxx \
-  --text "<TASK>"
-```
-
-**向 DIT bot 指派**（dit profile，需金鹏已在 dit 授权 user 身份）：
-
-```bash
-lark-cli --profile dit im +messages-send --as user \
-  --chat-id oc_xxx \
-  --text "<TASK>"
-```
-
-### 第3步：输出结果
-
-展示 `ok`、`message_id`、`create_time`；失败时输出完整错误码与信息。
-
-## 关键约束
-
- **必须 `--as user`（金鹏身份）**：目标 bot 的 consumer sender 白名单是金鹏；若用 bot 身份发，sender 是 app，会被对端 consumer 直接过滤，任务不会被执行。
- **profile 与目标一一对应**：向 SZIS 发用 `--profile szis`，向 DIT 发用 `--profile dit`。open_id 与 chat_id 按 app 隔离，跨用会报 `99992361 open_id cross app`。
- **写操作可见性**：发出的消息会真实进入对端项目的 Claude Code 并执行，指令内容需明确、自洽、可独立理解（对端没有本轮上下文）。
-
-## 固定参数
-
-| 目标 | profile | P2P chat_id | 对端 Claude Code |
-|------|---------|-------------|------------------|
-| szis | szis | oc_xxx | arno/szis（tmux ds-ds） |
-| dit | dit | oc_xxx | allmed/dit |
-
-## 示例
-
-```
-# 让 SZIS 整理本周对话捕捉
-/arno-util-lark-delegate szis 整理 01-输入/对话捕捉.md 本周新增条目，归类到对应清单
-
-# 让 DIT 更新项目推进报告
-/arno-util-lark-delegate dit 用 arno-prj-upd 更新项目推进报告与项目推进分析判断
-```
@@ -1,57 +0,0 @@
---
-name: arno-util-lark-inbox
-description: 读取金鹏与飞书 bot 的 P2P 私聊记录。优先展示实时事件流（lark-inbox.ndjson），回退到 API 拉取。通过环境变量 LARK_PROFILE/LARK_INBOX_CHAT_ID/LARK_INBOX_NDJSON_PATH/LARK_BOT_NAME 适配不同项目。当用户需要查看飞书收件箱、检查发给 bot 的消息时使用。触发词：收件箱、inbox、查看消息、bot对话、飞书消息。
-argument-hint: '[条数 默认10]'
-allowed-tools: Bash
---
-
-# arno-util-lark-inbox
-
-读取金鹏 ↔ bot P2P 私聊记录。**优先增量检查**（调用 `lark-inbox-check.sh --text`），有新消息则展示；有历史消息但无新消息时静默结束；ndjson 不存在时回退 API 拉取。增量检查脚本位于 `../tools/lark-inbox-check.sh`（相对 skill 目录），与 SessionStart hook 共用同一脚本、同一时间戳跟踪。
-
-## 环境变量
-
-| 变量 | 说明 | 示例 |
-|------|------|------|
-| `LARK_PROFILE` | lark-cli profile 名 | `szis` / `dit` |
-| `LARK_INBOX_CHAT_ID` | P2P 会话 chat_id | `oc_xxx` |
-| `LARK_INBOX_NDJSON_PATH` | 实时事件日志路径（相对项目根） | `01-输入/lark-inbox.ndjson` |
-| `LARK_BOT_NAME` | bot 显示名称 | `SZIS` / `DIT` |
-
-## 用户输入
-
-```
-$ARGUMENTS
-```
-
-## 执行流程
-
-### 第1步：增量检查（优先）
-
-调用 `lark-inbox-check.sh --text`，按 tmux session 隔离的时间戳做增量检查（同一 tmux 窗口内多次 CC 会话共享时间戳，避免重复展示），只返回上次检查后的新消息（最多5条）。
-
-```bash
-lark-inbox-check.sh --text
-```
-
- **有新消息** → 展示新消息，结束。
- **无新消息** → 检查 ndjson 文件是否存在且非空：
-  - 存在（有历史消息但无新消息）→ **静默结束**，不输出任何内容。
-  - 不存在 → 进入第2步（回退 API 拉取）。
-
-### 第2步：回退 API 拉取（ndjson 不可用时）
-
-```bash
-lark-cli --profile "${LARK_PROFILE}" im +chat-messages-list --as bot \
-  --chat-id "${LARK_INBOX_CHAT_ID}" \
-  --sort desc --page-size ${ARGUMENTS:-10} --json
-```
-
-区分 `sender_type: user`（👤 金鹏）和 `sender_type: app`（🤖 bot）。
-
-## 示例
-
-```
-/arno-util-lark-inbox        # 最近 10 条
-/arno-util-lark-inbox 20     # 最近 20 条
-```
@@ -1,57 +0,0 @@
---
-name: arno-util-lark-me
-description: 飞书 bot 向金鹏私聊发送消息。通过环境变量 LARK_PROFILE/LARK_ME_USER_ID/LARK_BOT_NAME 适配不同项目。当用户需要给自己发飞书提醒、通过 bot 推送通知、快速测试飞书通道时使用。触发词：发给自己、bot消息、飞书提醒、lark-me、自发送。
-argument-hint: '<消息内容>'
-allowed-tools: Bash
---
-
-# arno-util-lark-me
-
-bot → 金鹏 P2P 快捷发送。
-
-## 环境变量
-
-| 变量 | 说明 | 示例 |
-|------|------|------|
-| `LARK_PROFILE` | lark-cli profile 名 | `szis` / `dit` |
-| `LARK_ME_USER_ID` | 金鹏在该应用下的 open_id | `ou_xxx` |
-| `LARK_BOT_NAME` | bot 显示名称 | `SZIS` / `DIT` |
-
-## 用户输入
-
-```
-$ARGUMENTS
-```
-
-## 执行流程
-
-### 第1步：发送消息
-
-```bash
-lark-cli --profile "${LARK_PROFILE}" im +messages-send --as bot \
-  --user-id "${LARK_ME_USER_ID}" \
-  --text "$ARGUMENTS"
-```
-
-### 第2步：输出结果
-
-展示发送状态、message_id、时间。
-
-## 固定参数
-
-| 参数 | 值 |
-|------|-----|
-| 身份 | `--as bot` |
-| Profile | `$LARK_PROFILE` |
-| 目标 | `$LARK_ME_USER_ID`（金鹏） |
-| 类型 | P2P 私聊 |
-
-## 示例
-
-```bash
-# 用户输入: /arno-util-lark-me 别忘了下午3点的会议
-# 等价于:
-lark-cli --profile "${LARK_PROFILE}" im +messages-send --as bot \
-  --user-id "${LARK_ME_USER_ID}" \
-  --text "别忘了下午3点的会议"
-```
@@ -1,34 +0,0 @@
---
-name: arno-util-stop
-description: 任务执行完毕后的收尾流程——发送对话摘要、扫描新产生的承诺/待办/想法/决定并追加到对话捕捉文件。由 CLAUDE.md 强制要求在任务完成前调用，非用户直接触发。触发词：stop、收尾、任务完成、对话捕捉。
-allowed-tools: Bash, Read, Edit, Skill
---
-
-# arno-util-stop
-
-任务执行完毕后的收尾流程。
-
-## 环境变量
-
-| 变量 | 说明 | 示例 |
-|------|------|------|
-| `LARK_PROFILE` | lark-cli profile 名 | `szis` / `dit` |
-| `LARK_ME_USER_ID` | 金鹏在该应用下的 open_id | `ou_xxx` |
-| `LARK_BOT_NAME` | bot 显示名称 | `SZIS` / `DIT` |
-
-## 执行流程
-
-### 第1步：发送对话摘要
-
-通过 `arno-util-lark-me` skill 发出本次对话的简要摘要。
-
-### 第2步：扫描并捕捉新事项
-
-扫描本次对话中新产生的承诺、待办、想法、决定。
-
- **有**：通过 Edit 追加到 `01-输入/对话捕捉.md`，格式：`- YYYY-MM-DD 类型：承诺/待办/想法/决定 内容 — 来源：上下文`，再通过 `arno-util-lark-me` skill 发出。
- **无**：完全静默，不要输出任何文字。
-
-## 关键指令
-
-⚠️ 全程只通过工具操作，不附加任何解释文字。