winter-super-cli 2026.5.32 → 2026.6.5

package/resources/local/ecc/docs/zh-CN/skills/connections-optimizer/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: connections-optimizer
+description: 重新组织用户的X和LinkedIn网络，采用审查优先的修剪策略，提供添加/关注建议，并以用户真实口吻起草针对不同渠道的温和外联。当用户希望清理关注列表、向当前优先事项发展或围绕更高信号的关系重新平衡社交图谱时使用。
+origin: ECC
+---
+
+# 连接优化器
+
+重新组织用户的社交网络，而非将对外联系视为单向的潜在客户列表。
+
+本技能处理：
+
+* X（推特）关注清理与扩展
+* LinkedIn 关注与连接分析
+* 优先审核队列
+* 添加与关注建议
+* 温暖路径识别
+* 以用户真实口吻生成 Apple Mail、X DM 和 LinkedIn 草稿
+
+## 何时激活
+
+* 用户想要清理其 X 关注列表
+* 用户想要重新平衡关注或保持连接的对象
+* 用户说"清理我的网络"、"我应该取消关注谁"、"我应该关注谁"、"我应该与谁重新建立联系"
+* 外联质量取决于网络结构，而不仅仅是生成冷名单
+
+## 必要输入
+
+收集或推断：
+
+* 当前优先事项和活跃工作
+* 目标角色、行业、地区或生态圈
+* 平台选择：X、LinkedIn 或两者
+* 不可触碰名单
+* 模式：`light-pass`、`default` 或 `aggressive`
+
+如果用户未指定模式，则使用 `default`。
+
+## 工具要求
+
+### 首选
+
+* `x-api` 用于 X 图谱检查与近期活动
+* `lead-intelligence` 用于目标发现与温暖路径排序
+* `social-graph-ranker` 当用户希望独立于更广泛的线索流程评估桥梁价值时
+* Exa / 深度研究用于人物与公司信息丰富
+* `brand-voice` 在起草外联内容之前
+
+### 备选
+
+* 浏览器控制用于 LinkedIn 分析与起草
+* 当 API 覆盖受限时，使用浏览器控制处理 X
+* 当电子邮件是合适渠道时，通过桌面自动化起草 Apple Mail 或 Mail.app 邮件
+
+## 安全默认设置
+
+* 默认优先审核，绝不盲目自动清理
+* X：仅清理用户关注的对象，绝不清理粉丝
+* LinkedIn：将一级连接的移除视为手动优先审核
+* 不自动发送私信、邀请或电子邮件
+* 在任何执行步骤之前，输出排序后的行动计划与草稿
+
+## 平台规则
+
+### X
+
+* 互关比单向关注更稳固
+* 未回关者可更积极清理
+* 长期不活跃或已消失的账号应快速浮现
+* 互动、信号质量与桥梁价值比原始粉丝数更重要
+
+### LinkedIn
+
+* 若用户实际拥有 LinkedIn API 访问权限，优先使用 API
+* 当缺少 API 访问权限时，必须使用浏览器工作流程
+* 区分对外关注与已接受的一级连接
+* 对外关注可更自由地清理
+* 已接受的一级连接应默认审核，而非自动移除
+
+## 模式
+
+### `light-pass`
+
+* 仅清理高置信度、低价值的单向关注
+* 其余内容供审核
+* 生成少量添加/关注列表
+
+### `default`
+
+* 平衡的清理队列
+* 平衡的保留列表
+* 排序的添加/关注队列
+* 在有用时起草温暖介绍或直接外联
+
+### `aggressive`
+
+* 更大的清理队列
+* 对过时未回关者的容忍度更低
+* 执行前仍需审核把关
+
+## 评分模型
+
+使用以下正面信号：
+
+* 互惠性
+* 近期活跃度
+* 与当前优先事项的契合度
+* 网络桥梁价值
+* 角色相关性
+* 真实互动历史
+* 近期存在感与响应度
+
+使用以下负面信号：
+
+* 已消失或废弃的账号
+* 过时的单向关注
+* 偏离优先主题的集群
+* 低价值噪音
+* 反复无响应
+* 存在许多更优替代者时仍未回关
+
+互关和真实的温暖路径桥梁应比单向关注受到更宽松的惩罚。
+
+## 工作流程
+
+1. 获取优先事项、不可触碰约束和选定平台。
+2. 拉取当前关注/连接清单。
+3. 对清理候选者进行评分并附上明确理由。
+4. 对保留候选者进行评分并附上明确理由。
+5. 使用 `lead-intelligence` 结合研究信息对扩展候选者进行排序。
+6. 匹配正确渠道：
+   * X DM 用于温暖、快速的社交接触点
+   * LinkedIn 消息用于职业图谱邻近关系
+   * Apple Mail 草稿用于需要更多上下文的介绍或外联
+7. 在起草消息前运行 `brand-voice`。
+8. 在任何执行步骤前返回审核包。
+
+## 审核包格式
+
+```text
+连接优化器报告
+============================
+
+模式：
+平台：
+优先级设置：
+
+修剪队列
+- 账号/个人资料
+  原因：
+  置信度：
+  操作：
+
+审查队列
+- 账号/个人资料
+  原因：
+  风险：
+
+保留/保护
+- 账号/个人资料
+  桥梁价值：
+
+添加/关注目标
+- 联系人
+  当前原因：
+  预热路径：
+  首选渠道：
+
+草稿
+- X 私信：
+- LinkedIn：
+- Apple 邮件：
+```
+
+## 外联规则
+
+* 默认邮件路径是创建 Apple Mail / Mail.app 草稿。
+* 不自动发送。
+* 根据温暖度、相关性和上下文深度选择渠道。
+* 当电子邮件或不进行外联是正确选择时，不要强制发送私信。
+* 草稿应听起来像用户本人，而非自动化的销售文案。
+
+## 相关技能
+
+* `brand-voice` 用于可复用的语音档案
+* `social-graph-ranker` 用于独立的桥梁评分与温暖路径计算
+* `lead-intelligence` 用于加权目标与温暖路径发现
+* `x-api` 用于 X 图谱访问、起草和可选执行流程
+* `content-engine` 当用户还希望围绕网络变动发布公开内容时

