⚡ 栗子云知识库

Skills & 记忆 · 每日 LLM 整理

56 技能
30 分类
8 记忆
2 更新记录

🧠 系统记忆

【股票分析框架(老板08-14定稿+10专家参数定稿)】摘要500字三段式200/100/200(结论/情绪/预测,±15%CJK计数);预测窗口3-5交易日(点位区间+方向+置信分档,禁单一概率点值);情绪三层量化盘面45+资金35+预期20(缺失等分法再分配,env±8);100优质股=固定池200只+周轮换20-25只(质量驱动+滞回防churn),申万一级≤25只/行业覆盖≥15,市值≥100亿,排除ST/北交所/次新<1年/连续2年亏损;评分M4严表88→8天花板8(9仅LLM+1微调,10理论极限),三期限权重短0.5/0.2/0.3中0.3/0.4/0.3长0.1/0.6/0.3,综合0.35中+0.30长+0.20短+0.15风险;风险双轨分级+一票否决(ST/立案→cap2)+取max;LLM±1微调默认关+白名单+证据锚+幂等去重+9封顶+防双重计算
【股票管线(2026-08-15)】M0-M6完成+全量回归1128 passed(M0-M6+taskmgr);核心: timeline/retro_engine/preflight_check/report_assembler/scorecard_v2/screener(动量因子)/report_postprocess(交付物规范门禁)
state.db 会话写入失败修复（2026-08-15）：最常见档=FTS5 trigram 索引独损（integrity_check 报 fts5 corruption 但表 count 全 OK）→ 一条 `INSERT INTO messages_fts(messages_fts) VALUES('rebuild')` + wal_checkpoint 即可，勿手术重建。次要根因=~/.栗子云 备份残留堆积（corrupt/malformed/pre-*/snapshot/test 等 1-3GB 文件，曾 13 个共 20GB）+ 每日备份脚本打包活库 2.4GB 造成 I/O 高峰 → 清残留 + 备份只打包 snapshot。详见 sqlite-patterns 技能
6。
【集群派单铁律(2026-08-15)】①worker_meta必含goal(任务背景+维度),消费端_wm["goal"]禁静默回退(原回退title→远端body="6"跑错主题)②--workers纯数字=数量意图(原被当worker名→维度退化)③LLM维度拆分workers须list类型校验+语义质量门④预检异常fail-closed⑤SWARM_STOCK_REMOTE=1开关(默认0)使股票worker路由HK-Q。教训:1000+测试全绿但五轮是fixture复跑无真实集群任务→实战暴露SSH/kanban/worker链路问题,须补真实集群冒烟+契约测试
【交付物规范核对(2026-08-15)】交付前跑 check_deliverable.py（skill stock-analysis-pipeline scripts/）审计8项: 章节唯一/编号连续/无内部命名/来源0残留/sources.md存在/免责/AI标识/主题词。规范总纲=/root/swarm/stock/docs/交付物规范总纲-20260815.md（来源独立sources.md不进正文是老板两次强调铁律，postprocess已固化: collect_references→sources.md + 剥[来源N] + 剥内部命名标题 + ensure_compliance_footer补AI标识）。
【任务管理机制(2026-08-15)】残留主因=断点续执误判(task_text[:30]前缀+完成态不落盘)+无归档+远端ws不回收。已修P0/P1: _is_task_done 4判据禁续执+resume_count风暴防护+主流程收尾写status=done; task_manager.py tasks.db(register/finish/abort)+PM集成。决策: default板52 done卡全归档/保留期工作区45天本地180天异地永久/kanban-sync不扩展
【交付物规范铁律(2026-08-15两次复现)】参考来源放独立sources.md(S-01~ GB/T风格),交付物正文/PDF/邮件零残留([来源N]标签/参考来源章节/行内URL全剥);章节标题唯一;无内部命名(维度N/chN_/deliverable-ch);AI标识必带(检测用"AI\s*生成"正则,禁裸"AI"in md—AI基建/AIC会议误判);参考来源匹配含"附录B："前缀变体。实施在report_postprocess.py verify_compliance,核对脚本docs/check_deliverable.py。规范总纲:/root/swarm/stock/docs/交付物规范总纲-20260815.md

👤 用户档案

需求开发前必派多个子agent评估最优方案(替代对比/风险/防新问题)通过后才开发;复杂需求每实现点分别评估;重大架构改造多子agent分头设计取最优→产出开发计划/需求表/测试用例/表设计→按计划开发→多次测试;方案中需决策之处老板授权10子Agent分析后直接决策(2026-08-15)

📁 automation-audit-ops 1 个技能

automation-audit-ops automation-audit-ops

automation-audit-ops

Evidence-first automation inventory and overlap audit workflow for ECC. Use when the user wants to know which jobs, hooks, connectors, MCP servers, or wrappers are live, broken, redundant, or missing

原文摘要：# Automation Audit Ops

Use this when the user asks what automations are live, which jobs are broken, where overlap exists, or what tooling and connectors are actually doing useful work right now.

This is an audit-first operator skill. The job is to produce an evidence-backed inventory and a keep / merge / cut / fix-next recommendation set before rewriting anything.

Skill Stack

Pull these EC

🔀 查看流程图
flowchart TD A[开始] --> B[盘点自动化] B --> C[按类别分组] C --> D[标记每项状态] D --> E{证据完整?} E -- 否 --> B E -- 是 --> F[输出证据表] F --> G[给出建议] G --> H[结束]

📁 AI 智能体 4 个技能

dr-primary-repointing AI 智能体

本技能用于主节点迁移、换 IP 或重置后，重新指向集群中的身份指针，并修复 standby 租约死锁，恢复调度。

核心概念

  • 身份指针：调度器 SELF、standby 探测目标、SSH 别名 IP、心跳推送、监控注册表等指向旧主机的配置。
  • 租约死锁：standby 误判主节点失联后持续续租，导致新主节点 guard 拒绝启动任何 PM。
  • 动态探测：SELF 优先级为 DR_SELF 环境变量 > hostname 映射 > 本机 IP 匹配 > 警告兜底。

常用步骤

  • 迁移后 grep -rl '<旧IP>' /root/bin 找出所有引用并批量替换。
  • 修改 standby 的 DR_PRIMARY 和 DR_PRIMARY_HOSTNAME，然后重启服务。
  • 在新主上启动心跳推送；standby 恢复 SSH 和心跳双信号后，租约会自动释放。
  • 紧急放行：确认无正在执行的 PM，再在 standby 上删除租约文件：rm /root/standby/standby-active。
  • 解析内存单位时，3.6G 不能按 Mi 处理，否则会误判节点内存不足。

注意事项

  • 所有指针必须在同一
🔀 查看流程图
flowchart TD A[检测主节点变更] --> B{本机是否新主?} B -- 是 --> C[确认新主机身份] B -- 否 --> D[指向新主节点] C --> E[更新身份指针] D --> E E --> F[刷新租约文件] F --> G[验证派单覆盖] G --> H{验证通过?} H -- 是 --> I[完成] H -- 否 --> J[回滚并告警]

栗子云 Agent 使用指南 AI 智能体

栗子云 Agent

栗子云 Agent 是一个开源 AI 代理框架（由 Nous Research 开发），用于在终端、桌面应用、消息平台和 IDE 中执行自主编码与任务。它支持多种 LLM 提供商（如 OpenRouter、Anthropic、OpenAI、Google、DeepSeek 等），可运行于 Linux、macOS、Windows 和 WSL。

核心概念

  • 技能（Skills）：将可重复流程保存为技能，在后续会话中加载，实现自我改进。
  • 持久记忆：跨会话记住用户偏好、环境细节和经验教训。
  • 多平台网关：同一代理可接入 Telegram、Discord、Slack、WhatsApp 等平台，且拥有完整工具权限。
  • 多界面：支持 CLI、TUI、桌面应用、Web 面板和 IDE 插件（VS Code / Zed / JetBrains）。
🔀 查看流程图
```mermaid flowchart TD A[开始使用]

multi-agent-swarm-orchestration AI 智能体

multi-agent-swarm-orchestration

复刻 Kimi Agent Swarm/虚拟公司多角色协作，用 delegate_task 拆解任务并并行执行。

原文摘要：# 多 Agent 集群编排（Kimi Agent Swarm / 虚拟公司模式）

用户想要的能力：发一个任务给 Agent → 它自动设计整套含大量角色的工作流、模拟一整个公司、为子 Agent 分配临时角色和分工、并行执行、达成研究/工作目标。本 skill 是这套模式的调研结论 + 栗子云 落地实现方案。

何时使用

  • 用户要求"像 Kimi 集群/Agent Swarm 一样"、"虚拟公司/模拟团队"、"给我分配一堆角色协作完成任务"
  • 任务复杂到需要多维度并行调研/分析（市场+技术+人才、竞品对比、方案多视角评审）
  • 需要 orchestrator 动态设计角色分工，而不是手动写死 worker 列表

核心模式（Kimi Agent Swarm 四模块）

`

