Awesome Codex Skills：Codex CLI 的技能宝库，让 AI 代理真正替你干活

快速信息卡

GitHub 仓库: composio-community/awesome-codex-skills

指标	数值
⭐ Stars	16,717
🍴 Forks	1,644
📜 License	无
💻 主要语言	Python
📅 最后更新	2026-07-26

数据核实于 2026-09-30。仓库已从 ComposioHQ 组织迁至 composio-community，旧链接会自动重定向，本文统一用新地址。

Codex CLI 默认只输出文本。Awesome Codex Skills（以下简称 ACS）把它改造成能调外部 API、操作 GitHub、发 Slack、写 Notion 的执行器，靠的是一套"描述触发 + 按需加载"的 Skill 模块。

ACS 适合已经在用 Codex CLI 且希望它直接产出工单、消息、文档的人；如果只是想让模型回答问题，引入 Skills 反而增加维护成本。本文回答三个问题：Skill 的触发与执行边界、哪个 Skill 该先装、什么场景不该上 ACS。

目录

• Skill 是什么
• 系统地图
• 快速上手
• Skill 全景图
• 任务流案例
• 四个高频 Skill
• 构建自己的 Skill
• 适用场景横向对比
• 与 MCP 的关系
• 采用建议
• 自测题
• 进阶路径
• 常见问题

一、Skill 是什么：描述触发，按需加载

一个 Skill 是一个独立文件夹，以 SKILL.md 为入口。Codex 启动时只读取 frontmatter 里的 name 和 description，用来判断何时触发；触发后才加载 body 里的执行步骤。这样设计是为了让上下文保持轻量——装得再多，启动时进上下文的也只是每个技能的一小段描述；代价是描述写不好就触发不了，README 也专门提醒贡献者测试元数据是否超出上下文预算。

文件夹结构如下：

skill-name/
├── SKILL.md          # 必选：指令 + YAML frontmatter
├── scripts/          # 可选：确定性辅助脚本
├── references/       # 可选：长文档，仅在需要时加载
└── assets/           # 可选：模板或静态资源

SKILL.md 的最小可用形态：

---
name: my-skill-name
description: 这个技能做什么，以及何时触发。
---

# My Skill Name

这里写交给 Codex 的执行步骤。

设计上的关键约束：description 决定触发，body 决定执行。描述写得越具体（“当用户要求把会议转录稿转成 action item 时触发”），Codex 越不会误触发；描述越泛（“处理会议相关任务”），多个 Skill 之间会打架。

除了等 description 自动命中，也可以在对话里直接点名技能，让 Codex 把它纳入考虑——这是 README 给出的两种触发方式。

二、系统地图：四条主线如何分工

ACS 里有四条容易混淆的主线，边界先拆清楚：

前三条是 ACS 自带的闭环，第四条通过 connect Skill 桥接到 Composio 生态。这条边界决定了 ACS 的能力上限：ACS 本身不提供 Slack API，它只告诉 Codex"何时该调 Composio CLI"。

三、快速上手：两种安装方式

方式一：Skill Installer（推荐）

git clone https://github.com/composio-community/awesome-codex-skills.git
cd awesome-codex-skills

# 安装单个技能到 ~/.codex/skills/（默认位置）
python skill-installer/scripts/install-skill-from-github.py \
  --repo composio-community/awesome-codex-skills \
  --path meeting-notes-and-actions

安装完毕后重启 Codex，新技能即生效。在对话中自然描述任务，Codex 自动匹配触发。

方式二：手动安装

1. 复制目标技能文件夹到 $CODEX_HOME/skills/（默认 ~/.codex/skills/）
2. 重启 Codex 使其重新加载元数据
3. 开始对话

装没装好，两条命令就能确认：ls ~/.codex/skills 看文件夹在不在，head ~/.codex/skills/<skill>/SKILL.md 看元数据是否完整。

skill-installer 的内部逻辑就两步：从 GitHub 拉取指定 --repo + --path 下的文件夹，移动到 $CODEX_HOME/skills/<skill-name>/。维护自有技能库时，提供这两个参数就能分发；不满意默认位置，安装后手动搬运即可。

四、Skill 全景图：五大分类总览