package/resources/local/ecc/docs/zh-CN/skills/content-engine/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: content-engine
+description: 为X、LinkedIn、TikTok、YouTube、新闻通讯和跨平台重新利用的多平台活动创建平台原生内容系统。适用于当用户需要社交媒体帖子、帖子串、脚本、内容日历，或一个源资产在多个平台上清晰适配时。
+origin: ECC
+---
+
+# 内容引擎
+
+将一个想法转化为强大的、平台原生的内容，而不是到处发布相同的东西。
+
+## 何时激活
+
+* 撰写 X 帖子或主题串时
+* 起草 LinkedIn 帖子或发布更新时
+* 编写短视频或 YouTube 解说稿时
+* 将文章、播客、演示或文档改写成社交内容时
+* 围绕发布、里程碑或主题制定轻量级内容计划时
+
+## 首要问题
+
+明确：
+
+* 来源素材：我们从什么内容改编
+* 受众：构建者、投资者、客户、运营者，还是普通受众
+* 平台：X、LinkedIn、TikTok、YouTube、新闻简报，还是多平台
+* 目标：品牌认知、转化、招聘、建立权威、支持发布，还是互动参与
+
+## 核心规则
+
+1. 为平台进行适配。不要交叉发布相同的文案。
+2. 开篇钩子比总结更重要。
+3. 每篇帖子应承载一个清晰的想法。
+4. 使用具体细节而非口号。
+5. 保持呼吁行动小而清晰。
+
+## 平台指南
+
+### X
+
+* 开场要快
+* 每个帖子或主题串中的每条推文只讲一个想法
+* 除非必要，避免在主文中放置链接
+* 避免滥用话题标签
+
+### LinkedIn
+
+* 第一行要强有力
+* 使用短段落
+* 围绕经验教训、结果和要点进行更明确的框架构建
+
+### TikTok / 短视频
+
+* 前 3 秒必须抓住注意力
+* 围绕视觉内容编写脚本，而不仅仅是旁白
+* 一个演示、一个主张、一个行动号召
+
+### YouTube
+
+* 尽早展示结果
+* 按章节构建内容
+* 每 20-30 秒刷新一次视觉内容
+
+### 新闻简报
+
+* 提供一个清晰的视角，而不是一堆不相关的内容
+* 使章节标题易于浏览
+* 让开篇段落真正发挥作用
+
+## 内容再利用流程
+
+默认级联：
+
+1. 锚定素材：文章、视频、演示、备忘录或发布文档
+2. 提取 3-7 个原子化想法
+3. 撰写平台原生的变体内容
+4. 修剪不同输出内容中的重复部分
+5. 使行动号召与平台意图保持一致
+
+## 交付物
+
+当被要求进行一项宣传活动时，请返回：
+
+* 核心角度
+* 针对特定平台的草稿
+* 可选的发布顺序
+* 可选的行动号召变体
+* 发布前所需的任何缺失信息
+
+## 质量门槛
+
+在交付前检查：
+
+* 每份草稿读起来都符合其平台原生风格
+* 开篇钩子强大且具体
+* 没有通用的炒作语言
+* 除非特别要求，否则各平台间没有重复文案
+* 行动号召与内容和受众相匹配