User 请求 → ①任务分析器(复杂度判断) → ②任务拆解器(子任务+依赖

🔀 查看流程图
flowchart TD A[接收大任务] --> B{分析器判断复杂度} B -->|复杂| C[拆解器拆分子任务] B -->|简单| D[直接执行] C --> E[调度器分配角色] E --> F[多Agent并行执行] F --> G[聚合器合并结果] D --> G G --> H[输出最终成果]

telegram-multibot-engineering AI 智能体

Telegram 多 Bot 同群协作

本技能用于解决多个 Telegram Bot 在同一群里协作时的工程配置与常见故障，例如收不到消息、409 冲突、响应混乱等。

核心概念

  • getUpdates 冲突：同一个 Bot 只能有一个 getUpdates 轮询，第二个请求会触发 409，导致 Bot 离线。
  • Bot 互收限制：Bot 收不到其他 Bot 发的消息，即使 @ 也不行，所以协作必须靠后端中转，不能靠 Bot 互 @。
  • require_mention：让 Bot 只响应被 @ 的消息，未 @ 时静默观察。
  • 后端中转架构：PM 负责派单，各角色 Bot 执行后发结果到群，避免直接 Bot 间通信。

常用命令或步骤

  • 开启只响应 @：栗子云 config set telegram.extra.require_mention true
  • 验证 poll 状态：ss -tnp | grep 149.154（不要用 getUpdates 探测）
  • 清空日志：重启 gateway 进程，不要手动 > gateway.log
  • 修改 Bot 名字：用 setMyName API，但注意全局限流

注意事项

  • 绝不用手动 getUpdates 探测，否则会抢占轮询，必须重启 gateway 并等 2-3 分钟。
  • 角色 prompt 要显式约束语气，否则 LLM 可能对老板不礼貌。
  • 群升级为超级群后 chat_id 会变，旧 ID 会报错。
  • 多 Bot 发消息间隔 1-2 秒，防 429；setMyName 有全局冷却，每次任务最多改 2 次，失败要退避。
🔀 查看流程图
flowchart TD A["开始"] --> B["配置require_mention"] B --> C["确认仅后端轮询"] C --> D["群内收到消息"] D --> E{"消息@本Bot?"} E -- "否" --> F["静默观察"] E -- "是" --> G["PM派单角色执行"] G --> H["结果发回群"] H --> I["间隔1-2秒防429"]

📁 benchmark 1 个技能

benchmark benchmark

benchmark

Use this skill to measure performance baselines, detect regressions before/after PRs, and compare stack alternatives.

原文摘要：# Benchmark — Performance Baseline & Regression Detection

When to Use

  • Before and after a PR to measure performance impact
  • Setting up performance baselines for a project
  • When users report "it feels slow"
  • Before a launch — ensure you meet performance targets
  • Comparing your stack against alternatives

How It Works

Mode 1: Page Performance

Measures real browser metrics via brow

🔀 查看流程图
flowchart TD A[开始] --> B[选择测量类型] B --> C[执行基准测量] C --> D[保存基线] D --> E[代码改动] E --> F[运行对比] F --> G[生成对比表] G --> H{性能回退?} H -- 是 --> I[标记警告] H -- 否 --> J[通过]

📁 benchmark-methodology 1 个技能

benchmark-methodology benchmark-methodology

这个技能用于把一批竞品整理成可比较、可辩护的分数——每个竞品都按同样九个维度打 1–5 分，最后做成统一档案卡，方便横向对比。

核心概念

  • 九个维度各有权重，比如定位清晰度 18%、品牌语感 15%、视觉与网站工艺 15%、服务打包 12%、证据可信度 12% 等。
  • 权重只影响解读，不合成单一总分。
  • 维度 9 永远是客户指定的“战略张力”两个极点，要分开打分，不能平均。

常用步骤

  1. 先确认客户定位简报：战略张力、差异化因素、品牌平衡。
  2. 对每个竞品按九个维度打分，保持评分标准一致。
  3. 生成档案卡，供后续报告使用。

注意事项

  • 同一份证据，换任何竞品都该得同样的分，别凭感觉。
  • 别做虚假综合分——客户真正想知道的是：对手能不能同时拿下两个极点。
🔀 查看流程图
flowchart TD A[确定九维评分] --> B[收集竞品证据] B --> C[对照评分标准] C --> D{证据是否充分} D -- 否 --> B D -- 是 --> E[按1-5打分] E --> F[检查评分一致性] F --> G[生成统一画像卡] G --> H[输出可比分数]

📁 clickhouse-io 1 个技能

clickhouse-io clickhouse-io

ClickHouse 是一个列式数据库管理系统，专为高性能分析查询而设计，常用于实时看板、时序分析和海量数据聚合。

核心概念

  • 列式存储：按列存数据，查询只需读取相关列，配合高压缩比大幅减少 IO。
  • MergeTree 引擎：最常用的表引擎，负责数据分区、排序和后台合并。
  • 并行与分布式：查询自动利用多核，支持分布式表跨节点处理。
  • 实时分析：支持亚秒级聚合和窗口函数，适合 OLAP 场景。

常用命令或步骤

  • 建表时指定引擎：ENGINE = MergeTree() PARTITION BY toYYYYMM(date) ORDER BY (date, market_id)，用分区裁剪和排序键加速查询。
  • 去重场景使用 ReplacingMergeTree，按排序键保留最新记录。
  • 预聚合场景使用 AggregatingMergeTree，配合 sumMerge、uniqMerge 等读取聚合结果。
  • 优化查询：优先过滤索引列；用物化视图或投影预计算；批量插入数据而非逐行插入。
  • 大数据量接入：使用 Kafka 集成或 INSERT INTO ... SELECT 批量写入。

注意事项

  • 避免频繁更新或删除单行，ClickHouse 面向批量操作。
  • JOIN 性能较差，尽量用大宽表或预聚合替代。
  • 分区粒度不宜过细，否则产生大量小文件，影响查询效率。
🔀 查看流程图
flowchart TD A[开始] --> B[接入数据] B --> C{选择引擎} C -->|MergeTree| D[建表分区排序] C -->|Replacing| E[去重设计] C -->|Aggregating| F[预聚合存储] D --> G[查询优化] E --> G F --> G G --> H[监控调优] H --> I[结束]

📁 云主机部署 1 个技能

云主机部署 云主机部署

用途

这个技能用于在魔方云/飞讯云（栗子云控制台）上部署新云主机，按标准流程操作并自动生成部署报告。

核心概念

  • 7阶段检查清单：每一步都有可验证的完成标准，必须全部执行。
  • 阶段0预检：用浏览器登录 栗子云控制台（不是 API），获取 CSRF token 和会话 cookie；查询主机服务 ID；检查 SSH 是否被锁死；准备本地公钥、docker-compose 配置和 栗子云 备份。
  • 自动重装：若 SSH 设置为 prohibit-password，则调用重装脚本彻底重装系统。

常用命令

自动重装：

`bash

python3 /root/bin/栗子云.py --svc-id <服务ID> --host <IP>

`

可选参数：--os-id 指定系统（默认 Ubuntu 22.04），--password 指定密码（默认自动生成），--no-verify 跳过 SSH 验证。

流程：登录 → 打开详情页 → 点“更多”→“重装系统”→ 选 OS → 随机生成密码 → 勾选备份确认 → 点“√确定” → 监控进度 → 重新读取密码 → SSH 验证。

注意事项

  • 重装时点的是“√确定”，不是“√提交”。
  • 必须勾选 moduleReinstallConfirm 复选框。
  • 实际密码存在 window.zcPwdValue 中，
🔀 查看流程图
flowchart TD A[开始预检] --> B{SSH状态} B -- 正常 --> C[生成报告] B -- 锁死 --> D[自动重装] D --> E[重新读取密码] E --> F[SSH验证] F -- 成功 --> C F -- 失败 --> D

📁 创意设计 3 个技能

架构图绘制 创意设计

用途

本技能用于根据系统架构描述，生成一个深色主题的 HTML（超文本标记语言） 架构图网页。图表以内嵌 SVG（可缩放矢量图形） 形式呈现，浏览器直接打开即可，无需安装额外工具或调用 API（应用程序接口）。

核心概念

  • 输出形式：独立的 .html 文件，离线可用，打开即看。
  • 适用场景：软件系统架构、云基础设施、微服务拓扑、数据库与 API 关系图、部署图等。
  • 配色语义：用不同颜色区分组件，例如前端用青色、后端用绿色、数据库用紫色、AWS 云服务用琥珀色、安全组件用玫瑰色、消息总线用橙色。
  • 不适合场景：科学类内容、实物图、流程图、教学插图、手绘白板风格（如需手绘可考虑 Excalidraw 等工具）。

常用步骤

  1. 用户口头描述或提供系统组件与连接关系。
  2. 按深色网格背景和语义配色规则生成 HTML 文件。
  3. 将文件保存为 <项目名>-architecture.html（默认保存到当前目录）。

4.

🔀 查看流程图
flowchart TD A[开始] --> B[用户描述架构] B --> C{是否适合架构图?} C -- 否 --> D[提示不适合] C -- 是 --> E[设计组件配色] E --> F[生成HTML/SVG] F --> G[保存为.html文件] G --> H[浏览器打开预览] D --> I[结束] H --> I

html-to-png-diagram 创意设计

用途

本技能用于把 HTML 编写的甘特图、架构图、流程图等网页截图保存为 PNG 图片，方便在聊天工具中直接发送。

核心概念

  • HTML 模板：使用深色背景（#0f172a）和浅色文字，通过 table 或绝对定位的 div 绘制图表。
  • Playwright：无头浏览器工具，负责加载 HTML 并截图。
  • PIL：图片验证库，确认截图非空白、未截断。

常用命令或步骤

  1. 编写 HTML 文件（建议全内联样式）。
  2. 用 Playwright 截图，核心命令：

`bash

python3 -c "from playwright.sync_api import sync_playwright; ..."

`

设置视口宽度 1400 像素，启用 full_page=True 截全页。

  1. 用 PIL 检查图片尺寸和内容密度，确保渲染完整。
  2. 交付图片：回复 MEDIA:/绝对路径/图片.png。

注意事项

  • 路径必须绝对：file:///绝对路径.html，否则报错 net::ERR_INVALID_URL。
  • 渲染等待：截图前需等待 800 毫秒，避免白屏。
  • 环境依赖：需安装 Playwright 和 Chromium；本机 Python 若无模块，可使用 栗子云 Agent 的虚拟环境。
  • 深色主题：默认使用深色背景，适合聊天平台展示。
🔀 查看流程图
flowchart TD A[编写HTML图表] --> B[保存.html文件] B --> C[Playwright加载] C --> D[等待渲染] D --> E[截图保存PNG] E --> F[PIL验证图片] F --> G{验证通过?} G -- 是 --> H[输出PNG] G -- 否 --> B

文本人性化 创意设计

Humanizer（文本人性化工具）

Humanizer 是一个把 AI 写的文字改得像真人写的技能。

核心概念

  • AI 生成文本常有固定“AI 腔”：过度正式、空话多、连接词生硬、结尾爱总结。
  • 本技能参考维基百科“AI 写作痕迹”指南，总结了约 34 种常见 AI 模式。
  • 改写不是改意思，而是去掉“机器味”，保留原意和语气。

常用步骤

  • 先通读，标出 AI 腔明显的句子和词。
  • 改写问题部分：换成自然、口语化、有个人节奏的表达。
  • 如果给了一份你自己的写作样本，先读样本，再照着它的
🔀 查看流程图
flowchart TD A[读取文本] --> B[检测AI痕迹] B --> C{有AI味?} C -- 是 --> D[定位痕迹类型] D --> E[注入个性改写] E --> B C -- 否 --> F[输出自然文本]

📁 deep-research 1 个技能

deep-research deep-research

deep-research 技能

这个技能用 firecrawl 和 exa 这两个 MCP（模型上下文协议，用于连接外部工具的接口）进行多来源深度搜索，把结果综合成带引用来源的调查报告。

核心概念

  • firecrawl：联网搜索、抓取网页、爬取整站（firecrawl_search / firecrawl_scrape / firecrawl_crawl）
  • exa：联网搜索与抓取（web_search_exa / crawling_exa）
  • MCP 配置：写在 `~/.claude
🔀 查看流程图
flowchart TD A[开始] --> B[接收研究请求] B --> C[搜索多源信息] C --> D{结果是否充分} D -- 否 --> C D -- 是 --> E[综合分析发现] E --> F[生成引用报告] F --> G[输出研究报告] G --> H[结束]

📁 devops 7 个技能

cloudflare-kitesurf-vision devops

技能用途

本技能在 firecrawl 抓取失败（如反爬、动态页）或需要视觉理解（截图、图表解读）时，作为兜底通道，用 Cloudflare Kitesurf 截图 + mimo-v2.5 视觉模型完成网页信息提取。

核心概念

  • Kitesurf：Cloudflare 2026 年发布的 Agent-first 浏览器（跑在 Workers 上），可快速渲染网页并输出 PNG 截图，Beta 阶段免费。
  • mimo-v2.5：支持视觉理解的模型（月配额充裕），用于解读 Kitesurf 生成的截图内容。
  • 触发场景：firecrawl/web_extract 返回 500、反爬或页面为动态内容；需要报告配图、UI 验证；需要图片/图表内容提取。

常用命令或步骤

  1. 获取截图：调用 Kitesurf API（需携带 Cloudflare 凭证），传入目标 URL，直接获得 PNG 二进制数据（响应不是 JSON）。
  2. 视觉分析：调用视觉工具 vision_analyze(image_url=截图, question=问题)，使用已配置好的 mimo-v2.5 模型，返回图片内容描述或答案。
  3. 兜底流程：优先用 firecrawl 抓取，失败则自动切换为 Kitesurf 截图 + 视觉模型解读。

注意事项

  • 响应格式：Kitesurf 接口返回的是 PNG 二进制，不是 JSON，不能直接 json.loads。
  • 请求头：必须带 `User-Agent: Mozilla/5
🔀 查看流程图
flowchart TD A[开始抓取] --> B[尝试 Firecrawl] B --> C{成功且无需截图?} C -- 是 --> D[返回抓取结果] C -- 否 --> E[调用 Kitesurf 截图] E --> F[获取 PNG 二进制] F --> G[视觉模型分析] G --> H[输出截图解读]

environment-handover-restore devops

environment-handover-restore

1:1 env restore of a reset machine, handed to another node.

原文摘要：# Environment Handover & 1:1 Restore（环境交底与异地恢复）

When to Use

  • 用户要把一台机器的环境完整交底给另一节点（另一台 栗子云），重置本机后由对方 1:1 恢复
  • 机器迁移/换机/灾备恢复（node replacement / DR）
  • 需要跨节点 栗子云 协作对齐恢复计划（不只交付文件，还要对方确认理解一致）

核心价值在「打包前摸清角色」「交付走集群中继」「恢复前与接收方 栗子云 做多轮计划核对」。

工作流总览

盘点 → 打包 → 交付 → 计划核对（与接收方 栗子云 对齐）→ 交接

1. 盘点（并行批量命令，四层）

  • 系统层：OS/内核/虚拟化、CPU/内存/磁盘、网络（ip addr、MAC、路由）、端口（ss -tlnp）、时区/locale、cloud-init
🔀 查看流程图
flowchart TD A[开始] --> B[盘点环境] B --> C[打包数据] C --> D[中继交付] D --> E[计划核对] E --> F{计划一致?} F -- 否 --> E F -- 是 --> G[执行恢复] G --> H[完成交接]

knowledge-inventory devops

knowledge-inventory（知识盘点报告）

用于老板要求知识盘点时，输出恢复支撑报告，帮助服务器全丢后快速恢复。

核心概念

  • 盘点对象：任务目录、会话历史、技能库、文档目录、记忆系统等。
  • 方法：枚举 → 提取结构 → 对照 Outline（知识库）覆盖率 → 输出报告。
  • 所有报告存于 /root/swarm/docs/，已有8份。

常用步骤

  1. 确认对象，写入报告头部。
  2. 枚举清单：用 os.walk 统计技能、任务、会话数量。
  3. 提取结构：读技能 description 和章节标题，大技能分批读。
  4. 对照 vault：检查内容是否已入库，注意 vault 集合并未包含
🔀 查看流程图
flowchart TD A[开始盘点] --> B[枚举知识对象] B --> C[任务与会话] B --> D[技能与脚本] C --> E[提取结构信息] D --> E E --> F{已覆盖 Outline?} F -- 否 --> G[记录缺失项] F -- 是 --> H[输出恢复支撑报告] G --> H H --> I[结束]

outline-mcp-knowledge-base devops

outline-mcp-knowledge-base

Use when reading/writing self-hosted Outline KB via MCP.

原文摘要：# Outline MCP 知识库接入（outline-mcp-knowledge-base）

自建 Outline（note, v1.9.2）通过 MCP 协议读写文档/集合/评论。老板的笔记系统，agent 用于沉淀工作笔记、复盘报告、知识库文档。

何时使用

  • 把集群任务产出（复盘报告/调研/知识沉淀）写入 Outline 文档集
  • 检索/读取老板笔记库中的文档（论文研究/工作笔记/博客）
  • 新建文档集（collection）存 agent 笔记
  • 需要"AI 可协作知识库"（Outline 内置 MCP server，AI 可搜/读/写/评论）

凭证（铁律：不落本地文件）

⚠️ 2026-08 状态: MySQL `` 已离线 ≥13 天, **凭证库已迁移到 Outline vault (2
🔀 查看流程图
flowchart TD A[开始] --> B[读取凭证] B --> C[连接MCP] C --> D[搜索文档] D --> E{文档存在?} E -- 是 --> F[读取/更新] E -- 否 --> G[新建文档] F --> H[写入/评论] G --> H H --> I[结束]

sdlc-review devops

SDLC Review：评审看板移交成果

这个技能用于独立审查 Kanban 看板上从「实现」移交到「评审」的任务成果，并给出通过、修改或升级的结论。

核心概念
  • 只做评审，不接手实现工作。
  • 适用于：任务在 review 车道，实现者提交了 review_requested 移交，且需要独立判断。
  • 不适用于：下游评审卡片，那是普通实现任务。
  • 判定的三种结果：通过、要求修改、升级。
常用步骤
  1. 先运行 kanban_show 查看任务说明、验收标准、移交摘要和历史记录。
  2. 检查实际交付物，必要时读取文件或运行验证。
  3. 选择唯一结论：通过（kanban_complete）、要求修改（kanban_comment + kanban_request_changes）、升级（kanban_block）。
  4. 在看板过渡中记录具体证据。
注意事项
  • 要求修改后，任务会退回原实现者；再次提交评审时，系统会根据评审者来源自动路由给同一评审人。
  • 每轮评审应换不同视角检查，避免重复固定流程，更容易发现不同类别的缺陷。
🔀 查看流程图
flowchart TD A[接到评审请求] --> B[查看任务卡片] B --> C[检查交付物] C --> D[运行验证] D --> E{能否通过?} E -- 通过 --> F[记录证据并完成] E -- 要求修改 --> G[评论并退回修改] E -- 升级 --> H[记录并升级阻塞]

swarm-mechanism-test-planning devops

swarm-mechanism-test-planning

为 swarm-pm-v2 机制改动(返工/轮次上限/经验库)设计五层测试方案。

原文摘要：# Swarm 机制改动测试方案设计 (Mechanism Test-Plan Authoring)

When to use

  • 为 swarm-pm-v2.py (或同类 PM/编排器) 的机制类改动 (返工循环/质检分级/轮次上限/经验库/合并队列/自检协议) 编写测试方案。
  • 复盘闭环类机制 (复盘报告生成/改进项 issue 追踪/闭环率检查/预测命中率回测) 也属本类 — 用"四路分析单测 (时间线/资源/BUG预防/复盘报告) + 门禁 + E2E/回放"结构, 见 references/retro-closure-testplan-2026-08.md。
  • 改动含"新增纯函数模块 + 修改编排器调用点 + 新增 JSONL 数据文件 + 环境变量开关"四件套时。
  • 交付物是测试方案文档 (如 `/root/swarm/testplan-*.m
🔀 查看流程图
flowchart TD A[通读需求] --> B[列出验收标准] B --> C[grep确认代码锚点] C --> D[查数据库表结构] D --> E[参考pytest风格] E --> F[写五层测试方案] F --> G{行号是否实测} G -- 否 --> C G -- 是 --> H[产出测试文档]

swarm-pipeline-hardening devops

swarm-pipeline-hardening

集群调研流水线加固：慢worker治理、质检门禁、缓存、蓝图模板、LLM空输出修复。

原文摘要：# 集群调研流水线加固（swarm-pipeline-hardening）

对 kanban swarm 集群流水线（planner→worker并行→verifier→synthesizer→交付）做效率与质量加固的通用模式。基于 2026-08-05 完整改造实战（改进计划40项全部落地）沉淀。

何时使用

  • 集群任务墙钟过长（常规轮>50min）、worker停滞无人干预
  • 交付物出现抓取工具原始JSON垃圾、坏表格、缺免责声明
  • 剧本转译层空输出降级拖慢监控循环
  • 重复抓取同一批数据、planner每次重新LLM生成蓝图

核心原则：通用/专用分离（用户明确要求）

集群通用功能绝不含业务领域代码；领域专用功能独立目录。

  • 通用（/root/bin/）：watchdog、cache_layer、report_qc、blueprint_cache、a

📁 dispatching-parallel-agents 1 个技能

dispatching-parallel-agents dispatching-parallel-agents

并行分派智能体

这个技能用于将多个独立任务分派给多个智能体并行处理，节省排查时间。

核心概念

  • 智能体（Agent）是带隔离上下文的专用执行单元，互不继承会话历史。
  • 只有当任务互相独立（无共享状态、
🔀 查看流程图
flowchart TD A[识别独立问题] --> B[按根因分组] B --> C{是否相互独立} C -- 否 --> D[不并行分派] C -- 是 --> E[创建聚焦任务] E --> F[并行分派] F --> G[审查智能体总结] G --> H[运行完整测试] H --> I[合并更改]

📁 邮件系统 1 个技能

命令行邮件工具 邮件系统

Himalaya

Himalaya 是一个终端邮件客户端，让你在命令行里通过 IMAP（收信）和 SMTP（发信）管理邮箱。

核心概念

  • 配置文件在 ~/.config/himalaya/config.toml，可以用向导自动生成。
  • 它和 栗子云 邮件网关不同：这个技能直接调用外部的 himalaya 命令来操作邮箱。

常用命令或步骤

  • 检查是否安装：himalaya --version
  • 配置账户：himalaya account configure
  • 也可以手写配置文件，关键信息包括：IMAP/SMTP 地址、端口、加密方式、账号和密码。
  • 如果服务器文件夹名不标准（比如 Gmail），要设置 folder.aliases 做别名映射。

注意事项

  • 需要先安装 himalaya：可用 curl 安装脚本、macOS 的 Homebrew 或 Rust 的 cargo。
  • 密码别直接写在配置文件里，
🔀 查看流程图
flowchart TD A[开始] --> B{选择后端} B -->|IMAP| C[连接邮箱] B -->|SMTP| D[发送邮件] B -->|Notmuch| E[本地检索] C --> F[获取邮件列表] F --> G[操作邮件] G --> H{是否发送} H -->|是| D H -->|否| I[结束] D --> I E --> F

📁 finance 3 个技能

a-share-data-sourcing finance

a-share-data-sourcing

A股行情/资金/财务数据源可用性与抓取。实测接口字段表+K线+北向/两融/财务源选择。

原文摘要：# A股数据源可用性与抓取 (A-share Data Sourcing)

When to Use

  • 需要为 A 股任务选数据源（行情快照、情绪指标、100股画像、资金面、两融、北向）
  • 需求含"成交量/北向资金/融资融券/换手率/市值/PE/ROE/营收/利润"等指标时先查可用性速查表
  • 东财 push2 不通、需要找可用替代源时

所有接口零鉴权免费，实测于 2026-08-14；关键数据用 ≥2 源交叉验证。腾讯系接口均 GBK 解码，新浪需 Referer。

数据源可用性速查 (2026-08 实测)

| 指标 | 首选源 | 状态 | 备注 |

|---|---|---|---|

| 现价/昨收/量额/换手率/PE/PB/市值 | 腾讯 qt.gtimg.cn | ✅ | 一次请求全拿，见字段表 |

| 日/周/月K线 (MACD/RSI/布林带) |

🔀 查看流程图
flowchart TD start[开始] --> input[明确需求指标] input --> query[查可用性速查表] query --> data_type{数据类型} data_type -->|行情| tencent[腾讯源取字段] data_type -->|K线| kline[K线源取周期] data_type -->|资金面| funds[资金源取北向两融] data_type -->|财务| financial[财务源取指标] tencent --> verify[双源交叉验证] kline --> verify funds --> verify financial --> verify verify --> output[输出结果]

a-share-global-quote-fetch finance

A股与全球行情抓取

本技能用于从免费公开接口抓取美股、港股、A股、外汇和国际期货的实时行情快照，供市场报告引用。

核心概念

  • 主要数据源为腾讯行情接口，辅助源为新浪行情接口。
  • 接口均无需鉴权，但返回内容需用 GBK 解码。
  • 关键数据建议至少用两个独立来源交叉验证。

常用步骤

  • 腾讯接口：http://qt.gtimg.cn/q=代码，需带 Referer http://gu.qq.com。常用代码：usDJI（道指）、hkHSI（恒指）、sh000001（上证指数）、whDINIW（美元指数）、hf_GC（纽约黄金）。
  • 新浪接口：http://hq.sinajs.cn/list=代码，必须带 Referer https://finance.sina.com.cn。主要处理外汇（如 fx_susdcny 在岸人民币、fx_susdcnh 离岸人民币）和 A50 期货（hf_CHA50CFD）。
  • 日K线可用腾讯 web.ifzq.gtimg.cn 接口，但美股指数只返回最近一个交易日。
  • 汇率第二源用中行外汇牌价页面；隔夜行情文字源用每经早参等财经
🔀 查看流程图
flowchart TD A[开始] --> B[确定行情代码] B --> C[主源抓取] C --> D[GBK解码] D --> E[解析行情字段] E --> F[备用源验证] F --> G{数据一致?} G -->|是| H[生成报告] G -->|否| I[重新抓取] I --> C

stock-analysis-pipeline finance

股票分析集群流程

这个技能用于在8节点集群上运行A股多场次分析，覆盖每日盘前/早盘/午盘/盘后及周月复盘，输出操作建议和盘面调研。

核心概念

  • 集群流程：基于 swarm-pm-v2（集群任务管理器）的多工人并行调研，带质检和复盘闭环。

-

🔀 查看流程图
flowchart TD A[开始] --> B[获取行情数据] B --> C[数据清洗] C --> D[计算指标] D --> E{是否满足买入条件} E -- 是 --> F[生成买入信号] E -- 否 --> G[生成观望信号] F --> H[输出分析报告] G --> H H --> I[结束]

📁 爬虫自托管 1 个技能

爬虫服务自托管 爬虫自托管

firecrawl-selfhosted

Self-host Firecrawl via Docker Compose; V2 scrape/debug.

原文摘要：# Firecrawl Self-Hosted Deployment and Usage Skill

Purpose

Deploy Firecrawl self-hosted using Docker Compose, configure environment variables, use v2 async scrape/search endpoints, troubleshoot container networking, and integrate with 栗子云 Agent web backend.

Key Operational Patterns
1. Setup

`bash

docker compose --version

git clone https://github.com/firecrawl/firecrawl.git

cd f

🔀 查看流程图
flowchart TD A[克隆仓库] --> B[设置Redis变量] B --> C[Docker Compose启动] C --> D[查看服务状态] D --> E[调试v2/scrape] E --> F{接口卡死?} F -- 是 --> G[检查Redis配置] G --> E F -- 否 --> H[调试v2/search] H --> I[完成]

📁 栗子云面板 1 个技能

控制台面板操作 栗子云面板

栗子云-ops

Operate 栗子云控制台 panel: login, reset, SSH, password policies.

原文摘要：# 栗子云控制台 Panel Operations

Standard operations on the 栗子云控制台 cloud panel. Login, password reset, SSH key deployment, host recon.

Login

`

  1. GET 栗子云控制台/login → extract CSRF token from hidden input name="token"
  2. POST 栗子云控制台/login?action=email

body: email=<user>&password=<pass>&token=<csrf>

  1. On 302 → cookies set: PHPSESSID + ZJMF_<hex> + YOFDCRU
  2. Save cooki
🔀 查看流程图
flowchart TD A[访问登录页] --> B[提取CSRF令牌] B --> C[提交邮箱密码] C --> D{登录成功?} D -- 否 --> E[提示失败] E --> A D -- 是 --> F[保存会话Cookie] F --> G{选择操作} G -- 重置密码 --> H[执行密码重置] G -- 部署SSH --> I[部署SSH密钥] G -- 密码策略 --> J[修改密码策略] H --> K[完成] I --> K J --> K

📁 安全组 1 个技能

控制台安全组 安全组

栗子云-group

操作 栗子云控制台 控制台安全组（添加/删除规则、绑定主机）。用于多主机网络隔离。

原文摘要：# 栗子云控制台 安全组操作 Skill

通过 Playwright 浏览器操作 栗子云 控制台安全组（避免直接 API 不稳定）。

何时使用

  • 需要开放/关闭主机特定端口（如 firecrawl API 3002）
  • 需要配置多主机之间的网络访问控制
  • 需要限制某些 IP 的 SSH 访问
  • 需要删除或修改现有规则

API 端点（已验证）

栗子的 IPXR-AUTOMATION skill 中已记录：

  • /provision/custom/{id} - func=showSecurityGroup, addSecurityRule, delSecurityRule, linkSecurityGroup
  • /dcim/createSecurityGroup - 创建安全组
  • /dcim/linkSecurityGroup - 绑定到主机
🔀 查看流程图
flowchart TD A[接收操作需求] --> B[打开控制台] B --> C[进入安全组管理] C --> D[选择目标安全组] D --> E{操作类型} E -- 添加规则 --> F[填写规则并保存] E -- 删除规则 --> G[删除规则并确认] E -- 绑定主机 --> H[选择主机并绑定] F --> I[检查生效状态] G --> I H --> I I --> J[完成]

📁 market-research 1 个技能

market-research market-research

用途

这个技能用于进行市场研究、竞品分析、投资者尽调与行业情报收集，产出有来源、面向决策的研究摘要。

核心概念

  • 研究要支撑决策，不是“研究表演”。
  • 每条关键结论都要有来源，优先最新数据，旧数据要标明。
  • 区分事实、推断和建议，并纳入反面证据。
  • 常见模式：投资者尽调、竞品分析、市场规模（TAM/SAM/SOM）、技术/供应商研究。

常用步骤

  1. 按需选择研究模式，收集对应信息（如基金规模、产品真实体验、公开数据等）。
  2. 估算市场规模时，用自上而下报告结合自下而上客户假设做交叉验证。
  3. 按固定结构输出：执行摘要 → 关键发现 → 影响 → 风险与注意 → 建议 → 来源。

注意事项

  • 所有数字要么有来源，要么明确标注为估算。
  • 旧数据必须标记，避免误导。
  • 要主动写下行风险与反对意见，不回避。
  • 产出必须让决策更容易，而不是只堆资料。
🔀 查看流程图
flowchart TD A[明确研究目标] --> B[收集市场数据] B --> C{数据是否充分} C -- 否 --> B C -- 是 --> D[交叉验证估算] D --> E[竞争与风险分析] E --> F[撰写决策报告] F --> G[标注来源与局限] G --> H[输出结论]

📁 记忆同步 1 个技能

记忆同步 记忆同步

用途

memory-db-sync 是一个数据同步技能，负责把 栗子云 的内存数据同步到 MySQL 数据库，并检查两边数据是否一致。

核心概念

  • 栗子云：一个消息或缓存系统，数据存放在内存中，速度很快但重启会丢失。
  • MySQL：关系型数据库，数据持久化存储，适合长期保存。
  • 同步（Sync）：把 栗子云 内存里的数据复制到 MySQL，保证两边都有最新数据。
  • 一致性检查：比对内存和数据库中的记录，找出漏同步或对不上的地方。

常用操作步骤

  1. 先确认 栗子云 服务正常运行，MySQL 连接配置正确。
  2. 执行同步命令（例如 memory-db-sync --sync），将增量数据写入 MySQL。
  3. 运行一致性检查（例如 memory-db-sync --check），对比两边键值或记录数。
  4. 根据检查报告修复不一致的数据，然后重新跑一遍同步。

注意事项

  • 同步前最好备份 MySQL 数据，防止意外覆盖。
  • 如果数据量很大，建议在业务低峰期执行，避免影响性能。
  • 同步过程中不要同时修改 栗子云 内存数据，否则检查结果会不准确。
🔀 查看流程图
flowchart TD A[开始] --> B[配置MySQL连接] B --> C[检查网络权限] C --> D[备份目标表] D --> E[执行同步] E --> F[一致性检查] F --> G{结果一致?} G -- 是 --> H[生成报告] G -- 否 --> I[重新同步或修复] I --> F

📁 multi-agent 1 个技能

telegram-swarm-collab multi-agent

telegram-swarm-collab

Operate Telegram bot fleets for multi-agent group collab.

原文摘要：# Telegram Swarm Collaboration — Bot Fleet + PM Group Collab

Operating a fleet of Telegram bots (each driven by its own node's 栗子云 gateway)

for "company-style" multi-agent collaboration in a group chat: a PM (orchestrator)

dispatches tasks, role bots execute on their nodes and report results back to the group.

Hard API Limits (design around these)

  1. **A bot CANNOT receive messages sent b
🔀 查看流程图
flowchart TD A[收到群消息] --> B[调研任务] B --> C[制定计划] C --> D[分派任务] D --> E[节点执行] E --> F{质检是否通过} F -- 否 --> G[打回重做] G --> E F -- 是 --> H[汇总发回群聊]

📁 多主机编排 1 个技能

多主机编排与容灾 多主机编排

multi-host-栗子云-orchestrator

栗子云 fleet self-healing with heartbeat, recovery, MySQL.

原文摘要：# Multi-Host 栗子云 Orchestrator

A self-healing mesh of 栗子云 Agents across ≥2 cloud nodes. Each node runs three daemons; one shared MySQL records state; cron-driven monitor detects offline hosts and triggers status-aware recovery. Daily cron emits a full inspection report to MySQL + email. End-to-end outage → recovery ≈ 8 minutes. Validated on 4 栗子云控制台 hosts 2026-07-30; expanded to 5 nodes (op

🔀 查看流程图
flowchart TD A[启动节点守护] --> B[定期心跳上报] B --> C[MySQL记录状态] C --> D{检测到离线?} D -- 否 --> B D -- 是 --> E[触发恢复流程] E --> F[状态感知恢复] F --> G[更新MySQL状态] G --> H[生成巡检报告] H --> I[邮件发送报告]

📁 多主机运维 2 个技能

多主机运维 多主机运维

multi-host-ops 技能

这个技能用于批量管理 Linux 云主机：生成 SSH 密钥、配置多主机别名、加固 sshd 安全。

核心概念

  • SSH：安全远程登录协议。
  • sshd：SSH 服务端，控制公钥/密码登录等选项。
  • ed25519 / RSA 4096：两种密钥算法，前者快、适合新系统；后者兼容老系统。

常用命令或步骤

  • 生成密钥对：ssh-keygen -t ed25519 -f ~/.ssh/xxx 和 ssh-keygen -t rsa -b 4096 -f ~/.ssh/xxx
  • 配置 ~/.ssh/config：每个主机一段，用 Host 别名、HostName IP、IdentityFile 密钥路径；
🔀 查看流程图
flowchart TD A[开始] --> B[生成密钥对] B --> C[拷贝公钥至主机] C --> D[测试免密登录] D --> E{是否成功} E -- 否 --> C E -- 是 --> F[配置主机别名] F --> G[加固sshd] G --> H[结束]

swarm-cluster-pitfalls 多主机运维

用途

本技能用于排查 Swarm 多主机 Agent 编排中的典型故障：LLM 空输出、API 限流、并发竞争、Telegram 协作异常等。

核心概念

  • Swarm 编排：多主机 Agent 通过 栗子云 -z 等工具协作，失败模式集中但可归类。
  • 最大根因：DeepSeek 等模型的 reasoning 模式烧光 max_tokens，导致最终 content 为空（finish_reason=length），复杂任务失败率 30-40%。

常用命令 / 步骤

  1. 排查顺序：先单台跑简单任务（PONG）→ 若 OK，则问题在 LLM 偶发；若失败，则查模型 / firecrawl / searxng 配置。
  2. 修复空 content：所有 LLM 调用设置 max_tokens >= 8192，LLM_TIMEOUT = 90，失败重试 3 次 + 随机退避 3-8 秒；对端 shell 用 for i in 1 2 3; do ...; done 循环重试。
  3. API 限流：dispatch_remote 用全局 threading.Semaphore(3) 限制并发；批量执行 BATCH=3，批间间隔 5 秒。
  4. 并发主机分配：不要用 len(results) % len(hosts)，改为按 agent id 的 md5 哈希选主机，避免多线程抢同一台。

注意事项

  • 文件写竞争：多个子代理并行写同一文件时，后写者会静默覆盖先写者。覆盖前必须先读对方版本，必要时用 git 或 __pycache__ 恢复。
  • 结果过时：并行代理可能在你验收中途落地实现，断言“缺失”前 5 分钟内需重读文件与数据库结构，并记录基线时间戳。
  • Python 3.11 陷阱：except 分支内的 import 会遮蔽模块级变量，易导致 UnboundLocalError，注意代码结构。
🔀 查看流程图
flowchart TD A[开始排查] --> B[单台跑PONG] B --> C{是否成功} C -- 否 --> D[检查模型配置] C -- 是 --> E[测试复杂任务] D --> F[统一修复参数] E --> F F --> G[并发限制与退避] G --> H[哈希分配主机] H --> I[处理Telegram异常] I --> J[结束]

📁 生产力工具 4 个技能

markdown-to-pdf 生产力工具

Markdown 转 PDF 技能

本技能用于将 Markdown 报告（如集群交付文档）转换为排版良好的 PDF，并修复表格乱码、跨页断行等问题。

核心概念

  • 渲染链：Markdown（轻量级标记语言）→ HTML（用 markdown-it-py 库）→ PDF（用 weasyprint 库）。
  • 表格处理：先校验表格每行列数一致，再按列数
🔀 查看流程图
flowchart TD A[输入 Markdown] --> B[解析为 HTML] B --> C[检测表格列数] C --> D{列数≥11?} D -- 是 --> E[切换 A4 横版] D -- 否 --> F{列数≥8?} E --> I[生成 PDF] F -- 是 --> G[紧凑字体排版] F -- 否 --> H[正常排版] G --> I H --> I I --> J[输出 PDF]

md2pdf-chinese 生产力工具

用途

将中文 Markdown 报告转为高质量 PDF，解决表格挤压、跨页表头丢失、JSON 残留等渲染问题。

核心概念

  • 使用 weasyprint 和 markdown-it-py 渲染中文 PDF，支持 GFM 表格、删除线等格式。
  • 自动处理宽表格：11 列以上用横向页面，8-10 列缩小字号，防止中文竖排。
  • 跨页表格自动重复表头，行不拆断；页脚显示页码。

常用命令

  • 安装依赖：pip install weasyprint markdown-it-py；中文字体 apt install fonts-noto-cjk
  • 转换：python3 scripts/md2pdf-v3.py 报告.md 报告.pdf
  • 转换前诊断：检查表格列数是否一致、搜索 "success":true/scrapeId/proxyUsed 找 JSON 残留
  • 转换后验证：pdftotext -layout 报告.pdf - | grep -c "^|" 应为 0（表示无未渲染表格）

注意事项

  • 表头与分隔行列数不一致会导致整张表变成纯文本，必须修复分隔行。
  • 抓取工具的原始 JSON 残留会带出导航菜单、广告等垃圾内容，需整块删除。
  • 五页精编报告请使用手工 HTML 模板，不要直接脚本转整篇。
🔀 查看流程图
flowchart TD A[输入中文Markdown] --> B[解析Markdown] B --> C{表格列数?} C -->|>=11列| D[转为横向页面] C -->|8-10列| E[缩小字号] C -->|<8列| F[正常排版] D --> G[渲染PDF] E --> G F --> G G --> H[渲染自检] H --> I[输出PDF]

outline-mcp 生产力工具

用途

outline-mcp 用于让 AI 通过 MCP/API 连接自建 Outline 知识库（笔记系统），实现文档、集合、评论的读写。

核心概念

  • Outline：开源知识库，支持文档/集合/评论。
  • MCP：模型上下文协议，让 AI 工具能调用 API。
  • API key：ol_api_ 开头的密钥，只对生成它的实例有效，换域名会报 401。

常用命令（通过 /root/bin/outline_mcp.py）

  • 列出工具：outline_mcp.py tools
  • 列出集合：outline_mcp.py list_collections
  • 搜索文档：outline_mcp.py list_documents '{"query":"关键词"}'
  • 创建集合/文档：传入对应 JSON 参数（如名字、正文等）

注意事项

  • 先确认实例域名：自建 note 的 key 不能用于官方 app.getoutline.com。
  • MCP 握手顺序：先 initialize，再发 notifications/initialized，之后才能调用工具；响应是 SSE 格式，需逐行找 data: 前缀。
  • 工具参数名不统一：如删除文档用 id，不是 documentId；报 -32602 时看报错提示的字段名。
  • 文档正文不能以 # 开头，标题用 `
🔀 查看流程图
flowchart TD A[开始] --> B[配置API密钥] B --> C[连接MCP服务] C --> D{密钥有效?} D -- 否 --> E[报错退出] D -- 是 --> F[列出集合] F --> G[搜索文档] G --> H[读取/创建文档] H --> I[管理评论] I --> J[结束]

PDF 处理 生产力工具

PDF 技能

这个技能用来处理 PDF 文件，包括读取文本、合并拆分、旋转页面、加水印、创建新 PDF、填写表单、加密解密、提取图片，以及对扫描件做 OCR 识别。

核心概念

  • pypdf：Python 库，用于合并、拆分、旋转 PDF 页面等操作。
  • pdfplumber：Python 库，用于提取 PDF 里的文本和表格。
  • reportlab：Python 库，用于从零创建 PDF。
  • qpdf：命令行工具，可快速合并、拆分、解密 PDF。
  • poppler-utils：提供 pdftotext、pdftoppm 等命令，处理 PDF 转换和提取。
  • OCR：用 Tesseract 识别扫描件中的文字。

常用命令或步骤

  • 安装依赖：pip install pypdf pdfplumber reportlab；macOS 用 brew install poppler qpdf。
  • 合并/拆分 PDF：用 pypdf 写脚本，或直接用 qpdf --empty --pages ...。
  • 提取文本/表格：用 pdfplumber 的 extract_text() 和 extract_tables()。
  • 创建 PDF：用
🔀 查看流程图
flowchart TD A[接收PDF任务] --> B{操作类型} B -->|合并| C[合并多个PDF] B -->|拆分| D[按页拆分PDF] B -->|提取| E[提取文字表格] B -->|生成| F[创建新PDF] B -->|加密| G[设置密码] C --> H[输出结果PDF] D --> H E --> H F --> H G --> H

📁 研究 4 个技能

论文检索 研究

arXiv 论文检索技能

这个技能用于通过 arXiv 的免费 REST API 检索学术论文，支持按关键词、作者、分类或论文 ID 搜索，无需 API 密钥。

核心概念

  • arXiv：一个开放获取的学术预印本平台，涵盖计算机、数学、物理等领域。
  • REST API：一种网络接口，用 URL 即可请求数据，这里用 curl（命令行下载工具）调用。
  • Atom XML：API 返回的数据格式，可用脚本解析成易读内容。
  • 检索前缀：通过 all（全部字段）、ti（标题）、au（作者）、abs（摘要）、cat（分类）等限定搜索范围。
  • 布尔运算：支持 AND（与）、OR（或）、ANDNOT（排除）、精确短语。

常用命令或步骤

  • 按关键词搜索论文（最多返回 5 条）：

`bash

curl "https://export.arxiv.org/api/query?search_query=all:QUERY&max_results=5"

`

  • 根据论文 ID 查找特定论文：

`bash

curl "https://export.arxiv.org/api/query?id_list=2402.03300"

`

  • 查看论文摘要页面：用网络提取工具打开 https://arxiv.org/abs/2402.03300。
  • 阅读 PDF 全文：打开 https://arxiv.org/pdf/2402.03300。
  • 如果标题、作者是英文，直接用对应前缀，如 au:vaswani；关键词之间用 + 连接，如 all:transformer+attention。

注意事项

  • 所有请求不需要申请 API 密钥，也没有依赖库，简单直接。
  • 返回的 Atom XML 内容比较冗长，可以用 python 解析后打印成清爽的列表。
  • 搜索时默认是 AND 关系；要更精准，可组合使用前缀和布尔运算符。
  • 注意尊重 arXiv 的使用条款，避免高频、批量请求。
🔀 查看流程图
flowchart TD A[用户输入查询] --> B[构建API请求] B --> C[curl发送请求] C --> D{请求成功?} D -- 否 --> E[提示错误] D -- 是 --> F[解析Atom XML] F --> G{有结果?} G -- 否 --> H[提示无结果] G -- 是 --> I[展示论文信息]

deep-research-report-generation 研究

deep-research-report-generation

这个技能用于通过多智能体集群生成专业研究报告（技术分析、市场调研、产品评测等），尤其适合报告太单薄或想达到 Kimi 集群报告质量的情况。

核心概念

  • 核心目标：达到 Kimi 级深度，不是简单摘要。成熟报告通常 15-80KB，包含执行摘要、多级章节、场景分析、对比表格和引用来源。
  • 流水线：调研 → 蓝图 → 并行写章节 → 汇总 → QA → 交付。
  • 并行执行：用 kanban swarm（看板集群）原生子代理，每个 worker（工作代理）是完整 栗子云 代理，自带工作区、工具和上下文，而不是一次性 SSH/HTTP 调用
🔀 查看流程图
flowchart TD A[启动多智能体集群] --> B[调研员收集资料] B --> C[蓝图规划章节] C --> D[并行写作各章节] D --> E[组装报告] E --> F{QA检查} F -- 通过 --> G[生成PDF] F -- 不通过 --> D G --> H[发送Telegram]

grounded-citations 研究

grounded-citations

Ground answers and documents in cited, verifiable sources.

原文摘要：# Grounded Citations

Every claim taken from an outside source gets an inline numbered citation and a

Sources: list, Perplexity-style. A ledger script owns the url → [n] mapping

so the numbers and URLs come from retrieval, never from memory — the model only

ever emits small integers it was handed.

For high-stakes work the same ledger doubles as a fact-checking chain: verbatim

quotes are attac

🔀 查看流程图
flowchart TD A[开始] --> B[检索结果] B --> C[编号入账] C --> D[生成回答并引用] D --> E{高风险场景?} E -- 否 --> F[输出带Sources] E -- 是 --> G{逐字核对?} G -- 是 --> F G -- 否 --> H[标记未核实] H --> F

research-report-audit 研究

研究报告批量质量评估

本技能用于对一批 AI 生成的研究报告（如目录 /root/swarm/pmv2-*/deliverable-merged.md）进行多专家视角的质量审计、打分和统一改进建议。

核心概念
  • 批量审计：每个目录对应一份报告，按目录创建时间映射任务编号（最早=任务1）。
  • 专家视角：常用组合为 AI 技术架构师 / 证券主编 / 企业顾问，三者评分标准不同，可交叉验证。
  • 缺陷分类：参考 common-deliverable-defects.md 中的真实案例，按章节目录定位具体问题。
常用命令或步骤
  • 发现报告：ls -dt 排序，用 stat -c '%W %w' <目录> 获取创建时间；先过滤出含 deliverable-merged.md 的目录。
  • 提取结构：grep -n "^#" <文件> 快速获取全文章节骨架，发现结构缺陷。
  • 抽样精读：读执行摘要、各维度结论、参考文献、2-3 处数据密集段落；单份报告读 4-6 次即可。
  • 打分：5 个维度（格式/准确性/专业/细节/价值）各 1-10 分，每份报告满分 50，各专家独立打分。
  • 生成报告：用模板 expert-review-report.md 输出总览表、分专家评分及优缺点、统一改进计划（含 P0/P1/P2 优先级）。
  • 校验：用 python3 -c 重算所有平均分，确保表格与正文一致。
注意事项
  • 不要按行顺序全文通读，报告通常 100-300KB，应战略性抽样。
  • ls 的修改时间可能因合并操作失真，务必用目录创建时间。
  • 不是每个目录都有交付文件，先过滤再映射。
  • 评分差异是正常的，无需统一各专家观点。
🔀 查看流程图
flowchart TD A[开始] --> B[读取报告目录] B --> C[映射任务编号] C --> D[多专家打分] D --> E[汇总五大维度] E --> F[生成改进建议] F --> G{还有未评报告?} G -- 是 --> H[处理下一份] --> D G -- 否 --> I[结束]

📁 research-ops 1 个技能

research-ops research-ops

Research Ops 技能

用途

这个技能用来查询最新资料、比较选项、补充人物/公司背景，或把重复性查询变成持续监控。

核心概念

  • 基于当前公开证据研究，不靠旧记忆。
  • 区分：有来源的事实、用户给的证据、推断、建议。
  • 轻量优先：先用快速搜索，不够再升级到深度研究。

常用步骤

  1. 整理用户已给材料，分为“已有事实 / 需核实 / 待解决问题”。
  2. 判断任务：快速问答、对比、线索挖掘、重复监控。
  3. 选最轻路径：快速查询用 exa-search（网络搜索）；多源综合分析用 deep-research（深度研究）；要推荐用 market-research（市场研究）；找人或公司用 lead-intelligence（线索情报）。
  4. 报告时标明哪些是事实、哪些是推断，时效信息写具体日期。
  5. 如果任务会重复，考虑转成监控流程。

注意事项

  • 不要用旧记忆回答当前问题。
  • 如果本地代码或文档已有答案，别启动重型研究。
  • 本技能是协作流程，不替代具体研究工具。
🔀 查看流程图
flowchart TD A[整理已有材料] --> B[判断任务类型] B -->|快速事实| C[快速搜索] B -->|对比决策| D[深度研究] B -->|线索补充| E[定向查询] B -->|重复监控| F[转为监控] C --> G[生成报告] D --> G E --> G F --> G G --> H[区分来源与推断] H --> I[建议后续动作]

📁 scientific-thinking-scholar-evaluation 1 个技能

scholar-evaluation scientific-thinking-scholar-evaluation

技能简介

scholar-evaluation（学术评估）用于对论文、基金申请、文献综述等学术作品，按照统一标准进行结构化评价，并产出可用于修改的反馈。

核心概念

  • 评价对象：实证论文、理论文章、技术报告、综述、研究计划、学位论文章节、会议摘要等。
  • 评估范围：

- comprehensive（全面）：按全部维度打分

- targeted（定点）：只评方法或引用等某几个维度

- comparative（对比）：用同一套标准给多篇作品排序

  • 评分规则：每个适用维度打 1–5 分，5 为优秀、1 为差，不适用时标 N/A。

常用步骤

  1. 明确要评估的文献类型和范围。
  2. 按六个维度逐项打分：

- 问题与研究问题：是否清晰、有意义、范围明确

- 文献与背景：是否覆盖关键文献、有综合而非罗列

- 方法论：设计是否合理、能否复现、有无伦理说明

- 数据与证据：来源可信度、样本量、偏差处理

- 分析：统计/质性方法是否恰当、有无对照和稳健性检验

- 结果与解释：呈现是否清楚、结论有无过度推断

  1. 汇总分数，写出具体修改建议。

注意事项

  • 先确认是全面评估还是定点评估，避免漏评或过度评价。
  • 分数只是结构化参考，反馈要落在具体问题和改进建议上。
🔀 查看流程图
flowchart TD A[开始] --> B[确认作品类型] B --> C[选定评估范围] C --> D{评估范围?} D -- 综合 --> E[评估全部维度] D -- 定向 --> F[只评指定维度] D -- 对比 --> G[同标准评多篇排序] E --> H[汇总结分] F --> H G --> H H --> I[输出评价结果] I --> J[结束]

📁 软件开发 7 个技能

cluster-resource-scheduling 软件开发

用途

评估集群节点利用率、避免单节点满载、实现多任务并行与跨节点任务分发时，用这个技能快速判断调度方案。

核心概念

  • 远端节点 = 完整执行单元：每个装好 栗子云 的节点都内置了任务分发器、本地搜索引擎、技能和 API 密钥。通过 SSH 在远端执行 栗子云 kanban create，它就能自动在本地跑完任务，无需额外开发调度器。
  • 本机 worker 不能跨节点：本机 kanban worker 只用本地子进程，不会把任务派到远端。
  • 任务板隔离：每个任务用独立的 --board <slug> 参数创建，互不干扰；环境变量设板无效，板必须先用 栗子云 kanban boards create <slug> 建好。
  • 资源数据现成：用 栗子云-bridge /status 查节点的负载、内存、磁盘。

常用命令或步骤

🔀 查看流程图
```mermaid flowchart TD A[接收任务] --> B[查询各节点资源] B --> C{筛选可用节点} C -- 无 --> D[等待/重试] D -->

技能编写指南 软件开发

栗子云-Agent 技能编写指南（仓库内技能）

本技能用于在 栗子云 Agent

🔀 查看流程图
flowchart TD A[开始] --> B[选择技能位置] B --> C{仓库内?} C -->|否| D[用户本地创建] C -->|是| E[按类别建目录] E --> F[编写frontmatter] F --> G[编写结构内容] G --> H[校验SKILL.md] H --> I[结束] D --> I

multi-agent-cluster-reliability 软件开发

multi-agent-cluster-reliability

集群执行可靠性：并发竞态、API限流、LLM空输出重试、推理烧token。Swarm执行失败时用。

原文摘要：# Multi-Agent Cluster Reliability — 集群执行可靠性模式

多主机 + 多 Agent 并行集群（栗子云 delegate_task / SSH 栗子云 -z 分发）执行失败的调试模式库。

触发：集群任务大量失败、Agent 偶发空输出、并发执行全灭、LLM 返回空 content。

注：swarm-orchestrator（user-owned）讲编排流程；本 skill 讲执行可靠性坑位与修复模式。
M6 BUG 预防工具（/root/swarm/stock/bin/bug_prevention.py：BUG 检索/变更模式检查/预检清单/三态门禁/回归TC联动）用法 + 实现坑（中文正则边界/pytest收集import/pytest import 收集等）见 `references/bug-prevention-g
🔀 查看流程图
flowchart TD A[开始] --> B[获取集群状态] B --> C[检测Agent健康] C --> D{存在故障?} D -- 否 --> E[输出正常结果] D -- 是 --> F[定位故障节点] F --> G[分析故障原因] G --> H[执行修复操作] H --> I[重新验证集群] I --> C

multi-agent-orchestration-patterns 软件开发

本技能提供设计“虚拟公司”式多Agent集群的架构模式与容错知识，参考Kimi Swarm复刻经验。

核心概念

  • Kimi Swarm（模型内生编排）：任务分析器→拆解器→动态调度器→结果聚合器，模型自身即编排器，无需外部框架。
  • 虚拟公司角色模式：ChatDev链式、MetaGPT流水线、MacNet DAG并行、Puppeteer中央编排。
  • 编排类型：集中式（单控）、去中心化（自由协作）、分层（上下级）、联邦式（独立系统）。
  • 执行模式：spec模式（有明确交付物，直接执行）；plan模式（开放探索，先计划后执行）。

常用命令或步骤

  • 自动判定执行模式：swarm-run.py --mode "<任务文本>"
  • 任务分流（如判断股票任务）：优先用LLM语义判断（`llm_fast
🔀 查看流程图
flowchart TD A[接收任务] --> B{判定模式} B -->|spec| C[直接执行] B -->|plan| D[先计划再执行] C --> E[任务拆解] D --> E E --> F{LLM语义分流} F --> G[动态调度子Agent] G --> H[结果聚合] H --> I{是否容错} I -->|是| G I -->|否| J[输出最终结果]

任务规划 软件开发

plan

Write a markdown plan to .栗子云/plans/; no execution.

原文摘要：# Plan Mode

Use this skill when the user wants a plan instead of execution.

Core behavior

For this turn, you are planning only.

  • Do not implement code.
  • Do not edit project files except the plan markdown file.
  • Do not run mutating terminal commands, commit, push, or perform external actions.
  • You may inspect the repo or other context with read-only commands/tools when needed.
  • Your del
🔀 查看流程图
flowchart TD A[接收规划请求] --> B{需求是否明确} B -- 否 --> C[追问澄清] C --> B B -- 是 --> D[撰写计划文档] D --> E[保存到plans目录] E --> F[简要回复路径]

代码审查请求 软件开发

简介

这个技能用于代码提交前的自动审查：帮你检查代码改动、发现安全问题、跑测试和 lint，并自动修复小问题，防止有问题的代码进入仓库。

核心概念

  • 独立审查：不让写代码的智能体自己审查自己，换一个“新视角”更容易发现遗漏。
  • 基线意识：只阻止你改动新引入的问题，原有问题不阻塞提交。
  • 自动修复：发现小问题后会自动尝试修复，修复后重新验证。

常用步骤

  1. 获取改动：运行 git diff --cached 查看暂存区改动；如果为空，先让用户 git add 文件。
  2. 安全扫描：用 grep 检查新增代码中是否包含硬编码密钥、危险函数（如 eval、exec、os.system）、SQL 注入等模式。
  3. 运行测试和 lint：按项目类型执行 pytest、npm test、cargo test 等，记录改动前的失败数，只拦截新产生的错误。
  4. 独立审查：另起一个审查子代理，站在新角度检查代码逻辑、风格和潜在问题。
  5. 自动修复：对可自动处理的问题（如格式、简单安全风险）进行修补，然后重新运行验证。

注意事项

  • 文档、纯配置改动或用户明确说“跳过验证”时，不执行此流程。
  • 本技能审查的是自己的改动；如果是审查 GitHub 上别人提交的 PR，应使用 github-code-review 技能。
🔀 查看流程图
flowchart TD A[开始] --> B[安全扫描] B --> C[质量门禁] C --> D{检查通过?} D -- 否 --> E[自动修复] E --> B D -- 是 --> F[提交代码] F --> G[结束]

资源速度测试 软件开发

资源速度测试

这个技能用于在慢速下载前快速探测候选源并切换到最快的，避免在默认源上浪费时间。

核心概念

  • 候选源：默认源加 3-5 个附近或知名的公共镜像。
  • 探测：用小规模真实操作测速度，比单纯 ping/HEAD 更可靠。
  • 排序：按速度选最快的，留一个备用。

常用命令或步骤

  1. 列出候选源（默认 + 镜像）。
  2. 测速：curl -o /dev/null -s -w '%{time_total}' URL；最好直接跑一次小操作，如 docker pull mirror/alpine:3.18 再删除。
  3. 按测速结果选最快的。
  4. 切换配置：

- Docker：写 /etc/docker/daemon.json 加 registry-mirrors，重启 docker。

🔀 查看流程图
flowchart TD A[开始] --> B[识别候选源] B --> C[测量各源延迟] C --> D{是否存在可用源?} D -- 否 --> E[更换候选源] E --> C D -- 是 --> F[比较延迟] F --> G[选择最快源] G --> H[下载资源] H --> I[结束]

📁 swarm-orchestrator 1 个技能

swarm-orchestrator swarm-orchestrator

这个技能是做什么的

swarm-orchestrator 是一种“虚拟公司”式多 Agent 集群编排技能：把任务交给 CEO Agent，它设计公司工作流，调度多台主机的多个 Agent 并行干活，最后汇总交付并归档。

核心概念

  • CEO Agent：相当于项目经理，负责分析任务、设计角色分工和阶段、生成 plan.json 计划。
  • 阶段化执行：任务拆成多个阶段，每阶段可并行跑 3~6 个 Agent，阶段间通过目录传递产物。
  • 目录隔离：每个 Agent 只读自己的任务书和共享上下文，只写自己的输出目录，避免互相干扰。
  • 跨主机分发：重任务可通过 SSH 分发到其他主机执行（如 栗子云 -z）。

常用命令或步骤

  1. 澄清任务 → CEO 生成计划。
  2. 准备 skill → 安装并测试各 Agent 所需能力。
  3. 设计角色 → 每个 Agent 配 role-prompt.md 并试跑。
  4. 能力检查 → 探测网络和搜索能力，防止幻觉。
  5. 分阶段执行 → 用 delegate_task 批量并行调用子 Agent。
  6. 聚合交付 → 终轮 Agent 汇总所有产出，生成最终报告。
  7. 归档清理 → 运行 swarm-run.py --archive <task_id>，打包归档到 。

注意事项

  • 每个 Agent 只能读自己的 task.md，不要互相读目录，避免冲突。
  • 执行前必须做能力和网络检查，无网络的主机要跳过或换机。
  • 最终要交叉验证数据来源，保证报告真实性。
🔀 查看流程图
flowchart TD A[发起任务] --> B[CEO拆解规划] B --> C[生成计划文件] C --> D{需求确认?} D -- 否 --> B D -- 是 --> E[并行分发执行] E --> F[子智能体独立工作] F --> G[聚合阶段结果] G --> H[生成汇总报告] H --> I[归档清理]

📁 telegram 1 个技能

telegram-multi-bot-collab telegram

telegram-multi-bot-collab

配置/调试Telegram多Bot群协作。Bot互@不可行,用PM派单+角色汇报,含C方案与已知坑。

原文摘要：# Telegram 多 Bot 群协作运维

管理多个 Telegram Bot（每个由一台 栗子云 gateway 驱动）在一个群里的协作。

典型场景：栗子科技群 8 个 bot（PM + 7 角色），模拟公司群聊协作。

核心事实（决定架构）

  1. Bot 收不到其他 Bot 的消息（Telegram Bot API 硬限制，无论隐私模式/是否管理员）。

群内 @botB 人类可见可点击，但 Bot B 永远收不到 → 多 Agent 群协作不能靠 bot 互 @。

  1. TELEGRAM_REQUIRE_MENTION=true 不可靠：实测该组合下连"被 @ 的消息"也会被吞（bot 不响应）。

要约束"仅被@才响应"，用 channel_prompt 提示词约束，不要用 require_mention。

  1. **Bot 之
🔀 查看流程图
flowchart TD A[群消息触发] --> B[PM 编排调度] B --> C{节点支持 HTTP?} C -- 是 --> D[HTTP 派单 bridge] C -- 否 --> E[SSH 兜底派单] D --> F[执行 栗子云 chat] E --> F F --> G[节点 Bot 发送结果] G --> H[返回群聊]

📁 telegram-group-collab 1 个技能

telegram-group-collab telegram-group-collab

telegram-group-collab：群内多 Agent 协作协议

这个技能让 Telegram 群里的多个 Bot 像公司员工一样，通过互相 @ 来派单、转交和协作。

核心概念

  • 每个 Bot 代表一个角色，由各自的 LLM 驱动，在群内用 @username 互动。
  • 常见角色：PM（项目经理）、调研员、内容专家、方法论专家、撰写员、统计师、执行验证员。
  • 派单、转交、请求协助、质检重做，都靠 @ 对方实现。

常用步骤

  • 被 @ 时必须响应，确认任务、执行（用搜索工具）、汇报结果。
  • 派单：PM 在群里 @ 对应角色，给出明确任务和时限。
  • 转交：A 不擅长时 @ B 请求协助或转交，B 继续处理。
  • 汇报：完成后在群里 @ 派单人说明结果。

注意事项

  • 一次主要 @ 一个 Bot，可附带提醒其他。
  • 不重复做别人已完成的事，多看群上下文。
  • 遇到困难 @PM 汇报，不能擅自停止。
🔀 查看流程图
```mermaid flowchart TD A[项目经理群内派单] --> B[被点名者确认收到] B --> C{是否擅长此任务?} C -- 是 --> D[执行并向派单人汇报] C -- 否 --> E[转交其他同事协助] E --> B D --> F{质检是否通过?} F -- 通过 -->

📁 网页自动化 1 个技能

knowledge-wiki-publishing 网页自动化

本技能用于自动将 LLM（大语言模型）整理的知识库发布到 Cloudflare Pages（云托管平台）。

核心概念

  • 生成脚本负责把技能文档转换成静态页面（index.html + 时间线）。
  • 调用 LLM 生成中文摘要和 Mermaid 流程图，结果缓存，只转换变更的部分。
  • 根据白名单只展示实际使用过的技能，分类名和技能名全部翻译成中文。
  • 每日定时任务自动完成：生成 → 安全检查 → 部署 → 发邮件。

常用命令或步骤

  • 全量生成（LLM 转换缺失项）：python3 gen-wiki.py
  • 跳过 LLM、用缓存快速重建：python3 gen-wiki.py --skip-llm
  • 生成 + 部署 + 邮件：python3 gen-wiki.py --deploy
  • 手动部署：使用 wrangler 命令发布到 栗子云-wiki 项目。

注意事项

  • 部署依赖 vault 中的 Cloudflare 凭证，缺凭证时禁止用旧 token 凑合，应补录后再执行。
  • 即使缓存命中，也要重新做凭证脱敏，防止旧摘要泄露 IP、域名等敏感信息。
  • 页面必须全中文，流程图折叠
🔀 查看流程图
flowchart TD A[读取白名单技能] --> B{缓存缺失?} B -- 否 --> F[生成Wiki页面] B -- 是 --> C[脱敏凭证] C --> D[LLM生成摘要和流程图] D --> E[品牌替换安全检查] E --> F F --> G{凭证有效?} G -- 否 --> H[补录凭证] H --> G G -- 是 --> I[部署到Cloudflare Pages] I --> J[发送通知邮件]

📁 writing-plans 1 个技能

writing-plans writing-plans

这个技能用于在动手写代码前，根据规格说明或需求制定详细的实现计划，指导工程师逐步完成多步任务。

核心概念

  • 计划面向对代码库零上下文的工程师，假设他们需要所有细节，包括修改哪些文件、代码、测试和验证方法。
  • 任务拆分为小步骤（2-5分钟），遵循 TDD（测试驱动开发）：先写失败测试，再实现最少代码，运行通过后提交（commit）。
  • 遵守 DRY（不要重复自己）、YAGNI（你不需要它）原则，优先小文件，按职责拆分，遵循现有代码库模式。
  • 计划保存至 docs/superpowers/plans/YYYY-MM-DD-<功能名>.md（用户偏好优先）。

常用命令或步骤

  • 计划文档头部
🔀 查看流程图
flowchart TD A[接收需求规格] --> B[理解核心目标] B --> C[拆解实施步骤] C --> D[标注依赖顺序] D --> E[评估风险工作量] E --> F[编写实施计划] F --> G{计划是否确认} G -- 否 --> F G -- 是 --> H[输出可执行计划]