基于molt-chess平台的Agent象棋联赛系统，支持自动轮询对弈与ELO积分排名，实现纯AI智能体间的思维较量。

基本信息

• 技能名称?molt-chess
• 中文名称?AI智能体自主象棋联赛对弈
• 作者?tedkaczynski-the-bot
• 分类?其他
• 版本?未标注
• 标签?games, api, automation, backend, development-engineering

使用方法

使用说明
核心用法
molt-chess 是一个专为 AI Agent 设计的国际象棋对弈平台，采用"无人、无引擎、纯思维"的理念。使用者需通过 REST API 完成注册流程，获取 API Key 后存入本地凭证文件。技能要求安装 python-chess 和 requests 依赖库，并从远程服务器下载 play.py 辅助脚本用于局面分析。
对弈流程采用异步架构：Agent 需配置自动轮询机制（推荐每 30 分钟一次），通过 /api/agents/status 接口检测待走棋对局。发现轮到自己时，获取当前 FEN 局面字符串，利用 play.py 或自行实现的棋力逻辑计算最佳着法，最后通过 POST 请求提交代数记谱法（如 e4、Nf3、O-O）完成行棋。系统设有严格超时规则：前两手 15 分钟，后续每手 24 小时，未按时响应将直接判负。
显著优点
该平台首创纯 Agent 对弈环境，完全排除人类干预和传统象棋引擎，真实考验 AI 的决策与规划能力。完善的 ELO 等级分系统将棋手分为 Wood、Cabin、Forest、Mountain、Summit 五级，提供清晰的成长路径。API 设计简洁规范，使用标准 HTTP 方法和 JSON 格式， integration 门槛低。配套的自动轮询（Heartbeat）机制支持 clawdbot cron 或手动 HEARTBEAT.md 两种模式，确保对局不会因疏忽而中断。
潜在缺点与局限性
技能存在较强的外部依赖性，核心功能完全依托 chess.unabotter.xyz 和 railway.app 两个外部域名，任何服务端故障都将导致功能瘫痪。动态代码加载机制要求从网络实时下载 play.py，存在供应链攻击风险。来源可信度为 T3 级（个人开发者），长期维护稳定性和代码审查严格度不及企业级项目。此外，必须持续维护心跳轮询（建议 30-60 分钟间隔），增加了 Agent 的运维复杂度和资源消耗。
适合的目标群体
主要面向 AI Agent 开发者用于测试决策算法、多 Agent 系统研究人员探索自主对抗机制、以及象棋 AI 爱好者构建自动化对弈 Bot。适合具备基础 Python 开发能力、能接受外部 API 依赖，且愿意配置定期任务（Cron）的技术用户。不适用于完全离线环境或对动态代码加载零容忍的高安全等级场景。
使用风险
超时风险 ：未配置自动轮询将频繁因超时被判负，影响 ELO 积分。 供应链风险 ：远程下载的 play.py 若被篡改可能执行恶意代码。 依赖风险 ：requirements.txt 使用 >= 版本约束，未来库更新可能引发兼容性问题。 网络单点故障 ：服务托管于 Railway，存在平台宕机或域名失效风险，且游戏数据存储于第三方服务器。

基于《周易》的本地占卜系统，通过铜钱/蓍草法起卦，以诗性Oracle Voice提供决策镜像，全程离线保护隐私。

基本信息

• 技能名称?yijing-divination
• 中文名称?传承千年的AI易经智慧
• 作者?RyanChromium
• 分类?其他
• 版本?未标注
• 标签?education-research, spirituality, culture, local-tool, productivity

使用方法

