winter-super-cli 2026.5.32 → 2026.6.5

package/resources/local/ecc/docs/zh-CN/skills/ralphinho-rfc-pipeline/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: ralphinho-rfc-pipeline
+description: 基于RFC驱动的多智能体DAG执行模式，包含质量门、合并队列和工作单元编排。
+origin: ECC
+---
+
+# Ralphinho RFC 管道
+
+灵感来源于 [humanplane](https://github.com/humanplane) 风格的 RFC 分解模式和多单元编排工作流。
+
+当一个功能对于单次代理处理来说过于庞大，必须拆分为独立可验证的工作单元时，请使用此技能。
+
+## 管道阶段
+
+1. RFC 接收
+2. DAG 分解
+3. 单元分配
+4. 单元实现
+5. 单元验证
+6. 合并队列与集成
+7. 最终系统验证
+
+## 单元规范模板
+
+每个工作单元应包含：
+
+* `id`
+* `depends_on`
+* `scope`
+* `acceptance_tests`
+* `risk_level`
+* `rollback_plan`
+
+## 复杂度层级
+
+* 层级 1：独立文件编辑，确定性测试
+* 层级 2：多文件行为变更，中等集成风险
+* 层级 3：架构/认证/性能/安全性变更
+
+## 每个单元的质量管道
+
+1. 研究
+2. 实现计划
+3. 实现
+4. 测试
+5. 审查
+6. 合并就绪报告
+
+## 合并队列规则
+
+* 永不合并存在未解决依赖项失败的单元。
+* 始终将单元分支变基到最新的集成分支上。
+* 每次队列合并后重新运行集成测试。
+
+## 恢复
+
+如果一个单元停滞：
+
+* 从活动队列中移除
+* 快照发现结果
+* 重新生成范围缩小的单元
+* 使用更新的约束条件重试
+
+## 输出
+
+* RFC 执行日志
+* 单元记分卡
+* 依赖关系图快照
+* 集成风险摘要

package/resources/local/ecc/docs/zh-CN/skills/regex-vs-llm-structured-text/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: regex-vs-llm-structured-text
+description: 选择在解析结构化文本时使用正则表达式还是大型语言模型的决策框架——从正则表达式开始，仅在低置信度的边缘情况下添加大型语言模型。
+origin: ECC
+---
+
+# 正则表达式 vs LLM 用于结构化文本解析
+
+一个用于解析结构化文本（测验、表单、发票、文档）的实用决策框架。核心见解是：正则表达式能以低成本、确定性的方式处理 95-98% 的情况。将昂贵的 LLM 调用留给剩余的边缘情况。
+
+## 何时使用
+
+* 解析具有重复模式的结构化文本（问题、表单、表格）
+* 决定在文本提取时使用正则表达式还是 LLM
+* 构建结合两种方法的混合管道
+* 在文本处理中优化成本/准确性权衡
+
+## 决策框架
+
+```
+文本格式是否一致且重复？
+├── 是 (>90% 遵循某种模式) → 从正则表达式开始
+│   ├── 正则表达式处理 95%+ → 完成，无需 LLM
+│   └── 正则表达式处理 <95% → 仅为边缘情况添加 LLM
+└── 否 (自由格式，高度可变) → 直接使用 LLM
+```
+
+## 架构模式
+
+```
+[正则表达式解析器] ─── 提取结构（95-98% 准确率）
+    │
+    ▼
+[文本清理器] ─── 去除噪声（标记、页码、伪影）
+    │
+    ▼
+[置信度评分器] ─── 标记低置信度提取项
+    │
+    ├── 高置信度（≥0.95）→ 直接输出
+    │
+    └── 低置信度（<0.95）→ [LLM 验证器] → 输出
+```
+
+## 实现
+
+### 1. 正则表达式解析器（处理大多数情况）
+
+```python
+import re
+from dataclasses import dataclass
+
+@dataclass(frozen=True)
+class ParsedItem:
+    id: str
+    text: str
+    choices: tuple[str, ...]
+    answer: str
+    confidence: float = 1.0
+
+def parse_structured_text(content: str) -> list[ParsedItem]:
+    """Parse structured text using regex patterns."""
+    pattern = re.compile(
+        r"(?P<id>\d+)\.\s*(?P<text>.+?)\n"
+        r"(?P<choices>(?:[A-D]\..+?\n)+)"
+        r"Answer:\s*(?P<answer>[A-D])",
+        re.MULTILINE | re.DOTALL,
+    )
+    items = []
+    for match in pattern.finditer(content):
+        choices = tuple(
+            c.strip() for c in re.findall(r"[A-D]\.\s*(.+)", match.group("choices"))
+        )
+        items.append(ParsedItem(
+            id=match.group("id"),
+            text=match.group("text").strip(),
+            choices=choices,
+            answer=match.group("answer"),
+        ))
+    return items
+```
+
+### 2. 置信度评分
+
+标记可能需要 LLM 审核的项：
+
+```python
+@dataclass(frozen=True)
+class ConfidenceFlag:
+    item_id: str
+    score: float
+    reasons: tuple[str, ...]
+
+def score_confidence(item: ParsedItem) -> ConfidenceFlag:
+    """Score extraction confidence and flag issues."""
+    reasons = []
+    score = 1.0
+
+    if len(item.choices) < 3:
+        reasons.append("few_choices")
+        score -= 0.3
+
+    if not item.answer:
+        reasons.append("missing_answer")
+        score -= 0.5
+
+    if len(item.text) < 10:
+        reasons.append("short_text")
+        score -= 0.2
+
+    return ConfidenceFlag(
+        item_id=item.id,
+        score=max(0.0, score),
+        reasons=tuple(reasons),
+    )
+
+def identify_low_confidence(
+    items: list[ParsedItem],
+    threshold: float = 0.95,
+) -> list[ConfidenceFlag]:
+    """Return items below confidence threshold."""
+    flags = [score_confidence(item) for item in items]
+    return [f for f in flags if f.score < threshold]
+```
+
+### 3. LLM 验证器（仅用于边缘情况）
+
+```python
+def validate_with_llm(
+    item: ParsedItem,
+    original_text: str,
+    client,
+) -> ParsedItem:
+    """Use LLM to fix low-confidence extractions."""
+    response = client.messages.create(
+        model="claude-haiku-4-5-20251001",  # Cheapest model for validation
+        max_tokens=500,
+        messages=[{
+            "role": "user",
+            "content": (
+                f"Extract the question, choices, and answer from this text.\n\n"
+                f"Text: {original_text}\n\n"
+                f"Current extraction: {item}\n\n"
+                f"Return corrected JSON if needed, or 'CORRECT' if accurate."
+            ),
+        }],
+    )
+    # Parse LLM response and return corrected item...
+    return corrected_item
+```
+
+### 4. 混合管道
+
+```python
+def process_document(
+    content: str,
+    *,
+    llm_client=None,
+    confidence_threshold: float = 0.95,
+) -> list[ParsedItem]:
+    """Full pipeline: regex -> confidence check -> LLM for edge cases."""
+    # Step 1: Regex extraction (handles 95-98%)
+    items = parse_structured_text(content)
+
+    # Step 2: Confidence scoring
+    low_confidence = identify_low_confidence(items, confidence_threshold)
+
+    if not low_confidence or llm_client is None:
+        return items
+
+    # Step 3: LLM validation (only for flagged items)
+    low_conf_ids = {f.item_id for f in low_confidence}
+    result = []
+    for item in items:
+        if item.id in low_conf_ids:
+            result.append(validate_with_llm(item, content, llm_client))
+        else:
+            result.append(item)
+
+    return result
+```
+
+## 实际指标
+
+来自一个生产中的测验解析管道（410 个项目）：
+
+| 指标 | 值 |
+|--------|-------|
+| 正则表达式成功率 | 98.0% |
+| 低置信度项目 | 8 (2.0%) |
+| 所需 LLM 调用次数 | ~5 |
+| 相比全 LLM 的成本节省 | ~95% |
+| 测试覆盖率 | 93% |
+
+## 最佳实践
+
+* **从正则表达式开始** — 即使不完美的正则表达式也能提供一个改进的基线
+* **使用置信度评分** 来以编程方式识别需要 LLM 帮助的内容
+* **使用最便宜的 LLM** 进行验证（Haiku 类模型已足够）
+* **切勿修改** 已解析的项 — 从清理/验证步骤返回新实例
+* **TDD 效果很好** 用于解析器 — 首先为已知模式编写测试，然后是边缘情况
+* **记录指标**（正则表达式成功率、LLM 调用次数）以跟踪管道健康状况
+
+## 应避免的反模式
+
+* 当正则表达式能处理 95% 以上的情况时，将所有文本发送给 LLM（昂贵且缓慢）
+* 对自由格式、高度可变的文本使用正则表达式（LLM 在此处更合适）
+* 跳过置信度评分，希望正则表达式“能正常工作”
+* 在清理/验证步骤中修改已解析的对象
+* 不测试边缘情况（格式错误的输入、缺失字段、编码问题）
+
+## 适用场景
+
+* 测验/考试题目解析
+* 表单数据提取
+* 发票/收据处理
+* 文档结构解析（标题、章节、表格）
+* 任何具有重复模式且成本重要的结构化文本

package/resources/local/ecc/docs/zh-CN/skills/remotion-video-creation/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: remotion-video-creation
+description: Remotion 最佳实践 - 在 React 中创建视频。29 条领域特定规则，涵盖 3D、动画、音频、字幕、图表、过渡等。
+metadata:
+  tags: remotion, video, react, animation, composition, three.js, lottie
+---
+
+## 使用时机
+
+当处理 Remotion 代码并需要获取领域特定知识时，请使用此技能。
+
+## 使用方法
+
+阅读各个规则文件以获取详细说明和代码示例：
+
+* [rules/3d.md](rules/3d.md) - 使用 Three.js 和 React Three Fiber 在 Remotion 中创建 3D 内容
+* [rules/animations.md](rules/animations.md) - Remotion 的基础动画技能
+* [rules/assets.md](rules/assets.md) - 在 Remotion 中导入图片、视频、音频和字体
+* [rules/audio.md](rules/audio.md) - 在 Remotion 中使用音频和声音——导入、裁剪、音量、速度、音调
+* [rules/calculate-metadata.md](rules/calculate-metadata.md) - 动态设置合成时长、尺寸和属性
+* [rules/can-decode.md](rules/can-decode.md) - 使用 Mediabunny 检查浏览器能否解码视频
+* [rules/charts.md](rules/charts.md) - Remotion 的图表和数据可视化模式
+* [rules/compositions.md](rules/compositions.md) - 定义合成、静态画面、文件夹、默认属性和动态元数据
+* [rules/display-captions.md](rules/display-captions.md) - 在 Remotion 中显示字幕，支持 TikTok 风格页面和单词高亮
+* [rules/extract-frames.md](rules/extract-frames.md) - 使用 Mediabunny 从视频中提取指定时间戳的帧
+* [rules/fonts.md](rules/fonts.md) - 在 Remotion 中加载 Google 字体和本地字体
+* [rules/get-audio-duration.md](rules/get-audio-duration.md) - 使用 Mediabunny 获取音频文件的时长（秒）
+* [rules/get-video-dimensions.md](rules/get-video-dimensions.md) - 使用 Mediabunny 获取视频文件的宽度和高度
+* [rules/get-video-duration.md](rules/get-video-duration.md) - 使用 Mediabunny 获取视频文件的时长（秒）
+* [rules/gifs.md](rules/gifs.md) - 显示与 Remotion 时间线同步的 GIF
+* [rules/images.md](rules/images.md) - 使用 Img 组件在 Remotion 中嵌入图片
+* [rules/import-srt-captions.md](rules/import-srt-captions.md) - 使用 @remotion/captions 将 .srt 字幕文件导入 Remotion
+* [rules/lottie.md](rules/lottie.md) - 在 Remotion 中嵌入 Lottie 动画
+* [rules/measuring-dom-nodes.md](rules/measuring-dom-nodes.md) - 在 Remotion 中测量 DOM 元素尺寸
+* [rules/measuring-text.md](rules/measuring-text.md) - 测量文本尺寸、将文本适配到容器以及检查溢出
+* [rules/sequencing.md](rules/sequencing.md) - Remotion 的序列模式——延迟、裁剪、限制项目时长
+* [rules/tailwind.md](rules/tailwind.md) - 在 Remotion 中使用 TailwindCSS
+* [rules/text-animations.md](rules/text-animations.md) - Remotion 的排版和文本动画模式
+* [rules/timing.md](rules/timing.md) - Remotion 中的插值曲线——线性、缓动、弹簧动画
+* [rules/transcribe-captions.md](rules/transcribe-captions.md) - 转录音频以在 Remotion 中生成字幕
+* [rules/transitions.md](rules/transitions.md) - Remotion 的场景过渡模式
+* [rules/trimming.md](rules/trimming.md) - Remotion 的裁剪模式——裁剪动画的开头或结尾
+* [rules/videos.md](rules/videos.md) - 在 Remotion 中嵌入视频——裁剪、音量、速度、循环、音调

package/resources/local/ecc/docs/zh-CN/skills/repo-scan/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: repo-scan
+description: 跨栈源代码资产审计——对每个文件进行分类，检测嵌入的第三方库，并为每个模块提供可操作的四级判定结果，附带交互式HTML报告。
+origin: community
+---
+
+# repo-scan
+
+> 每个生态系统都有自己的依赖管理器，但没有工具能跨 C++、Android、iOS 和 Web 告诉你：有多少代码真正属于你，哪些是第三方代码，哪些是冗余负担。
+
+## 适用场景
+
+* 接手大型遗留代码库，需要了解整体结构
+* 重大重构前——识别核心代码、重复代码和废弃代码
+* 审计直接嵌入源码（而非通过包管理器声明）的第三方依赖
+* 为单体仓库重组准备架构决策记录
+
+## 安装
+
+```bash
+# Fetch only the pinned commit for reproducibility
+mkdir -p ~/.claude/skills/repo-scan
+git init repo-scan
+cd repo-scan
+git remote add origin https://github.com/haibindev/repo-scan.git
+git fetch --depth 1 origin 2742664
+git checkout --detach FETCH_HEAD
+cp -r . ~/.claude/skills/repo-scan
+```
+
+> 安装任何代理技能前，请先审查源码。
+
+## 核心能力
+
+| 能力 | 描述 |
+|---|---|
+| **跨技术栈扫描** | 一次扫描 C/C++、Java/Android、iOS（OC/Swift）、Web（TS/JS/Vue） |
+| **文件分类** | 每个文件标记为项目代码、第三方代码或构建产物 |
+| **库检测** | 识别 50+ 已知库（FFmpeg、Boost、OpenSSL…）并提取版本号 |
+| **四级判定** | 核心资产 / 提取合并 / 重建 / 废弃 |
+| **HTML 报告** | 交互式深色主题页面，支持逐层下钻导航 |
+| **单体仓库支持** | 分层扫描，提供摘要 + 子项目报告 |
+
+## 分析深度级别
+
+| 级别 | 读取文件数 | 适用场景 |
+|---|---|---|
+| `fast` | 每模块 1-2 个 | 快速盘点大型目录 |
+| `standard` | 每模块 2-5 个 | 默认审计，含完整依赖 + 架构检查 |
+| `deep` | 每模块 5-10 个 | 增加线程安全、内存管理、API 一致性检查 |
+| `full` | 所有文件 | 合并前全面审查 |
+
+## 工作原理
+
+1. **分类仓库表面**：枚举文件，将每个文件标记为项目代码、嵌入的第三方代码或构建产物。
+2. **检测嵌入的库**：检查目录名、头文件、许可证文件和版本标记，识别捆绑的依赖及其可能版本。
+3. **为每个模块评分**：按模块或子系统分组文件，根据所有权、重复度和维护成本分配四种判定之一。
+4. **突出结构风险**：指出冗余产物、重复的封装器、过时的供应商代码，以及应提取、重建或废弃的模块。
+5. **生成报告**：返回简洁摘要及交互式 HTML 输出，支持按模块下钻，便于异步审查审计结果。
+
+## 示例
+
+在一个 50,000 文件的 C++ 单体仓库中：
+
+* 发现仍在使用 FFmpeg 2.x（2015 年版本）
+* 发现同一 SDK 封装器重复了 3 次
+* 识别出 636 MB 已提交的 Debug/ipch/obj 构建产物
+* 分类结果：3 MB 项目代码 vs 596 MB 第三方代码
+
+## 最佳实践
+
+* 首次审计时从 `standard` 深度开始
+* 对包含 100+ 模块的单体仓库使用 `fast` 快速盘点
+* 对标记为需重构的模块增量运行 `deep`
+* 审查跨模块分析结果，检测子项目间的重复代码
+
+## 链接
+
+* [GitHub 仓库](https://github.com/haibindev/repo-scan)

package/resources/local/ecc/docs/zh-CN/skills/research-ops/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: research-ops
+description: 以证据为先的ECC当前状态研究工作流程。当用户希望基于当前公开证据和提供的本地上下文获取最新事实、比较、丰富信息或建议时使用。
+origin: ECC
+---
+
+# 研究运营
+
+当用户要求研究当前信息、比较选项、丰富人员或公司信息，或将重复查询转化为可监控的工作流时，使用此功能。
+
+这是仓库研究栈的操作封装。它并非 `deep-research`、`exa-search` 或 `market-research` 的替代品；而是指示何时以及如何将它们结合使用。
+
+## 技能栈
+
+在相关场景下，将这些 ECC 原生技能纳入工作流：
+
+* `exa-search`：用于快速发现当前网络信息
+* `deep-research`：用于多源综合并附带引用
+* `market-research`：当最终结果应为建议或排序决策时使用
+* `lead-intelligence`：当任务针对人员/公司而非通用研究时使用
+* `knowledge-ops`：当结果需持久存储于后续上下文时使用
+
+## 使用时机
+
+* 用户提及“研究”、“查找”、“比较”、“我应该联系谁”或“最新情况”
+* 答案依赖于当前的公开信息
+* 用户已提供证据，并希望将其纳入新的建议中
+* 任务可能具有重复性，应转为监控而非一次性查询
+
+## 防护措施
+
+* 当新鲜搜索成本低廉时，不要依赖过时记忆回答当前问题
+* 区分：
+  * 有来源的事实
+  * 用户提供的证据
+  * 推断
+  * 建议
+* 如果答案已存在于本地代码或文档中，不要启动繁重的研究流程
+
+## 工作流
+
+### 1. 从用户已提供的信息出发
+
+将任何提供的材料规范化为：
+
+* 已有证据的事实
+* 需要验证的内容
+* 未解决的问题
+
+如果用户已构建部分模型，不要从零开始重新分析。
+
+### 2. 对请求进行分类
+
+在搜索前选择正确的路径：
+
+* 快速事实性回答
+* 比较或决策备忘录
+* 线索/丰富化处理
+* 重复监控候选
+
+### 3. 优先采用最轻量的有效证据路径
+
+* 使用 `exa-search` 进行快速发现
+* 当需要综合或多源信息时，升级至 `deep-research`
+* 当结果需以建议形式呈现时，使用 `market-research`
+* 当实际需求是目标排序或温暖路径发现时，转交至 `lead-intelligence`
+
+### 4. 报告时明确证据边界
+
+对于重要声明，说明其属于：
+
+* 有来源的事实
+* 用户提供的上下文
+* 推断
+* 建议
+
+对时效性敏感的答案应包含具体日期。
+
+### 5. 决定任务是否应保持手动
+
+如果用户可能反复提出相同的研究问题，请明确说明，并建议采用监控或工作流层，而非永远重复相同的手动搜索。
+
+## 输出格式
+
+```text
+问题类型
+- 事实性 / 比较性 / 补充性 / 监控性
+
+证据
+- 有来源的事实
+- 用户提供的上下文
+
+推论
+- 从证据中得出的结论
+
+建议
+- 答案或下一步行动
+- 是否应将其设为监控项
+```
+
+## 常见陷阱
+
+* 不要将推断混入有来源的事实而不加标注
+* 不要忽略用户提供的证据
+* 不要对本地仓库上下文能回答的问题使用繁重的研究路径
+* 不要给出不含日期的时效性敏感答案
+
+## 验证
+
+* 重要声明需标注证据类型
+* 时效性敏感的输出需包含日期
+* 最终建议需与实际使用的研究模式匹配