package/resources/local/ecc/docs/zh-CN/skills/content-hash-cache-pattern/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: content-hash-cache-pattern
+description: 使用SHA-256内容哈希缓存昂贵的文件处理结果——路径无关、自动失效、服务层分离。
+origin: ECC
+---
+
+# 内容哈希文件缓存模式
+
+使用 SHA-256 内容哈希作为缓存键，缓存昂贵的文件处理结果（PDF 解析、文本提取、图像分析）。与基于路径的缓存不同，此方法在文件移动/重命名后仍然有效，并在内容更改时自动失效。
+
+## 何时激活
+
+* 构建文件处理管道时（PDF、图像、文本提取）
+* 处理成本高且同一文件被重复处理时
+* 需要一个 `--cache/--no-cache` CLI 选项时
+* 希望在不修改现有纯函数的情况下为其添加缓存时
+
+## 核心模式
+
+### 1. 基于内容哈希的缓存键
+
+使用文件内容（而非路径）作为缓存键：
+
+```python
+import hashlib
+from pathlib import Path
+
+_HASH_CHUNK_SIZE = 65536  # 64KB chunks for large files
+
+def compute_file_hash(path: Path) -> str:
+    """SHA-256 of file contents (chunked for large files)."""
+    if not path.is_file():
+        raise FileNotFoundError(f"File not found: {path}")
+    sha256 = hashlib.sha256()
+    with open(path, "rb") as f:
+        while True:
+            chunk = f.read(_HASH_CHUNK_SIZE)
+            if not chunk:
+                break
+            sha256.update(chunk)
+    return sha256.hexdigest()
+```
+
+**为什么使用内容哈希？** 文件重命名/移动 = 缓存命中。内容更改 = 自动失效。无需索引文件。
+
+### 2. 用于缓存条目的冻结数据类
+
+```python
+from dataclasses import dataclass
+
+@dataclass(frozen=True, slots=True)
+class CacheEntry:
+    file_hash: str
+    source_path: str
+    document: ExtractedDocument  # The cached result
+```
+
+### 3. 基于文件的缓存存储
+
+每个缓存条目都存储为 `{hash}.json` —— 通过哈希实现 O(1) 查找，无需索引文件。
+
+```python
+import json
+from typing import Any
+
+def write_cache(cache_dir: Path, entry: CacheEntry) -> None:
+    cache_dir.mkdir(parents=True, exist_ok=True)
+    cache_file = cache_dir / f"{entry.file_hash}.json"
+    data = serialize_entry(entry)
+    cache_file.write_text(json.dumps(data, ensure_ascii=False), encoding="utf-8")
+
+def read_cache(cache_dir: Path, file_hash: str) -> CacheEntry | None:
+    cache_file = cache_dir / f"{file_hash}.json"
+    if not cache_file.is_file():
+        return None
+    try:
+        raw = cache_file.read_text(encoding="utf-8")
+        data = json.loads(raw)
+        return deserialize_entry(data)
+    except (json.JSONDecodeError, ValueError, KeyError):
+        return None  # Treat corruption as cache miss
+```
+
+### 4. 服务层包装器（单一职责原则）
+
+保持处理函数的纯净性。将缓存作为一个单独的服务层添加。
+
+```python
+def extract_with_cache(
+    file_path: Path,
+    *,
+    cache_enabled: bool = True,
+    cache_dir: Path = Path(".cache"),
+) -> ExtractedDocument:
+    """Service layer: cache check -> extraction -> cache write."""
+    if not cache_enabled:
+        return extract_text(file_path)  # Pure function, no cache knowledge
+
+    file_hash = compute_file_hash(file_path)
+
+    # Check cache
+    cached = read_cache(cache_dir, file_hash)
+    if cached is not None:
+        logger.info("Cache hit: %s (hash=%s)", file_path.name, file_hash[:12])
+        return cached.document
+
+    # Cache miss -> extract -> store
+    logger.info("Cache miss: %s (hash=%s)", file_path.name, file_hash[:12])
+    doc = extract_text(file_path)
+    entry = CacheEntry(file_hash=file_hash, source_path=str(file_path), document=doc)
+    write_cache(cache_dir, entry)
+    return doc
+```
+
+## 关键设计决策
+
+| 决策 | 理由 |
+|----------|-----------|
+| SHA-256 内容哈希 | 与路径无关，内容更改时自动失效 |
+| `{hash}.json` 文件命名 | O(1) 查找，无需索引文件 |
+| 服务层包装器 | 单一职责原则：提取功能保持纯净，缓存是独立的关注点 |
+| 手动 JSON 序列化 | 完全控制冻结数据类的序列化 |
+| 损坏时返回 `None` | 优雅降级，在下次运行时重新处理 |
+| `cache_dir.mkdir(parents=True)` | 在首次写入时惰性创建目录 |
+
+## 最佳实践
+
+* **哈希内容，而非路径** —— 路径会变，内容标识不变
+* 对大文件进行哈希时**分块处理** —— 避免将整个文件加载到内存中
+* **保持处理函数的纯净性** —— 它们不应了解任何关于缓存的信息
+* **记录缓存命中/未命中**，并使用截断的哈希值以便调试
+* **优雅地处理损坏** —— 将无效的缓存条目视为未命中，永不崩溃
+
+## 应避免的反模式
+
+```python
+# BAD: Path-based caching (breaks on file move/rename)
+cache = {"/path/to/file.pdf": result}
+
+# BAD: Adding cache logic inside the processing function (SRP violation)
+def extract_text(path, *, cache_enabled=False, cache_dir=None):
+    if cache_enabled:  # Now this function has two responsibilities
+        ...
+
+# BAD: Using dataclasses.asdict() with nested frozen dataclasses
+# (can cause issues with complex nested types)
+data = dataclasses.asdict(entry)  # Use manual serialization instead
+```
+
+## 适用场景
+
+* 文件处理管道（PDF 解析、OCR、文本提取、图像分析）
+* 受益于 `--cache/--no-cache` 选项的 CLI 工具
+* 跨多次运行出现相同文件的批处理
+* 在不修改现有纯函数的情况下为其添加缓存
+
+## 不适用场景
+
+* 必须始终保持最新的数据（实时数据流）
+* 缓存条目可能极其庞大的情况（应考虑使用流式处理）
+* 结果依赖于文件内容之外参数的情况（例如，不同的提取配置）