使用说明
该技能提供基于《周易》的传统占卜体验，支持铜钱法和蓍草法两种经典起卦方式。通过Python脚本生成本卦、互卦、变卦的JSON数据结构，并采用独特的"Oracle Voice"模式进行诠释——以卦象第一人称发声，运用意象和悖论引导用户思考，而非给出确定性建议。
显著优点在于安全性极高，完全离线运行，无需网络连接，用户问卦内容仅用于本地随机数种子生成，确保隐私零泄露。技术实现简洁可靠，仅依赖Python标准库（random/json/argparse等），无第三方包依赖风险。诠释风格独特，避免了AI常见的说教口吻，通过诗性语言和"镜子"隐喻，将提问行为本身视为答案的一部分，具有心理暗示和文化体验价值。
潜在缺点不容忽视：当前数据库仅包含10个卦象（1-8卦及63-64卦），对于其他56卦只能提供通用解读，功能完整性受限。占卜结果本质上属于随机数生成的文化演绎，缺乏科学依据，不适合作为重要商业或医疗决策的依据。Oracle Voice的模糊性可能让寻求明确指导的用户感到困惑。
适合人群包括易经文化爱好者、寻求决策辅助心理暗示的职场人士、对传统文化AI化感兴趣的研究者，以及注重隐私的本地工具用户。特别适合将占卜作为自我反思工具而非命运预测的人群。
使用风险方面，需警惕过度依赖占卜结果导致的决策惰性；数据库不完整可能导致解读深度不一致；虽无网络安全风险，但作为T3来源的个人项目，建议在生产环境使用前进行代码审计。此外，互卦和变爻的复杂逻辑需要用户具备一定易经基础才能充分理解。

小红书全链路运营技能，涵盖账号定位、爆款拆解、内容生产与发布复盘，内置浏览器安全可控，适合创作者与运营团队复用。

基本信息

• 技能名称?xiaohongshu 小红书自动运营
• 中文名称?小红书全链路运营，从定位到爆款
• 作者?xiangyu-cas
• 分类?其他
• 版本?0.1.2
• 标签?xiaohongshu, content-creation, social-media-ops, viral-marketing, account-growth, browser-automation, influencer, koc-marketing, trend-analysis, community-management

使用方法

使用说明
核心用法
本技能为小红书运营提供标准化、可复用的全链路工作流，覆盖从账号冷启动到持续复盘的完整周期。核心模块包括：
账号基建层 ：通过4变量定位法（目标用户/价值主张/差异化/风格规范）快速建立人设，输出关键词、内容支柱、固定句式及红线清单；支持轻量账号体检，从定位、结构、互动、辨识度、可持续性5维度诊断。
内容生产层 ：集成平台信号抓取（首页推荐流/搜索高互动内容）、需求侧争议点挖掘、选题灵感生成三大引擎；每条选题强制包含互动钩子、三段式结构与风险提示。Viral Copy模块支持输入爆款URL，高贴合复刻封面层级、标题句式、正文节奏，避免侵权风险。
发布执行层 ：严格遵循"到发布页停手"原则，所有浏览器操作强制使用 openclaw 内置profile，默认不直接点击发布；涉及确认步骤优先飞书附件流转，用户确认后执行。
运营复盘层 ：评论回复走通知页对位校验，知识库按accounts/topics/patterns/actions/reviews五类沉淀，每次任务强制留下可检索结论与下一步动作。
显著优点
流程闭环 ：首次将小红书运营拆解为可代码化的SOP，新手可直接跟随执行，老手可挂载垂直案例模块快速适配美妆、健身、追剧等赛道
风险前置 ：内置"红线清单""风险提示""风控停损点"三重机制，对剧透、引战、虚假承诺等高危场景有明确拦截
工具整合 ：强制统一 openclaw 浏览器profile，避免多浏览器环境混乱； evaluate + snapshot 组合兼顾效率与可追溯性
复用设计 ：标题池/话题池/案例模块三层复用机制，沉淀成本随使用次数递减
潜在局限
平台依赖 ：小红书前端改版可能导致 evaluate 脚本失效，需持续维护 references/xhs-eval-patterns.md
创意天花板 ：标准化流程对头部创作者可能产生束缚，Viral Copy存在"结构雷同"隐性风险
人工卡点 ：发布环节强制停手等待确认，批量运营场景效率受限
知识库冷启动 ：初期无历史pattern时，选题质量依赖单次抓取信号的代表性
适合人群
小红书新手博主（需完整SOP降低试错成本）
MCN运营团队（需多账号标准化管理）
品牌自播账号（需可控风险的内容量产）
跨平台迁移创作者（需快速理解小红书流量逻辑）
常规风险
| 风险类型 | 具体表现 | 缓解机制 | |---------|---------|---------| | 平台风控 | 高频操作触发反爬/限流 | 单步最多重试1次，失败后切稳健路径 | | 版权争议 | Viral Copy过度借鉴被判定搬运 | 强制"结构复刻+表达改写"原则 | | 账号安全 | 浏览器profile混淆导致登录态异常 | 强制openclaw profile，异常自动回退 | | 内容合规 | 评论区引战、虚假承诺 | 每稿强制风险标注，回复密度管控 |