ACS 将技能分为五大分类，根目录现有 48 个技能文件夹（核实于 2026-09-30）。下表列出每个分类下有代表性的技能及能力，能力描述以仓库 README 和各技能的 SKILL.md 为准。

1. 开发与代码工具（Development & Code Tools）

2. 生产力与协作（Productivity & Collaboration）

3. 通信与写作（Communication & Writing）

4. 数据与分析（Data & Analysis）

5. Meta 与工具（Meta & Utilities）

根目录之外还有一个容易看漏的目录：composio-skills/，里面有 830 多个按应用自动生成的 *-automation 技能文件夹（如 slackbot-automation），每个只有一份 SKILL.md，走 Rube MCP（rube.app/mcp）通道调用对应应用的 API。这些是批量生成的"连接器"，与根目录的手写精选技能不是一回事；一般用户装根目录的精选技能就够了。

五、任务流案例：一条 Slack 消息如何流过系统

四条主线在真实任务里如何配合，看一次完整流程：

1. 用户输入：“在 Slack 的 #release 频道发一条说 v1.2.3 上线成功”
2. 触发匹配：Codex 扫描所有已安装 Skill 的 description，命中 connect 的描述（涉及 Slack 消息发送）
3. 加载 body：connect/SKILL.md 的执行步骤被加载进上下文，告诉 Codex 该调 Composio CLI 的哪个命令
4. 执行外部能力：Codex 执行 composio execute SLACK_SEND_MESSAGE -d '{"channel": "release", "text": "v1.2.3 上线成功"}'，Composio 平台代为调用 Slack API
5. 返回结果：Slack 消息 ID 回到 Codex，Codex 向用户确认发送成功

整个流程里，ACS 只负责第 2、3 步（触发与执行引导），第 4 步的实际 API 调用由 Composio 平台完成。这就是为什么 connect 必须配合 Composio CLI 使用——ACS 自己不持有 Slack token。

六、四个高频 Skill 的能力与代价

6.1 connect：接入外部应用的桥

connect 是 ACS 里覆盖面最大的技能：通过 Composio CLI，Codex 可以直接调 1000 多个应用的 API，输出的是已发送的消息、已创建的 issue 这类真实副作用，操作步骤文本只是中间产物。

支持的生态包括：

• 协作工具：Slack、Discord、Notion、Linear、Jira
• 代码平台：GitHub、GitLab、Bitbucket
• 云服务：AWS、Stripe、Supabase、Vercel
• 数据平台：Datadog、LangSmith、Helium（实时新闻 + 市场数据）

安装后，Codex 能执行类似下面的任务：“在 Slack 发一条消息说上线成功”、“在 GitHub 创建一个 issue”、“在 Notion 更新这篇文档的状态”。

这些任务有一道前置工序：先装 Composio CLI 并登录（composio login，会打开浏览器认证），再对每个要用的应用做一次授权（composio link slack、composio link github）。OAuth 走一遍后连接持久化，之后的调用不再需要人工确认。凭证始终在 Composio 平台侧，connect 本身只是引导 Codex 用对命令。

6.2 meeting-notes-and-actions：从会议记录到可执行任务

会议开完后，决策散落在聊天记录里、没人跟进——这是协作工具的常见痛点。这个 Skill 用结构化输出把转录稿变成可分配的任务。

输入一段会议转录稿，输出包含：

• 结构化摘要（议程、讨论点、决策）
• 开放问题与风险清单
• 每个 action item 标注负责人和期限的待办列表

SKILL.md 里还写了几条质量约束：统一人名写法、不编造事实、拿不准的地方标成澄清问题。配合 notion-meeting-intelligence，还能在会前基于 Notion 中的上下文自动准备材料，会后自动同步到 Notion 知识库。两个 Skill 串联的前提是会议内容确实写在 Notion 里；如果用其他工具（飞书文档、Google Docs），需要先迁移或自建类似 Skill。

6.3 brooks-lint：用经典工程书做代码审查

brooks-lint 是一个外部 AI 审查框架（装进 ACS 的技能列表，仓库在 hyhmrright 名下），把十二本经典工程著作（《人月神话》《代码大全》《重构》《领域驱动设计》等）的判断标准合成六个"衰减风险"维度，对代码做结构化诊断：