package/resources/local/ecc/docs/zh-CN/skills/context-budget/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: context-budget
+description: 审核Claude Code上下文窗口在代理、技能、MCP服务器和规则中的消耗情况。识别膨胀、冗余组件，并提供优先的令牌节省建议。
+origin: ECC
+---
+
+# 上下文预算
+
+分析 Claude Code 会话中每个已加载组件的令牌开销，并提供可操作的优化建议以回收上下文空间。
+
+## 使用时机
+
+* 会话性能感觉迟缓或输出质量下降
+* 你最近添加了许多技能、代理或 MCP 服务器
+* 你想知道实际有多少上下文余量
+* 计划添加更多组件，需要知道是否有空间
+* 运行 `/context-budget` 命令（本技能为其提供支持）
+
+## 工作原理
+
+### 阶段 1：清单
+
+扫描所有组件目录并估算令牌消耗：
+
+**代理** (`agents/*.md`)
+
+* 统计每个文件的行数和令牌数（单词数 × 1.3）
+* 提取 `description` 前言长度
+* 标记：文件 >200 行（繁重），描述 >30 词（臃肿的前言）
+
+**技能** (`skills/*/SKILL.md`)
+
+* 统计 SKILL.md 的令牌数
+* 标记：文件 >400 行
+* 检查 `.agents/skills/` 中的重复副本 — 跳过相同副本以避免重复计数
+
+**规则** (`rules/**/*.md`)
+
+* 统计每个文件的令牌数
+* 标记：文件 >100 行
+* 检测同一语言模块中规则文件之间的内容重叠
+
+**MCP 服务器** (`.mcp.json` 或活动的 MCP 配置)
+
+* 统计配置的服务器数量和工具总数
+* 估算模式开销约为每个工具 500 令牌
+* 标记：工具数 >20 的服务器，包装简单 CLI 命令的服务器 (`gh`, `git`, `npm`, `supabase`, `vercel`)
+
+**CLAUDE.md**（项目级 + 用户级）
+
+* 统计 CLAUDE.md 链中每个文件的令牌数
+* 标记：合并总数 >300 行
+
+### 阶段 2：分类
+
+将每个组件归入一个类别：
+
+| 类别 | 标准 | 操作 |
+|--------|----------|--------|
+| **始终需要** | 在 CLAUDE.md 中被引用，支持活动命令，或匹配当前项目类型 | 保留 |
+| **有时需要** | 特定领域（例如语言模式），未在 CLAUDE.md 中引用 | 考虑按需激活 |
+| **很少需要** | 无命令引用，内容重叠，或无明显的项目匹配 | 移除或延迟加载 |
+
+### 阶段 3：检测问题
+
+识别以下问题模式：
+
+* **臃肿的代理描述** — 前言中描述 >30 词，会在每次任务工具调用时加载
+* **繁重的代理** — 文件 >200 行，每次生成时都会增加任务工具的上下文
+* **冗余组件** — 重复代理逻辑的技能，重复 CLAUDE.md 的规则
+* **MCP 超额订阅** — >10 个服务器，或包装了可免费使用的 CLI 工具的服务器
+* **CLAUDE.md 臃肿** — 冗长的解释、过时的部分、本应成为规则的指令
+
+### 阶段 4：报告
+
+生成上下文预算报告：
+
+```
+上下文预算报告
+═══════════════════════════════════════
+
+总预估开销：约 XX,XXX 个词元
+上下文模型：Claude Sonnet (200K 窗口)
+有效可用上下文：约 XXX,XXX 个词元 (XX%)
+
+组件细分：
+┌─────────────────┬────────┬───────────┐
+│ 组件            │ 数量   │ 词元数    │
+├─────────────────┼────────┼───────────┤
+│ Agents          │ N      │ ~X,XXX    │
+│ Skills          │ N      │ ~X,XXX    │
+│ Rules           │ N      │ ~X,XXX    │
+│ MCP tools       │ N      │ ~XX,XXX   │
+│ CLAUDE.md       │ N      │ ~X,XXX    │
+└─────────────────┴────────┴───────────┘
+
+WARNING: 发现的问题 (N)：
+[按可节省词元数排序]
+
+前 3 项优化建议：
+1. [action] → 节省约 X,XXX 个词元
+2. [action] → 节省约 X,XXX 个词元
+3. [action] → 节省约 X,XXX 个词元
+
+潜在节省空间：约 XX,XXX 个词元 (占当前开销的 XX%)
+```
+
+在详细模式下，额外输出每个文件的令牌计数、最繁重文件的行级细分、重叠组件之间的具体冗余行，以及 MCP 工具列表和每个工具模式大小的估算。
+
+## 示例
+
+**基本审计**
+
+```
+/context-budget
+技能：扫描设置 → 16个代理（12,400个令牌），28个技能（6,200），87个MCP工具（43,500），2个CLAUDE.md（1,200）
+       标记：3个重型代理，14个MCP服务器（3个可替换为CLI）
+       最高节省：移除3个MCP服务器 → -27,500个令牌（减少47%开销）
+```
+
+**详细模式**
+
+```
+/context-budget --verbose
+技能：完整报告 + 按文件细目显示 planner.md（213 行，1,840 个令牌），
+       MCP 工具列表及每个工具的大小，重复规则行并排显示
+```
+
+**扩容前检查**
+
+```
+User: 我想再添加5个MCP服务器，有空间吗？
+Skill: 当前开销33% → 添加5个服务器（约50个工具）会增加约25,000个tokens → 开销将升至45%
+       建议：先移除2个可用CLI替代的服务器以保持在40%以下
+```
+
+## 最佳实践
+
+* **令牌估算**：对散文使用 `words × 1.3`，对代码密集型文件使用 `chars / 4`
+* **MCP 是最大的杠杆**：每个工具模式约消耗 500 令牌；一个 30 个工具的服务器开销超过你所有技能的总和
+* **代理描述始终加载**：即使代理从未被调用，其描述字段也存在于每个任务工具上下文中
+* **详细模式用于调试**：需要精确定位导致开销的确切文件时使用，而非用于常规审计
+* **变更后审计**：添加任何代理、技能或 MCP 服务器后运行，以便及早发现增量