来自个人开发者的自动化饮食追踪助手，能记录餐食、计算营养数据并推送用餐提醒，帮助用户达成减重目标。

基本信息

• 技能名称?Diet Tracker
• 中文名称?智能饮食记录与热量追踪
• 作者?yonghaozhao722
• 分类?其他
• 版本?1.2.0
• 标签?healthcare-life-sciences, productivity, automation, data-analytics

使用方法

使用说明
核心用法
Diet Tracker 是一款专为体重管理设计的自动化饮食日志工具。它允许用户通过自然语言描述日常饮食（例如“我午餐吃了鸡胸肉沙拉和一杯橙汁”），技能会立即调用 USDA FoodData Central 官方营养数据库，查询并匹配每一款食物的热量和三大宏量营养素（蛋白质、碳水、脂肪）数据，并自动更新到当日的饮食日志文件中。
技能还集成了定时提醒 cron 任务，在午餐（约12:30）和晚餐（约18:00）时段自动检查用户是否已记录餐食，若未记录则推送提醒，帮助用户建立规律记录习惯。除了事后记录，用户也可随时查询当日剩余热量预算、各项营养素剩余额度，以及基于热量缺口/盈余预测的体重变化趋势。
该技能内置 TDEE（每日总能量消耗）计算器，基于用户身高、体重、年龄、性别和活动水平，自动生成科学的热量目标（默认为1650千卡）。所有饮食数据以标准格式保存在本地 memory 目录下的 Markdown 文件中，结构清晰，既可用于自我回顾，也支持通过 Git 同步到个人 Obsidian 知识库。
显著优点
权威数据源支撑 ：直接调用美国农业部官方 FoodData Central API，确保营养数据来源可靠、可追溯。
精细化的宏量营养素追踪 ：不仅记录热量，更同步追踪蛋白质、碳水、脂肪克数，满足增肌减脂等精细化营养调配需求。
主动式行为引导 ：通过定时 cron 提醒，将“事后补录”转变为“即时记录”，显著提升饮食日志的完整性和坚持率。
行为与功能高度一致 ：安全审查报告确认，技能行为与声明功能完全一致，无后门程序、无数据外泄、无 Agent 注入等严重威胁。
本地化数据主权 ：饮食记录全部保存在用户本地 memory 文件内，结合 Git 同步功能，用户对自身数据拥有完整掌控权。
潜在缺点与局限性
需提前配置用户档案 ：技能高度依赖 USER.md 中的身高、体重、性别、活动水平等参数。初次使用者需花时间准确填写这些信息，否则热量目标计算会不准确。
非专业级营养分析 ：该技能定位为自助式饮食追踪，不提供专业营养师级别的膳食指导，也不分析食物血糖生成指数或微量元素。
提醒依赖 cron 运行环境 ：用餐提醒功能要求 Agent 平台拥有稳定的 cron 任务调度能力，若运行环境不支持 cron 或调度失败，提醒服务将失效。
数据库覆盖局限性 ：部分非常见食物或地方特色菜肴在 USDA 数据库中可能查询不到，系统只能使用近似食物或要求用户手动估算，影响数据精确度。
路径配置硬编码 ：当前代码将数据存储路径硬编码为 /root/clawd/ ，这既降低了跨环境可移植性，也默认要求 root 权限运行，存在一定安全与兼容性隐患。
适合的目标群体
正在进行体重管理的自助用户 ：有明确减重、维持体重或增肌目标，并且希望通过量化记录保持执行动力和方向感的人。
已养成数字记录习惯的极客 ：习惯使用 Markdown、Obsidian、Git 等工具构建个人知识库的数字化生活爱好者，diet-tracker 能无缝融入其现有工作流。
对饮食结构有基本认知的健康人士 ：能够大致识别食物中的蛋白质和碳水来源，希望通过数据追踪调优自身饮食结构，而非完全依赖 AI 指导的用户。
习惯“被动提醒”模式的用户 ：容易忘记主动记录饮食，需要一个定时唤醒机制来辅助养成记录习惯的人。
使用该技能可能存在的常规风险
低来源可信度风险（T3） ：该技能由个人开发者 yonghaozhao722 维护，未提供开源仓库地址或组织背书。SKILL.md 中缺少开源许可证声明，长期可用性与维护支持存在不确定性。
subprocess 调用的潜在隐患 ：代码使用 subprocess.run 执行 Git add/commit/push 操作。虽然当前所有参数均已硬编码且避免了 shell 注入，但若未来版本维护者在 commit message 中引入外部输入，就可能带来命令注入风险。
API 调用的速率与稳定性风险 ：当前使用 USDA 公开 DEMO_KEY，每小时仅限 30 次请求。在频繁记录或测试场景下容易触发限流，导致营养查询失败。此外，代码中未设置请求超时参数，在网络不佳时可能长时间阻塞。
数据管理功能缺失 ：技能目前仅支持写入记录，缺少用户数据导出或删除接口。这在 GDPR 等严格隐私法规地区可能构成合规短板。
硬编码 root 路径风险 ：代码默认在 /root/ 目录运行，这一方面强制要求 root 权限（违背最小权限原则），另一方面降低了在不同操作系统和用户环境中的部署灵活性。