• 诊断格式：每个问题按"症状 → 根源 → 后果 → 修复建议"展开，并附书籍引用
• 严重等级：Critical / Warning / Suggestion 三级标注
• 六个模式命令：/brooks-review（变更审查）、/brooks-audit（架构审计，附 Mermaid 依赖图）、/brooks-debt（技术债盘点）、/brooks-test（测试质量）、/brooks-health（综合健康分）、/brooks-sweep（统一扫描并修复）

这种设计的代价是审查视角偏"工程哲学"，对纯语法错误、性能瓶颈这类问题不如专门的 linter 敏感——它自己的 README 也明说"不取代你的 linter"，抓的是架构漂移、知识孤岛、领域模型失真这类 linter 抓不到的问题。适合用在架构 review 或技术债盘点场景，不适合替代 ESLint、mypy 这类工具。

6.4 sentry-triage：自动映射堆栈帧到源码

Sentry 报警来了，传统流程是：复制堆栈帧 → 打开代码 → 手动匹配文件和行号。sentry-triage 把这个流程自动化：

1. 通过 Composio CLI 拉取 Sentry 的问题详情、事件、面包屑和可疑提交
2. 把堆栈帧映射到本地源码文件
3. 输出诊断结果和修复建议

省掉的是复制粘贴和人工匹配的误差，多出来的是"可疑提交"这条线索——回归类问题往往直接指向引入 bug 的那次改动。前提是本地代码与 Sentry 上报的版本对应；版本对不上，映射结果就不可信。

七、构建自己的 Skill

ACS 提供了完整的 skill-creator 指导，以及 template-skill 起步模板。构建流程分三步。

第一步：定义触发条件（description）

---
name: my-new-skill
description: 当用户要求 [具体任务] 时触发这个技能。
---

描述要具体到 Codex 能准确判断"这个技能该上场了"。避免过于泛化的描述，例如"处理会议相关任务"会与 meeting-notes-and-actions、notion-meeting-intelligence 同时命中，导致触发不稳定。

第二步：写执行步骤

• 保持步骤清晰、可执行
• 使用确定性脚本处理重复操作（脚本输出比让模型自由生成更稳定）
• 将长文档放进 references/，正文按需引用（避免一次性灌满上下文）
• 技能文件夹里不要再放 README、changelog 之类的额外文档——它们只会白白占用上下文

第三步：测试与调优

1. 放入 $CODEX_HOME/skills/
2. 重启 Codex
3. 用触发描述测试，看是否精准命中
4. 调整 description 措辞直到稳定

调优时常见的问题是描述过宽导致误触发。一个验证方法：把可能冲突的 Skill 同时安装，用边界任务测试，看 Codex 选哪个。

八、适用场景横向对比

九、与 MCP 的关系：helium-mcp

ACS 中有一个值得单独关注的技能——helium-mcp/。它本身只有一份 SKILL.md，作用是引导 Codex 调用 Helium 的 MCP 服务器（heliumtrades.com/mcp），提供实时新闻搜索（3.2M+ 文章、5000+ 来源、15+ 维度偏差评分）、股票/ETF/加密货币行情、ML 期权定价和平衡新闻综合，另有表情包搜索。免费档 50 次查询，无需注册和 API key；所有工具只读。

helium-mcp 与 connect 的区别在于数据通道：connect 走 Composio CLI 调外部应用 API，helium-mcp 走 MCP 协议直接暴露实时数据工具。如果构建的代理需要实时新闻或市场行情，helium-mcp 比 connect 更直接；如果只是发消息、建 issue，仍然用 connect。

十、采用建议

按使用频率和上手难度，建议按以下顺序引入：

1. 第一周：装 connect + meeting-notes-and-actions。前者打通外部工具，后者解决日常协作痛点，两个 Skill 就能覆盖大部分"让 Codex 替我做事"的场景。
2. 第二周：根据工作流加 gh-fix-ci、sentry-triage 或 datadog-logs。这些 Skill 接的是已有工具链，不需要改原有流程。
3. 第三周以后：尝试 brooks-lint 做架构 review，或用 skill-creator 自建 Skill。自建前先读 template-skill 的结构，避免 description 写得太泛。

