awesome-codex-skills用 Clearout Automation 技能通过 Rube MCP 驱动 Clearout 客户反馈自动化【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills本文基于 awesome-codex-skills 仓库中的 clearout-automation 技能 展开讲解这个 Codex 技能如何通过 Composio 的 Rube MCP 网关对接 Clearout 平台完成搜索工具 → 管理连接 → 执行工具的标准化自动化闭环。读完本文你将掌握该技能的安装方式、Rube MCP 三个核心工具RUBE_SEARCH_TOOLS、RUBE_MANAGE_CONNECTIONS、RUBE_MULTI_EXECUTE_TOOL的完整调用参数以及避免硬编码工具 slug、会话复用、分页处理等六类常见陷阱的实践要点。技能定位composio-skills 家族中的一个成员awesome-codex-skills 是一个面向 Codex CLI 与 API 的实用技能Skills精选仓库。仓库中composio-skills/目录收录了大量按第三方 SaaS 平台划分的自动化技能clearout-automation是其中之一专门用于自动化 Clearout一个客户反馈与评论管理 SaaS 平台的操作。从目录结构看整个composio-skills/家族采用统一的 Rube MCP 接入模板每个工具包toolkit对应一个独立技能目录如composio-skills/composio-search-automation/、composio-skills/ably-automation/等其 SKILL.md 共享同一套先搜索工具、再管理连接、后执行工具的工作流骨架仅 toolkit 标识本技能为clearout与使用场景描述不同。理解这一点后本文讲的所有协议流程可以平移到家族中的其他技能。该技能文件由 YAML frontmatter 加正文两部分组成--- name: clearout-automation description: Automate Clearout tasks via Rube MCP (Composio). Always search tools first for current schemas. requires: mcp: [rube] ---name技能标识符也是技能在$CODEX_HOME/skills下安装后的目录名description触发描述。按照仓库 README.md 的说明Codex 通过匹配description来决定何时触发技能因此这里明确写入了 Always search tools first for current schemas 这一核心行为约定requires.mcp: [rube]声明该技能依赖名为rube的 MCP 服务端即下文要接入的 Rube MCP 网关。安装与加载技能本体只是 Markdown 指令包真正落地需要把技能目录放进 Codex 的技能加载路径。仓库提供了两条路径推荐使用内置 skill-installer 脚本安装。根据 README.md 的 Quickstart 和 skill-installer/SKILL.md 的说明可从本仓库直接按路径安装python skill-installer/scripts/install-skill-from-github.py \ --repo ComposioHQ/awesome-codex-skills \ --path composio-skills/clearout-automation脚本会把技能拉取到$CODEX_HOME/skills/skill-name默认~/.codex/skills/clearout-automation。若目标目录已存在脚本会中止安装。手动安装把composio-skills/clearout-automation/整个目录复制到$CODEX_HOME/skills/下。两种方式的共同后置动作是重启 Codex让它重新加载技能元数据。验证方式ls ~/.codex/skills确认目录存在head ~/.codex/skills/clearout-automation/SKILL.md检查 frontmatter 是否完整。需要说明的前提本技能本身只负责指挥 Codex 如何调用 Clearout并不自带任何凭证。运行它之前客户端必须已能访问 Rube MCP且当前账号下存在处于 ACTIVE 状态的 Clearout 连接——这两点在下文 Setup 章节展开。接入 SetupRube MCP 与 Clearout 连接技能文档给出的 Setup 部分定义了接入顺序这里完整保留并逐条解释获取 Rube MCP在 MCP 客户端配置中把https://rube.app/mcp添加为一个 MCP 服务端。文档特别强调 No API keys needed — just add the endpoint and it works即该端点无需预先配置 API Key认证流程被延迟到具体连接connection的授权环节。随后按 4 步完成验证与连接确认RUBE_SEARCH_TOOLS有响应证明 Rube MCP 已在客户端中可用这是requires: mcp: [rube]声明的运行前提调用RUBE_MANAGE_CONNECTIONStoolkit 指定为clearout触发/查询 Clearout 的账号连接若连接状态不是 ACTIVE按工具返回的授权链接auth link完成第三方授权——这一步在用户浏览器侧完成Agent 侧拿不到也不应索要任何令牌在任何工作流执行前再次确认连接状态显示 ACTIVE。这一步的设计意图是把工具层是否可达与账号层是否已授权解耦成两次显式检查任何一步失败都能被定位到具体环节而不是让工具执行时报出含糊的鉴权错误。工具发现为什么必须先调 RUBE_SEARCH_TOOLS该技能与写死一组 API 封装的传统集成方案最大的区别在于工具清单不是技能的一部分而是每次运行时动态发现的。技能正文在 Tool Discovery 一节给出了标准调用RUBE_SEARCH_TOOLS queries: [{use_case: Clearout operations, known_fields: }] session: {generate_id: true}参数含义queries使用场景查询列表。use_case用自然语言描述本次要做什么如 Clearout operations 或更具体的任务描述known_fields可补充已知的字段名线索未知时留空字符串session: {generate_id: true}让 Rube 生成一个新的会话 ID作为后续同一条工作流内所有调用的上下文锚点。返回值包含四样东西可用工具的 slug、输入参数 schema、推荐的执行计划execution plans、已知陷阱known pitfalls。也就是说工具长什么样、怎么调、哪里容易踩坑全部由服务端实时下发。这解释了 frontmatter 里 Always search tools first for current schemas 的由来——Clearout 工具包的 schema 会随服务端演进变化任何硬编码的 slug 或参数都可能过期而搜索结果永远是最新契约。核心工作流三步完成一次自动化技能正文的 Core Workflow Pattern 是全文的操作主干三步缺一不可Step 1: Discover Available Tools针对具体任务重新搜索并把会话延续到同一 sessionRUBE_SEARCH_TOOLS queries: [{use_case: your specific Clearout task}] session: {id: existing_session_id}注意与 Setup 阶段的首次调用相比这里用的是session: {id: existing_session_id}而非generate_id: true——即复用工作流开始时生成的会话 ID保证发现—执行发生在同一个上下文里。Step 2: Check Connection执行前对目标 toolkit 做一次连接状态检查RUBE_MANAGE_CONNECTIONS toolkits: [clearout] session_id: your_session_idtoolkits是数组形式本技能固定传[clearout]。返回状态必须为 ACTIVE否则回到 Setup 第 3 步补做授权。这一步的意义在于连接可能因授权过期、用户撤销等原因在两次会话之间失效执行前复检成本极低能避免整条工作流白跑。Step 3: Execute Tools使用批量执行工具落地具体操作RUBE_MULTI_EXECUTE_TOOL tools: [{ tool_slug: TOOL_SLUG_FROM_SEARCH, arguments: {/* schema-compliant args from search results */} }] memory: {} session_id: your_session_id三个要点tool_slug必须取自 Step 1 搜索结果arguments必须严格符合搜索结果下发的 schema字段名、类型逐字匹配tools是数组支持一次调用编排多个工具memory参数必须存在即使没有内容也要显式传空对象{}详见下文陷阱清单。整个链路串起来就是RUBE_SEARCH_TOOLS拿到 slug schema 执行计划→RUBE_MANAGE_CONNECTIONS确认 ACTIVE→RUBE_MULTI_EXECUTE_TOOL按 schema 执行三者共享同一个 session ID。已知陷阱六条避坑清单技能文档 Known Pitfalls 一节总结了六条经验全部继承如下并结合调用链说明其影响陷阱说明影响环节Always search first工具 schema 会变化禁止在未调用RUBE_SEARCH_TOOLS的情况下硬编码 slug 或参数Step 1Check connection执行前用RUBE_MANAGE_CONNECTIONS确认 ACTIVE 状态Step 2Schema compliance字段名与类型必须与搜索结果逐字一致不能猜字段Step 3Memory parameterRUBE_MULTI_EXECUTE_TOOL必须包含memory参数空时也传{}Step 3Session reuse同一条工作流内复用 session ID新工作流再generate_id: true生成新的全程Pagination检查响应中的分页 token持续翻页直到取完为止Step 3其中后两条对多轮自动化尤其关键session 复用保证了上下文连贯如多步依赖同一会话状态而分页处理则防止批量拉取类操作只拿到第一页数据就误判完成。快速参考表文档末尾的 Quick Reference 覆盖了五类操作入口可直接作为日常速查OperationApproachFind toolsRUBE_SEARCH_TOOLSwith Clearout-specific use caseConnectRUBE_MANAGE_CONNECTIONSwith toolkitclearoutExecuteRUBE_MULTI_EXECUTE_TOOLwith discovered tool slugsBulk opsRUBE_REMOTE_WORKBENCHwithrun_composio_tool()Full schemaRUBE_GET_TOOL_SCHEMASfor tools withschemaRef两点延伸说明基于文档表述Bulk ops走的不是RUBE_MULTI_EXECUTE_TOOL而是RUBE_REMOTE_WORKBENCH配合run_composio_tool()函数。从命名可以推断该入口面向需要多工具编排/代码式批量处理的重负载场景把执行逻辑放到远端 workbench 中运行Full schema一栏提示当搜索结果中某个工具带有schemaRef字段时说明其完整 schema 没有内联在搜索结果里需要再调RUBE_GET_TOOL_SCHEMAS拉取全文。这意味着RUBE_SEARCH_TOOLS的返回可能是摘要 引用形式遇到schemaRef不要直接凭摘要构造参数。小结这套模式的可复用性clearout-automation的价值不在于它封装了多少 Clearout 专属 API而在于它示范了 Codex 技能对接第三方 SaaS 的一种稳健范式技能只固化流程纪律先发现、再验连接、后执行、全程复用 session把易变的工具契约交给运行时发现机制。仓库 composio-skills 目录下数百个技能均采用同一模板因此本文所述的三步工作流、六条陷阱与五个速查入口同样适用于其中任意一个 toolkit——切换技能时只需要替换use_case描述与toolkits参数中的标识符本技能为clearout。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 19:02:12 · 阅读 1.2k awesome-codex-skills：用 Clearout Automation 技能通过 Rube MCP 驱动 Clearout 客户反馈自动化
awesome-codex-skills用 Clearout Automation 技能通过 Rube MCP 驱动 Clearout 客户反馈自动化【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills本文基于 awesome-codex-skills 仓库中的 clearout-automation 技能 展开讲解这个 Codex 技能如何通过 Composio 的 Rube MCP 网关对接 Clearout 平台完成搜索工具 → 管理连接 → 执行工具的标准化自动化闭环。读完本文你将掌握该技能的安装方式、Rube MCP 三个核心工具RUBE_SEARCH_TOOLS、RUBE_MANAGE_CONNECTIONS、RUBE_MULTI_EXECUTE_TOOL的完整调用参数以及避免硬编码工具 slug、会话复用、分页处理等六类常见陷阱的实践要点。技能定位composio-skills 家族中的一个成员awesome-codex-skills 是一个面向 Codex CLI 与 API 的实用技能Skills精选仓库。仓库中composio-skills/目录收录了大量按第三方 SaaS 平台划分的自动化技能clearout-automation是其中之一专门用于自动化 Clearout一个客户反馈与评论管理 SaaS 平台的操作。从目录结构看整个composio-skills/家族采用统一的 Rube MCP 接入模板每个工具包toolkit对应一个独立技能目录如composio-skills/composio-search-automation/、composio-skills/ably-automation/等其 SKILL.md 共享同一套先搜索工具、再管理连接、后执行工具的工作流骨架仅 toolkit 标识本技能为clearout与使用场景描述不同。理解这一点后本文讲的所有协议流程可以平移到家族中的其他技能。该技能文件由 YAML frontmatter 加正文两部分组成--- name: clearout-automation description: Automate Clearout tasks via Rube MCP (Composio). Always search tools first for current schemas. requires: mcp: [rube] ---name技能标识符也是技能在$CODEX_HOME/skills下安装后的目录名description触发描述。按照仓库 README.md 的说明Codex 通过匹配description来决定何时触发技能因此这里明确写入了 Always search tools first for current schemas 这一核心行为约定requires.mcp: [rube]声明该技能依赖名为rube的 MCP 服务端即下文要接入的 Rube MCP 网关。安装与加载技能本体只是 Markdown 指令包真正落地需要把技能目录放进 Codex 的技能加载路径。仓库提供了两条路径推荐使用内置 skill-installer 脚本安装。根据 README.md 的 Quickstart 和 skill-installer/SKILL.md 的说明可从本仓库直接按路径安装python skill-installer/scripts/install-skill-from-github.py \ --repo ComposioHQ/awesome-codex-skills \ --path composio-skills/clearout-automation脚本会把技能拉取到$CODEX_HOME/skills/skill-name默认~/.codex/skills/clearout-automation。若目标目录已存在脚本会中止安装。手动安装把composio-skills/clearout-automation/整个目录复制到$CODEX_HOME/skills/下。两种方式的共同后置动作是重启 Codex让它重新加载技能元数据。验证方式ls ~/.codex/skills确认目录存在head ~/.codex/skills/clearout-automation/SKILL.md检查 frontmatter 是否完整。需要说明的前提本技能本身只负责指挥 Codex 如何调用 Clearout并不自带任何凭证。运行它之前客户端必须已能访问 Rube MCP且当前账号下存在处于 ACTIVE 状态的 Clearout 连接——这两点在下文 Setup 章节展开。接入 SetupRube MCP 与 Clearout 连接技能文档给出的 Setup 部分定义了接入顺序这里完整保留并逐条解释获取 Rube MCP在 MCP 客户端配置中把https://rube.app/mcp添加为一个 MCP 服务端。文档特别强调 No API keys needed — just add the endpoint and it works即该端点无需预先配置 API Key认证流程被延迟到具体连接connection的授权环节。随后按 4 步完成验证与连接确认RUBE_SEARCH_TOOLS有响应证明 Rube MCP 已在客户端中可用这是requires: mcp: [rube]声明的运行前提调用RUBE_MANAGE_CONNECTIONStoolkit 指定为clearout触发/查询 Clearout 的账号连接若连接状态不是 ACTIVE按工具返回的授权链接auth link完成第三方授权——这一步在用户浏览器侧完成Agent 侧拿不到也不应索要任何令牌在任何工作流执行前再次确认连接状态显示 ACTIVE。这一步的设计意图是把工具层是否可达与账号层是否已授权解耦成两次显式检查任何一步失败都能被定位到具体环节而不是让工具执行时报出含糊的鉴权错误。工具发现为什么必须先调 RUBE_SEARCH_TOOLS该技能与写死一组 API 封装的传统集成方案最大的区别在于工具清单不是技能的一部分而是每次运行时动态发现的。技能正文在 Tool Discovery 一节给出了标准调用RUBE_SEARCH_TOOLS queries: [{use_case: Clearout operations, known_fields: }] session: {generate_id: true}参数含义queries使用场景查询列表。use_case用自然语言描述本次要做什么如 Clearout operations 或更具体的任务描述known_fields可补充已知的字段名线索未知时留空字符串session: {generate_id: true}让 Rube 生成一个新的会话 ID作为后续同一条工作流内所有调用的上下文锚点。返回值包含四样东西可用工具的 slug、输入参数 schema、推荐的执行计划execution plans、已知陷阱known pitfalls。也就是说工具长什么样、怎么调、哪里容易踩坑全部由服务端实时下发。这解释了 frontmatter 里 Always search tools first for current schemas 的由来——Clearout 工具包的 schema 会随服务端演进变化任何硬编码的 slug 或参数都可能过期而搜索结果永远是最新契约。核心工作流三步完成一次自动化技能正文的 Core Workflow Pattern 是全文的操作主干三步缺一不可Step 1: Discover Available Tools针对具体任务重新搜索并把会话延续到同一 sessionRUBE_SEARCH_TOOLS queries: [{use_case: your specific Clearout task}] session: {id: existing_session_id}注意与 Setup 阶段的首次调用相比这里用的是session: {id: existing_session_id}而非generate_id: true——即复用工作流开始时生成的会话 ID保证发现—执行发生在同一个上下文里。Step 2: Check Connection执行前对目标 toolkit 做一次连接状态检查RUBE_MANAGE_CONNECTIONS toolkits: [clearout] session_id: your_session_idtoolkits是数组形式本技能固定传[clearout]。返回状态必须为 ACTIVE否则回到 Setup 第 3 步补做授权。这一步的意义在于连接可能因授权过期、用户撤销等原因在两次会话之间失效执行前复检成本极低能避免整条工作流白跑。Step 3: Execute Tools使用批量执行工具落地具体操作RUBE_MULTI_EXECUTE_TOOL tools: [{ tool_slug: TOOL_SLUG_FROM_SEARCH, arguments: {/* schema-compliant args from search results */} }] memory: {} session_id: your_session_id三个要点tool_slug必须取自 Step 1 搜索结果arguments必须严格符合搜索结果下发的 schema字段名、类型逐字匹配tools是数组支持一次调用编排多个工具memory参数必须存在即使没有内容也要显式传空对象{}详见下文陷阱清单。整个链路串起来就是RUBE_SEARCH_TOOLS拿到 slug schema 执行计划→RUBE_MANAGE_CONNECTIONS确认 ACTIVE→RUBE_MULTI_EXECUTE_TOOL按 schema 执行三者共享同一个 session ID。已知陷阱六条避坑清单技能文档 Known Pitfalls 一节总结了六条经验全部继承如下并结合调用链说明其影响陷阱说明影响环节Always search first工具 schema 会变化禁止在未调用RUBE_SEARCH_TOOLS的情况下硬编码 slug 或参数Step 1Check connection执行前用RUBE_MANAGE_CONNECTIONS确认 ACTIVE 状态Step 2Schema compliance字段名与类型必须与搜索结果逐字一致不能猜字段Step 3Memory parameterRUBE_MULTI_EXECUTE_TOOL必须包含memory参数空时也传{}Step 3Session reuse同一条工作流内复用 session ID新工作流再generate_id: true生成新的全程Pagination检查响应中的分页 token持续翻页直到取完为止Step 3其中后两条对多轮自动化尤其关键session 复用保证了上下文连贯如多步依赖同一会话状态而分页处理则防止批量拉取类操作只拿到第一页数据就误判完成。快速参考表文档末尾的 Quick Reference 覆盖了五类操作入口可直接作为日常速查OperationApproachFind toolsRUBE_SEARCH_TOOLSwith Clearout-specific use caseConnectRUBE_MANAGE_CONNECTIONSwith toolkitclearoutExecuteRUBE_MULTI_EXECUTE_TOOLwith discovered tool slugsBulk opsRUBE_REMOTE_WORKBENCHwithrun_composio_tool()Full schemaRUBE_GET_TOOL_SCHEMASfor tools withschemaRef两点延伸说明基于文档表述Bulk ops走的不是RUBE_MULTI_EXECUTE_TOOL而是RUBE_REMOTE_WORKBENCH配合run_composio_tool()函数。从命名可以推断该入口面向需要多工具编排/代码式批量处理的重负载场景把执行逻辑放到远端 workbench 中运行Full schema一栏提示当搜索结果中某个工具带有schemaRef字段时说明其完整 schema 没有内联在搜索结果里需要再调RUBE_GET_TOOL_SCHEMAS拉取全文。这意味着RUBE_SEARCH_TOOLS的返回可能是摘要 引用形式遇到schemaRef不要直接凭摘要构造参数。小结这套模式的可复用性clearout-automation的价值不在于它封装了多少 Clearout 专属 API而在于它示范了 Codex 技能对接第三方 SaaS 的一种稳健范式技能只固化流程纪律先发现、再验连接、后执行、全程复用 session把易变的工具契约交给运行时发现机制。仓库 composio-skills 目录下数百个技能均采用同一模板因此本文所述的三步工作流、六条陷阱与五个速查入口同样适用于其中任意一个 toolkit——切换技能时只需要替换use_case描述与toolkits参数中的标识符本技能为clearout。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考