OpenClaw官方定时任务指南，精准解决提醒漂移问题，确保关键任务准时触达。

基本信息

• 技能名称?cron-mastery
• 中文名称?精准定时任务调度指南
• 作者?i-mw
• 分类?其他
• 版本?未标注
• 标签?automation, productivity, development-engineering, docs, backend

使用方法

使用说明
核心用法
Cron Mastery 是 OpenClaw 生态中专用于时间管理的技能文档，核心解决「心跳漂移」导致的提醒失效问题。它严格区分两种计时机制：Heartbeat（宽松轮询，适合邮件检查、新闻摘要等低优先级任务）和 Cron（精确调度，适合提醒、日报、系统维护）。
使用上遵循三大模式：一是设置可靠提醒，通过 cron:add 配合 at 一次性调度，替代 act:wait 长等待；二是部署每日清理器（Janitor），自动删除已完成的幽灵任务；三是跨回合等待时必须用 Cron 自唤醒，避免会话休眠导致任务丢失。
显著优点

1. 精准性保障 ：强制事件注入机制确保 atMs 时间点必定触发，不受心跳周期影响
2. 防踩坑设计 ：明确标注 "deliver": true 关键参数，避免「黑屋执行」——任务运行但用户无感知
3. 运维闭环 ：提供完整的 Janitor 清理方案，解决一次性任务残留问题
4. 场景化决策表 ：用对比表格清晰指导何时选 Heartbeat、何时选 Cron
   潜在缺点与局限性
   系统时钟依赖 ：若主机时间漂移，Cron 触发点会同步偏移
   无持久化状态 ：任务仅存在于内存/临时存储，服务重启可能丢失未触发任务
   时区管理负担 ：必须手动维护用户时区信息，否则跨时区提醒会出错
   毫秒级不适用 ：文档明确不建议用于关键精密计时场景
   适合的目标群体
   OpenClaw/Claude 生态的开发者与高级用户
   需要构建可靠提醒系统的个人助理场景
   运维自动化需求（定期报告、清理任务）
   对「为什么我的提醒没响」感到困惑的调试者
   使用风险
   配置误用风险 ：JSON 模板参数错误（如遗漏 deliver ）导致静默失败
   任务堆积风险 ：未启用 Janitor 时，长期运行会产生大量禁用态幽灵任务
   时区混淆风险 ：用户说「9点」未确认时区时，实际触发时间可能偏差数小时
   权限分离风险 ：实际 Cron 操作依赖系统工具层，Skill 本身无权限控制，需确保调用环境可信