不适合用 ACS 的场景：纯问答用途（不需要执行外部动作）、对数据隐私要求极高（Composio 平台代为调用 API 意味着凭证要交给第三方）、团队尚未统一 Codex CLI 版本（Skill 触发机制依赖运行时元数据扫描，版本不一致会导致行为差异）。

自测题

回答下面的问题检验理解，能答上来说明读到了机制层：

1. 触发机制：Codex 如何决定加载哪个 Skill？description 字段写得太宽泛会有什么后果？
2. 四条主线：ACS 系统中的"触发"、“执行”、“安装”、“外部能力"四条主线各自负责什么？
3. 任务组合：用户说"帮我把今天会议的 action item 同步到 Linear”，Codex 会触发哪几个 Skill？触发顺序由什么决定？
4. connect Skill：为什么 connect Skill 本身不持有 Slack token？消息是如何发出的？
5. 构建 Skill：写一个触发稳定的 description，应该避免什么常见错误？
6. ACS vs MCP：helium-mcp 和 connect 在数据通道上有什么本质区别？

进阶路径

入门（已完成本文阅读）

• 安装 connect Skill，完成一次"在 Slack 发消息"的任务
• 阅读 meeting-notes-and-actions 的 SKILL.md，理解其 description 写法

进阶

• 参考 template-skill 构建自己的 Skill，解决一个你日常重复的操作
• 阅读 brooks-lint 源码，理解如何将书籍知识编码进 prompt

深入

• 研究 Codex CLI 的上下文管理策略，理解为什么"按需加载"能控制 token 消耗
• 对比 ACS 与 MCP 两种扩展机制，写一篇对比分析文档

常见问题

Q1：Skill 安装了但没触发，怎么排查？

A：按以下顺序检查：

1. 确认 description 是否具体——过于泛化的描述会导致多个 Skill 冲突或都不触发
2. 重启 Codex CLI——新安装的 Skill 需要重启才能加载元数据
3. 用 ls ~/.codex/skills/ 确认文件夹存在，head ~/.codex/skills/<skill>/SKILL.md 确认 frontmatter 完整
4. 用边界任务测试——同时安装可能冲突的 Skill，看 Codex 选哪个

Q2：connect Skill 本身持有 Slack token 吗？

A：不持有。connect Skill 只告诉 Codex “何时该调 Composio CLI”，实际的 API 调用由 Composio 平台完成。这也是为什么使用 connect 前必须先 composio login，再对要用到的应用逐个执行 composio link（OAuth 授权一次，连接持久化）。

Q3：可以不用 Composio，让 Skill 直接调 Slack API 吗？

A：可以，但需要自己写 Skill 和对应的脚本/工具适配代码。connect Skill 的价值是省去这一步——它依赖 Composio 平台已经封装好的 1000+ 应用连接器。如果只对接少量应用且不复用，直接写工具适配代码更快。

Q4：自建 Skill 的 description 怎么写才能让触发准确？

A：遵循三个原则：

1. 具体动词 + 明确对象——“当用户要求把会议转录稿转成 action item 时触发” 比 “处理会议相关任务” 准确得多
2. 不要描述实现方式——description 只决定"何时触发"，“怎么做” 留给 body
3. 测试负例——确保你的 description 不会在无关任务上误触发

Q5：ACS 的 Skill 和 MCP Server 有什么区别？

A：Skill 是"触发 + 执行指引"，MCP Server 是"工具协议标准"。一个 MCP Server 可以被多个 Agent 框架调用；一个 Skill 只被 Codex CLI 按 description 匹配触发。两者可以叠加使用（如 helium-mcp Skill 引导 Codex 调用 MCP 协议暴露的工具）。

Q6：Codex CLI 升级后，已安装的 Skill 需要更新吗？

A：取决于 Skill 的触发机制是否依赖特定版本的元数据扫描行为。建议每次升级后：

1. 重新安装核心 Skill（connect、meeting-notes-and-actions）
2. 测试触发是否仍然准确
3. 如果行为有变化，调整 description 措辞

🦞 每日 08:00 自动更新

相关链接：

• GitHub：https://github.com/composio-community/awesome-codex-skills
• Composio 官网：https://composio.dev
• Composio 控制台：https://dashboard.composio.dev
• Discord 社区：https://discord.com/invite/composio