package/resources/local/ecc/docs/zh-CN/skills/continuous-agent-loop/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: continuous-agent-loop
+description: 具有质量门、评估和恢复控制的连续自主代理循环模式。
+origin: ECC
+---
+
+# 持续代理循环
+
+这是 v1.8+ 的规范循环技能名称。它在保持一个发布版本的兼容性的同时，取代了 `autonomous-loops`。
+
+## 循环选择流程
+
+```text
+Start
+  |
+  +-- 需要严格的 CI/PR 控制？ -- yes --> continuous-pr
+  |
+  +-- 需要 RFC 分解？ -- yes --> rfc-dag
+  |
+  +-- 需要探索性并行生成？ -- yes --> infinite
+  |
+  +-- default --> sequential
+```
+
+## 组合模式
+
+推荐的生产栈：
+
+1. RFC 分解 (`ralphinho-rfc-pipeline`)
+2. 质量门 (`plankton-code-quality` + `/quality-gate`)
+3. 评估循环 (`eval-harness`)
+4. 会话持久化 (`nanoclaw-repl`)
+
+## 故障模式
+
+* 循环空转，没有可衡量的进展
+* 因相同根本原因而重复重试
+* 合并队列停滞
+* 无限制升级导致的成本漂移
+
+## 恢复
+
+* 冻结循环
+* 运行 `/harness-audit`
+* 将范围缩小到失败单元
+* 使用明确的验收标准重放