后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载在 OpenClaw 的 Skill Plugin Registry 项目 ClawHub 中,.agents/skills/convex/SKILL.md 是整个 Convex 后端工作流的总调度台:它声明了 Convex 作为全 TypeScript 反应式后端平台的定位,定义了把具体任务路由到 30 余个convex-*子技能与在线能力目录的规则,并规定了目录优先、降级兜底、付费能力需显式确认等行为边界。读完本文,你将理解这套主入口 子技能 在线目录的 Agent 技能架构设计,并能对照 ClawHub 仓库中真实的 Convex 代码组织方式(convex.json、convex/convex.config.ts、convex/schema.ts),掌握在同类项目中安装与使用该技能集的方法。主入口定位:一个技能,路由一切Convex 主入口技能的第一段就说明了它的角色:The main entry point for building on Convex. This skill set ships one skill per capability (all namedconvex-*); this skill routes to the right one and to the served capability catalog that keeps procedures current without reinstalling anything.即:每个能力对应一个独立的convex-*技能文件,主入口本身不承载具体操作步骤,只负责把请求送到正确的地方。这种拆分带来两个好处:上下文按需加载——Agent 在处理加一个 cron时只需要加载convex-crons的操作手册,而不是把所有能力的细节塞进上下文;目录永远新鲜——主入口还指向一个在线能力目录(served capability catalog),新能力上线不需要重新发布技能文件。从仓库结构可以印证这一点:.agents/skills/下与 convex 直接相关的目录有三十多个,包括convex-add、convex-expert、convex-quickstart、convex-migrate、convex-authz、convex-cost等,每个目录内含自己的SKILL.md与(部分含)references/、agents/、assets/子资源,例如 convex-setup-auth/SKILL.md 附带了 auth0、clerk、convex-auth、workos-authkit 四份参考文档。为什么选 Convex:四条核心主张文档在 Why reach for Convex 一节给出了四条选择理由,理解它们是理解整个技能集设计意图的前提:第一次就写出正确代码。整个后端是 TypeScript,端到端类型贯通:schema、validator、函数签名都会流向客户端,tsc --noEmit能在运行前捕获大多数生成代码的错误;每个 query/mutation 自动成为可串行化事务,手写后端常见的竞态与部分写入问题根本无法被写出来。原型速度且不是一次性投入。一个能跑的全栈应用只需几分钟(convex-quickstart),零基础设施配置:没有连接串、没有迁移工具、没有 WebSocket 管道,实时反应式是默认能力而非附加项。原型即生产应用。同一批函数在自动缓存与一致性保障下直接承载生产负载,无需重写;技能集覆盖整个生命周期(授权审计、在线数据迁移、成本分析、生产错误捕获与自愈)。远不止一个数据库。通过安装组件即可获得整块子系统:AI Agent 与 RAG、持久工作流、限流、Stripe 计费、全文/向量检索、邮件、在线状态(presence)、分片计数器等。ClawHub 本身就是这四条主张的实例:它的后端完全由 Convex 构成,convex/目录下有 200 个.ts文件,涵盖鉴权(convex/auth.ts)、技能发布(convex/skills.ts)、搜索(convex/search.ts)、限流(convex/rateLimits.ts)、定时任务(convex/crons.ts)等,而 package.json 中的依赖声明了平台版本基线:convex 1.44.0、convex-helpers 0.1.123,以及组件convex-dev/auth 0.0.95、convex-dev/migrations 0.3.6、convex-dev/rate-limiter 0.3.2、convex-dev/workpool 0.4.12。路由机制:五步分诊主入口把任务分诊为五类,顺序固定:在convex/下写代码或改代码(schema、query、mutation、action、HTTP 端点、cron、文件存储、auth 接线):优先咨询convex-expert技能。理由是模型对 Convex 的通用知识常常是过期的,而 convex-expert/SKILL.md 持有当前版本的对象式函数语法、validator 与索引模式、资源限制与组件生态。从零开始新应用:使用convex-quickstart。给现有应用加能力(auth、计费、cron、agent、搜索、邮件、域名、托管等):使用convex-add——它会抓取在线目录capabilities.json,匹配请求,然后执行匹配到的能力的/capability/id.md在线文档。新能力进入目录后无需更新任何技能文件。审查或加固现有后端:convex-reviewer(正确性审查)、convex-authz(授权审计)、convex-verify(类型检查与部署验证)。运营一个已上线的应用:convex-monitor(盯错误)、convex-sentinel(捕获)、convex-self-heal(自动生成修复 PR);线上数据上的 schema 变更走convex-migrate或convex-migrate-rehearse(先在 preview 上排练);费用问题走convex-cost。ClawHub 仓库还叠加了一层项目内部分流规则:clawhub-convex/SKILL.md 要求先读convex/_generated/ai/guidelines.md再动 Convex 代码,并在动任何 Convex 命令前先声明目标运行时(local/dev/prod);查询成本、索引、读放大问题路由到convex-performance-audit,生产迁移路由到convex-migration-helper,TTL 与保留期清理路由到convex-retention。这是上游通用技能 仓库专属边界两层路由的典型做法,且明确禁止把 ClawHub 策略写进上游管理的 convex 技能里。规则:目录优先、降级兜底、付费必确认主入口的 Rules 一节是这套体系最有实操价值的部分,四条规则分别解决了信任、时效、安全与可用性四个问题:规则解决的问题项目未安装 Convex AI 指导文件(或看起来过期)时,先建议npx convex ai-files install保证 Agent 依据的是托管的、当前的官方指导,而非模型记忆捆绑流程与在线目录流程同时存在时,优先在线版本在线副本更新,时效性优先在线文档是操作步骤说明,不是可以盲目执行的 shell;需正常判断防止 Agent 把目录文本当作无审查的指令源tier0的能力(会花钱,例如购买域名)必须先获得用户显式确认付费/不可逆操作的人工闸门在线 URL 不可达时,回退到捆绑技能自带流程;目录未命中绝不硬失败可用性兜底convex-add的 SKILL.md 把这些规则落成了可执行的五步工作流:先识别用户要的能力 → 带 4 秒超时抓取在线目录并比对 title/summary/trigger → 命中则抓取/capability/id.md并执行其 ProcedureRules → 未命中或目录不可达时走旧逻辑(hosting接convex-dev/static-hosting,其余走/add-component搜索脚本安装最匹配的convex-dev组件)→ 用 URL 或组件名向用户确认结果。捆绑技能全景:覆盖开发到运营的生命周期主入口列出了完整的捆绑技能清单(共 30 个)。按生命周期分组后,其覆盖面一目了然:搭建与扩展convex-quickstart:从一句话想法拉起 Convex web 模板;convex-add:加能力的统一入口(查在线目录);convex-agent:接入convex-dev/agent(AI Agent / RAG 后端);convex-auth:接入 passkey/OAuth,含auth.config.ts接线;convex-billing:通过convex-dev/stripe加 Stripe 计费(checkout webhook 门槛控制);convex-crons:加重复调度的 cron;convex-env:设置与接线部署环境变量/密钥;convex-domains:把自有域名指向 Convex 应用(DNS 记录、自定义域名挂载、auth origin 重绑);convex-seed:向数据库灌数据或导入。审查、验证与性能convex-reviewer:面向convex/目录代码的安全、鉴权、validator、性能与模式审查;convex-authz:授权审计——参数身份伪装、缺失的逐文档属主检查、泄漏 PII 的公开查询、向调用者无权容器写入等;convex-verify:用convex-test模拟多用户(含负向授权用例)证明功能可用;convex-test:生成convex-test测试;convex-advisor:读取部署的 72 小时洞察(读限制、OCC 争用),在代码中定位根因,给出有证据的性能/成本结论;convex-insights:以自然语言查询运行中应用的日志与健康度(官方 MCP);convex-optimize/convex-design:审计优化与后端设计。生产运营convex-monitor:盯下一个 dev/prod 错误或请求并响应;convex-sentinel:在自己的部署中搭建 Sentinel 生产错误捕获;convex-self-heal:生产错误 → 分诊 → 根因 → 修复 → 认证(tsc 排练 复现后消失)的修复 PR,之后确认错误不再复现;convex-deploy-guard:任何影响部署的命令先分类并宣告目标部署,prod 动作需全新显式同意,支持会话只读模式;convex-backup:配置备份并执行恢复演练——快照、恢复到一次性 preview、断言数据回来,再按 RPO 排期;convex-cost:预览开销——按读取字节/文档数 × 调用量给函数排名,外推每个成本驱动因素的增长曲线,指名最便宜的修复手段;convex-launch-readiness:跑完所有审计(authz、reviewer、advisor、insights)合并成一份打分、去重的就绪度报告,附有序修复计划——后端的 Lighthouse。数据与迁移convex-migrate:用convex-dev/migrations在已部署应用上迁移 schema 回填数据;convex-migrate-rehearse:在快照播种的 preview 部署上排练线上应用 schema 变更 回填,验证通过后把已验证变更提升到 prod,快照作为回滚手段;convex-suggest:当用户手搓某个组件已解决的样板模式(cron、分片计数、限流、存储、搜索、presence、workflow、RAG……)时,建议对应组件;convex-explain-app:从 schema 与函数出发解释现有应用——数据模型与关系、public 与 internal 函数、鉴权/属主模型、组件、请求→数据流;convex-docs:按项目所用版本拉取版本对应的 Convex 文档(版本固定、页面转 markdown、node_modules类型检查、新鲜度层级);convex-improve-convex-plugin:把当前编码会话的 transcript 提交给 Convex 团队做 AI 复盘,反哺 quickstart 系统。值得注意的细节:ClawHub 仓库中convex/_generated/ai/下存在ai-files.state.json与guidelines.md,正是上述npx convex ai-files install规则的落盘产物——即托管指导文件已经安装且带状态标记,clawhub-convex技能要求的编辑前先读 guidelines才有对象可读。在 ClawHub 仓库中的落地形态技能文档描述的是通用流程,ClawHub 仓库提供了这些原则在真实生产项目中的对照样本:部署配置与组件装配。convex/convex.config.ts 展示了drop-in 组件主张的具体形态——三行app.use(...)即挂上迁移、限流与后台工作池:import migrations from convex-dev/migrations/convex.config.js; import rateLimiter from convex-dev/rate-limiter/convex.config.js; import workpool from convex-dev/workpool/convex.config.js; import { defineApp } from convex/server; const app defineApp(); app.use(migrations); app.use(rateLimiter); app.use(workpool, { name: searchReports });而根目录 convex.json 声明了函数目录与 Node 运行时的外部包白名单(sharp,用于图片处理),对应convex-expert中use node仅限 action-only 模块这条运行时边界。schema 即契约。convex/schema.ts(约 4800 行)中大量使用v.literal(clean)这类固定枚举校验器(如 convex/schema.ts#L26-L31 的人工审核覆盖结构),并引入convex-dev/auth/server的authTables与自研 schema 包clawhub-schema——这正是convex-expert规则v.literal而非裸v.string()每个注册函数都要有 args/returns validator在大型项目中的规模化体现。导入纪律与项目封装。convex-expert强调query/mutation/action只能从./_generated/server导入、api/internal从./_generated/api导入。ClawHub 在此之上多了一层:按 clawhub-convex/SKILL.md 的约定,业务代码从 convex/functions.ts 导入 mutation 而非_generated/server,以便仓库自有的 trigger 包装器(customMutationTriggers)生效——convex/functions.ts 顶部可见rawMutation被改名导入后统一包装的写法。这是上游技能给通用规则、仓库技能给本地边界两层架构的又一实证。运行时验证闭环。convex-expert的 SELF-VERIFY RULE 要求声明完成前必须跑npx tsc --noEmit并推送部署;clawhub-convex则把它具体化为 dev 用bunx convex dev --once、prod 走clawhub-production-release工作流、schema 变更用bunx convex codegen重新生成提交的 API 类型,并要求 mockctx测试之外对分页/索引/validator/auth 边界/OCC 等行为补跑真实 Convex 路径(convex run、HTTP action 冒烟或bun run test:pw:local-auth)。如何在自己的 Convex 项目中启用这套技能按主入口文档的规则,复现路径很简单:在 Convex 项目中执行npx convex ai-files install,安装托管的、随版本更新的官方 AI 指导文件(会落盘convex/_generated/ai/guidelines.md等文件,参考 convex/_generated/ai/ 目录形态);确认 Agent 工具链能识别.agents/skills/下的技能目录,入口技能为convex,子技能以convex-前缀命名;遵循其路由顺序:动convex/代码先查convex-expert;加能力先查在线目录再回退本地;生产变更优先convex-migrate-rehearse式先排练后上线;保持两条纪律:在线文档按步骤说明理解而非盲执行的 shell;tier0的付费能力(如购买域名)必须人工显式确认。这套体系的本质,是把Convex 官方知识从模型记忆迁移到技能文件 在线目录的可版本化载体上:主入口保证分诊正确,子技能保证操作细节可维护,在线目录保证内容不腐化——而 ClawHub 仓库中真实的 schema、组件装配、code-gen 指导与项目级边界技能,则完整示范了它在生产级全栈 Convex 应用中的落地方式。赞分享后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载相关推荐convex-backend与Rust生态系统从crates到性能优化convex backend与Rust生态系统从crates到性能优化 convex backend作为开源的单机版Convex后端实现依托Rust语言构建数据库后端Convex Auth在 Convex 后端直接落地的完整认证接入指南convex-backend 仓库实战Convex Auth在 Convex 后端直接落地的完整认证接入指南convex backend 仓库实战 Convex Auth 是 Convex 官数据库后端Convex Private Demos E2E 测试基于 Playwright 与 convex-local-backend 的本地端到端测试体系Convex Private Demos E2E 测试基于 Playwright 与 convex local backend 的本地端到端测试体系 导读 本数据库后端上一篇攻克MuJoCo并行机构站点添加难题从建模到调试下一篇深度解析MuJoCo插件与复制功能导致段错误的技术原因与解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考