如果你也在用 Codex CLI 这类 AI 编程助手大概率会遇到同一个尴尬模型本身很强但每次都得你把一堆工程规范手把手重新说一遍。让它写测试你得在提示词里写明先写失败测试、再写实现、再重构让它调试你得反复叮嘱先复现再定位根因别急着改代码。说一两次还行天天说就有点心累了。superpowers 就是为了解决这个问题出现的——它不是某一个单一工具而是一套打包好的、可复用的技能库专门给 Codex、Claude Code 这类 agent 补充工程经验。我最近在折腾 Codex 环境时把它装上了实测下来最大的感受是它把那些你自己心里清楚但没写成文档的开发流程变成了一堆 SKILL.md 文件让 AI 在合适的时机自动按流程干活。这篇文章打算从安装、使用到排坑完整过一遍顺便把很多人搜到的superpowers java这个点讲清楚。适合正在用 Codex、或者想尝试 agent 辅助编程的人参考。1. superpowers 到底是什么不是魔法是操作手册1.1 从 AI 编程助手的裸奔状态说起现在的 Codex 这类编程 agent本质上是一个很聪明但没什么行业经验的新人。你让它帮我修这个 bug它会修但它可能上来就贴一段代码缺少复现、定位、验证的完整思路你让它补测试它可能只补了几个 happy path边界条件全没覆盖。这不是模型不行而是它没有一套稳定的工程方法论。我以前的做法是把方法论写在自己的提示词模板里。比如一段调试专用提示词、一段写测试专用提示词用的时候复制进去。麻烦的点在于一是提示词越长越容易互相干扰二是换一个项目、换一个工具这些模板又要重新整理。superpowers 把这个事变成了基础设施它不要求你每次手动贴规则而是把规则以技能Skill的形式装进 agent 的能力列表里让 agent 自己判断什么时候该用哪套流程。1.2 Skills 机制为什么用 SKILL.md 而不是写死在提示词里superpowers 的底层机制是 Skills这套东西最早在 Claude 生态里流行起来核心形式就是一个目录里放一个SKILL.md文件。这个文件有固定的元信息头比如name和description下面就是具体的操作指令。Agent 会先扫描所有技能的description判断当前任务和哪个技能匹配然后把对应的SKILL.md内容加载进上下文按里面的步骤执行。这种设计比写死在提示词里的好处非常直接技能可以模块化不同任务加载不同技能上下文不会被无关内容塞满技能可以单独更新不用整体替换你的提示词技能还能附带模板、脚本、示例代码不只是文字规则。用生活里的例子类比这就是给 AI 发了员工手册而不是让每个项目组都自己口头传一遍规矩。1.3 和 Codex 的关系codex superpowers 是怎么接上的很多人搜codex superpowers其实就是指把 superpowers 这套技能库装到 Codex CLI 里用。Codex 在较新的版本中支持从~/.codex/skills目录读取技能文件superpowers 的安装器干的事就是把技能文件复制或者链接到这个目录下。装完之后 Codex 启动时会自动扫描技能不需要改 Codex 的任何配置也不需要你懂什么插件开发。所以你可以把 superpowers 理解成一层经验层下面是 Codex 这种通用 agent上面是各种可插拔的技能。这个项目本身由 Jesse Vincentobra发起在 GitHub 上挺火。我建议你在动手之前先看一眼仓库 README因为技能的清单和安装方式偶有更新我那套实测流程是基于当前主流版本的具体以官方文档为准。2. 安装前的准备与快速安装2.1 前置条件Codex CLI 和 Node 环境安装 superpowers 之前先确认两样东西Codex CLI 已经能跑Node.js 版本够新。安装器是用 npm 包形式发布的执行npx superpowers install时npx 需要本地有 Node.js 环境。我环境里 Node 版本是 20 以上实测没问题如果你 Node 版本太老建议先升级否则可能直接报语法错误或依赖安装失败。这里有点容易绕进去的地方这个 Node 环境只是安装器需要的不是 superpowers 本身要跑的服务更不是你的 Java 项目要引入的依赖。换句话说哪怕你接下来的项目是纯 Java、纯 Python只要本机有 Node 能跑安装器照样可以装 superpowers。确认版本的命令很简单codex --version node --version npm --version只要这三条命令都能正常输出环境就过关了。2.2 安装步骤实测我在一台刚配好 Codex 的测试机上走了一遍完整流程大致步骤如下如果之前手动创建过~/.codex/skills目录先把里面的内容备份一下避免安装器覆盖冲突。在终端执行npx superpowers install安装器会询问要给哪些 agent 安装技能选项一般包括 Claude Code、Codex 等按需选择。我选择了 Codex。安装完成后检查技能目录ls ~/.codex/skills重启 Codex CLI 会话让技能被重新扫描。整个安装过程很快基本一分钟内搞定。装完之后你不需要在 Codex 的配置文件里手动写任何路径安装器已经处理好了。注意第一次执行npx时会有确认安装的提示输入y即可。2.3 关于 java 的澄清搜索superpowers java的人在看什么我理解为什么会有superpowers java这个热词很多人在搜的时候会下意识认为这是一个 Java 框架或者 Java 库想着是不是要把依赖加到pom.xml里。这里得澄清一下这个项目不是 Java 专属工具它完全是语言无关的。技能文件里写的是流程和原则不绑定具体编程语言。举个例子superpowers 里的 TDD 技能会要求先写一个失败的测试运行并确认失败再写最小实现最后重构这套流程在 Python、Java、JavaScript 里完全通用。真正变化的只是具体命令Java 项目里是mvn testPython 项目里是pytest。所以如果你搜这个词是想找一个 Java 版 superpowers建议换个思路——直接在 Java 项目里配合使用这套技能流程比你找一个所谓的 Java 专用版本更靠谱。3. 使用指南让技能真正进入工作流3.1 基本调用方式自动触发与显式要求装好之后很多人第一反应是问我要不要输入某个命令才启动技能答案是不用它会自动触发。Codex 在启动时会读取技能描述当你提出一个任务时模型会把任务内容与各个技能的description做匹配匹配上了就加载对应技能。比如你让它调试一个偶发崩溃调试类技能的描述里通常包含bug、crash、reproduce这些关键词模型就倾向于加载它。但自动触发有时并不准确尤其是任务描述含糊的时候。我的做法是直接在对话里显式指定技能。比如请用 Test-Driven Development 技能来完成这个功能严格按技能里的步骤执行。这样 Codex 大概率会把对应SKILL.md拉进来并且按文件里的编号步骤走。比起完全依赖模型的自由发挥显式指定技能会稳得多。3.2 核心技能拆解TDD、调试、研究与规划superpowers 包含多个技能这里挑几个我实际用过的展开说说具体清单以仓库为准。TDD 技能是我最常用的。它不会简单说请写测试而是给出类似红-绿-重构的完整循环先根据需求写一个会失败的测试运行测试确认失败原因再写最小实现让测试变绿最后做重构并确保测试仍然通过。我实测下来这套流程对功能开发的约束感很强Codex 不会跳步骤直接写一大坨实现而是小步推进。调试技能也很实用。它强调先复现问题再形成假设再做最小化验证最后才动手改代码。这个流程帮我避免了之前遇到过的情况——Codex 上来就贴一段看起来像修复的代码但根因根本没找到。研究技能适合处理陌生技术栈会引导 agent 先做信息收集、列方案、比较优劣再落地。规划技能则适合大一点的改造任务先拆解任务、列风险点、定验收标准再开始写代码。这些技能之间可以组合。比如一个稍大的功能可以先让规划技能产出任务清单再对每个子任务用 TDD 技能推进。实际用下来组合使用比单个技能效果好得多。3.3 参数与配置SKILL.md 的元数据怎么读如果你不满足于直接使用想看一下技能内部到底写了什么或者想自己改一版那就要学会读SKILL.md。它的一般结构是这样的--- name: write-tests-first description: Use when the user asks to write tests, fix a bug in test code, or implement a feature following test-driven development. --- 1. Check the projects test framework configuration. 2. Write one failing test that describes the expected behavior. 3. Run the test and confirm it fails for the right reason. 4. Write the minimal implementation to make the test pass. 5. Run the full test suite and refactor if needed.元信息头里的name是技能标识description最关键因为 agent 就是靠它来判断什么时候加载这个技能的。你如果发现某个技能经常在不该出现的时候出现可以改它的description把触发条件写得更精确。正文部分就是给 agent 的具体指令最好写成可执行的编号步骤不要写太多抽象原则。我建议刚上手的人先只读不改用一段时间之后再根据自己项目的特点去精简技能内容。比如我在团队里就改过 TDD 技能把运行测试的具体命令直接从pytest改成了mvn test省得每次模型还要自己猜。3.4 把 superpowers 用到真实项目的一次记录为了说明这东西在真实项目里长什么样我回顾一次实际经历。那次任务是给一个 Java Spring Boot 项目修一个偶发性的空指针异常顺带给相关服务补单元测试。放在以前我会在提示词里写一大段请先复现、再定位、再修复的规则这次我直接说用调试技能定位这个空指针修完之后用 TDD 技能给这个服务补上单元测试。Codex 读完调试技能后先让我提供了异常堆栈和复现步骤然后在代码里定位到一处未判空的对象引用并写了一个最小化的复现用例。修复阶段它没有直接开始改而是先确认我手上有没有那个复现用例。进入 TDD 阶段后它先写了一个会失败的 JUnit 测试再改动代码让测试通过最后跑了mvn test确认没有破坏其他用例。整轮下来我的介入很少主要是确认复现条件和最终验收。对比以前模型的行为稳定了很多关键步骤没有跳最后交付的代码也带了测试。这是我愿意继续用下去的核心理由。4. 常见问题与排查技巧实录4.1 安装后 Codex 完全没反应最常见的问题是装完了Codex 对话里完全没出现技能行为。我遇到过两种情况一种是没有重启会话Codex 的技能扫描大概率在会话启动时执行你装完必须开一个新会话另一种是 Codex 版本太老某些旧版本还不支持从~/.codex/skills读技能这时候你有两个选择升级 Codex或者在提示词里手动指定技能文件路径。排查时先确认目录里有内容find ~/.codex/skills -name SKILL.md如果有输出但 Codex 不响应再看版本。我个人的做法是升级到最新版因为 skills 这类功能演进很快老版本可能有不少兼容问题。4.2 技能加载了但不按流程走比技能没加载更让人头疼的是技能加载了但模型不听话。表现是你说用 TDD 技能它也读了文件但写测试、跑测试、写实现、重构这些步骤被打乱了或者直接跳到最后一步。我分析过几次原因基本是两个一个是上下文太长技能内容被挤到边缘位置模型忘记了步骤顺序另一个是任务本身太大模型为了快速给结果自己压缩了流程。对策也简单把任务拆细一次只让技能处理一个阶段同时在提示词里加强约束比如严格按照技能步骤每完成一步先告诉我结果再进入下一步。这种交互方式虽然多了几轮对话但质量稳定多了。4.3 技能和项目实际情况冲突技能文件里经常会写一些示例命令比如测试用pytest但你的项目是 Java 的mvn或者 JS 的npm test。直接让模型照做就会出错。我的建议是别把技能当成不可修改的铁律它是一个起点而不是终点。项目里已有测试框架时第一轮对话就先说明本项目测试命令是 mvn test所有测试步骤按这个执行。如果经常出现这种冲突更彻底的办法是自己改一份项目专用技能或者维护一个包含项目上下文的自定义技能。我整理过一个简单的对应表方便理解技能中的常见假设Java 项目里的实际适配测试命令pytest改为mvn test或./gradlew test源码目录src/保持src/main/java结构依赖管理requirements.txt改为pom.xml或build.gradle调试入口 main.py根据 Spring Boot 启动类调整4.4 我的几条避坑经验最后补充几条我在实际使用中总结出来的体会不一定写在哪份文档里。第一不要把 superpowers 当成自动全能的魔法。它本质上是把工程经验结构化让 agent 有章可循但最终的代码质量还是依赖你的 review。第二装完之后先挑一个小任务验证效果不要直接拿核心业务做实验。我见过有人一上来就在生产仓库里用结果模型按技能流程写了一堆测试方向却不对白费功夫。第三技能数量多了不一定好注意按需裁剪。superpowers 默认装了多个技能实际项目中经常用到的可能就两三个把不相关的技能留在一个个目录里会占上下文空间。最后再分享一个小技巧如果你用了几个项目之后发现某个技能特别好用可以把它的SKILL.md复制到你自己的项目仓库里改成项目专用版。我就是在团队仓库里放了一个定制过的 TDD 技能让所有人不管用 Codex 还是其他支持技能的 agent都能得到一致的工程约束。这样做的好处是规范沉淀在仓库里而不是只存在于某个人的对话历史中。
如果你也在用 Codex CLI 这类 AI 编程助手大概率会遇到同一个尴尬模型本身很强但每次都得你把一堆工程规范手把手重新说一遍。让它写测试你得在提示词里写明先写失败测试、再写实现、再重构让它调试你得反复叮嘱先复现再定位根因别急着改代码。说一两次还行天天说就有点心累了。superpowers 就是为了解决这个问题出现的——它不是某一个单一工具而是一套打包好的、可复用的技能库专门给 Codex、Claude Code 这类 agent 补充工程经验。我最近在折腾 Codex 环境时把它装上了实测下来最大的感受是它把那些你自己心里清楚但没写成文档的开发流程变成了一堆 SKILL.md 文件让 AI 在合适的时机自动按流程干活。这篇文章打算从安装、使用到排坑完整过一遍顺便把很多人搜到的superpowers java这个点讲清楚。适合正在用 Codex、或者想尝试 agent 辅助编程的人参考。1. superpowers 到底是什么不是魔法是操作手册1.1 从 AI 编程助手的裸奔状态说起现在的 Codex 这类编程 agent本质上是一个很聪明但没什么行业经验的新人。你让它帮我修这个 bug它会修但它可能上来就贴一段代码缺少复现、定位、验证的完整思路你让它补测试它可能只补了几个 happy path边界条件全没覆盖。这不是模型不行而是它没有一套稳定的工程方法论。我以前的做法是把方法论写在自己的提示词模板里。比如一段调试专用提示词、一段写测试专用提示词用的时候复制进去。麻烦的点在于一是提示词越长越容易互相干扰二是换一个项目、换一个工具这些模板又要重新整理。superpowers 把这个事变成了基础设施它不要求你每次手动贴规则而是把规则以技能Skill的形式装进 agent 的能力列表里让 agent 自己判断什么时候该用哪套流程。1.2 Skills 机制为什么用 SKILL.md 而不是写死在提示词里superpowers 的底层机制是 Skills这套东西最早在 Claude 生态里流行起来核心形式就是一个目录里放一个SKILL.md文件。这个文件有固定的元信息头比如name和description下面就是具体的操作指令。Agent 会先扫描所有技能的description判断当前任务和哪个技能匹配然后把对应的SKILL.md内容加载进上下文按里面的步骤执行。这种设计比写死在提示词里的好处非常直接技能可以模块化不同任务加载不同技能上下文不会被无关内容塞满技能可以单独更新不用整体替换你的提示词技能还能附带模板、脚本、示例代码不只是文字规则。用生活里的例子类比这就是给 AI 发了员工手册而不是让每个项目组都自己口头传一遍规矩。1.3 和 Codex 的关系codex superpowers 是怎么接上的很多人搜codex superpowers其实就是指把 superpowers 这套技能库装到 Codex CLI 里用。Codex 在较新的版本中支持从~/.codex/skills目录读取技能文件superpowers 的安装器干的事就是把技能文件复制或者链接到这个目录下。装完之后 Codex 启动时会自动扫描技能不需要改 Codex 的任何配置也不需要你懂什么插件开发。所以你可以把 superpowers 理解成一层经验层下面是 Codex 这种通用 agent上面是各种可插拔的技能。这个项目本身由 Jesse Vincentobra发起在 GitHub 上挺火。我建议你在动手之前先看一眼仓库 README因为技能的清单和安装方式偶有更新我那套实测流程是基于当前主流版本的具体以官方文档为准。2. 安装前的准备与快速安装2.1 前置条件Codex CLI 和 Node 环境安装 superpowers 之前先确认两样东西Codex CLI 已经能跑Node.js 版本够新。安装器是用 npm 包形式发布的执行npx superpowers install时npx 需要本地有 Node.js 环境。我环境里 Node 版本是 20 以上实测没问题如果你 Node 版本太老建议先升级否则可能直接报语法错误或依赖安装失败。这里有点容易绕进去的地方这个 Node 环境只是安装器需要的不是 superpowers 本身要跑的服务更不是你的 Java 项目要引入的依赖。换句话说哪怕你接下来的项目是纯 Java、纯 Python只要本机有 Node 能跑安装器照样可以装 superpowers。确认版本的命令很简单codex --version node --version npm --version只要这三条命令都能正常输出环境就过关了。2.2 安装步骤实测我在一台刚配好 Codex 的测试机上走了一遍完整流程大致步骤如下如果之前手动创建过~/.codex/skills目录先把里面的内容备份一下避免安装器覆盖冲突。在终端执行npx superpowers install安装器会询问要给哪些 agent 安装技能选项一般包括 Claude Code、Codex 等按需选择。我选择了 Codex。安装完成后检查技能目录ls ~/.codex/skills重启 Codex CLI 会话让技能被重新扫描。整个安装过程很快基本一分钟内搞定。装完之后你不需要在 Codex 的配置文件里手动写任何路径安装器已经处理好了。注意第一次执行npx时会有确认安装的提示输入y即可。2.3 关于 java 的澄清搜索superpowers java的人在看什么我理解为什么会有superpowers java这个热词很多人在搜的时候会下意识认为这是一个 Java 框架或者 Java 库想着是不是要把依赖加到pom.xml里。这里得澄清一下这个项目不是 Java 专属工具它完全是语言无关的。技能文件里写的是流程和原则不绑定具体编程语言。举个例子superpowers 里的 TDD 技能会要求先写一个失败的测试运行并确认失败再写最小实现最后重构这套流程在 Python、Java、JavaScript 里完全通用。真正变化的只是具体命令Java 项目里是mvn testPython 项目里是pytest。所以如果你搜这个词是想找一个 Java 版 superpowers建议换个思路——直接在 Java 项目里配合使用这套技能流程比你找一个所谓的 Java 专用版本更靠谱。3. 使用指南让技能真正进入工作流3.1 基本调用方式自动触发与显式要求装好之后很多人第一反应是问我要不要输入某个命令才启动技能答案是不用它会自动触发。Codex 在启动时会读取技能描述当你提出一个任务时模型会把任务内容与各个技能的description做匹配匹配上了就加载对应技能。比如你让它调试一个偶发崩溃调试类技能的描述里通常包含bug、crash、reproduce这些关键词模型就倾向于加载它。但自动触发有时并不准确尤其是任务描述含糊的时候。我的做法是直接在对话里显式指定技能。比如请用 Test-Driven Development 技能来完成这个功能严格按技能里的步骤执行。这样 Codex 大概率会把对应SKILL.md拉进来并且按文件里的编号步骤走。比起完全依赖模型的自由发挥显式指定技能会稳得多。3.2 核心技能拆解TDD、调试、研究与规划superpowers 包含多个技能这里挑几个我实际用过的展开说说具体清单以仓库为准。TDD 技能是我最常用的。它不会简单说请写测试而是给出类似红-绿-重构的完整循环先根据需求写一个会失败的测试运行测试确认失败原因再写最小实现让测试变绿最后做重构并确保测试仍然通过。我实测下来这套流程对功能开发的约束感很强Codex 不会跳步骤直接写一大坨实现而是小步推进。调试技能也很实用。它强调先复现问题再形成假设再做最小化验证最后才动手改代码。这个流程帮我避免了之前遇到过的情况——Codex 上来就贴一段看起来像修复的代码但根因根本没找到。研究技能适合处理陌生技术栈会引导 agent 先做信息收集、列方案、比较优劣再落地。规划技能则适合大一点的改造任务先拆解任务、列风险点、定验收标准再开始写代码。这些技能之间可以组合。比如一个稍大的功能可以先让规划技能产出任务清单再对每个子任务用 TDD 技能推进。实际用下来组合使用比单个技能效果好得多。3.3 参数与配置SKILL.md 的元数据怎么读如果你不满足于直接使用想看一下技能内部到底写了什么或者想自己改一版那就要学会读SKILL.md。它的一般结构是这样的--- name: write-tests-first description: Use when the user asks to write tests, fix a bug in test code, or implement a feature following test-driven development. --- 1. Check the projects test framework configuration. 2. Write one failing test that describes the expected behavior. 3. Run the test and confirm it fails for the right reason. 4. Write the minimal implementation to make the test pass. 5. Run the full test suite and refactor if needed.元信息头里的name是技能标识description最关键因为 agent 就是靠它来判断什么时候加载这个技能的。你如果发现某个技能经常在不该出现的时候出现可以改它的description把触发条件写得更精确。正文部分就是给 agent 的具体指令最好写成可执行的编号步骤不要写太多抽象原则。我建议刚上手的人先只读不改用一段时间之后再根据自己项目的特点去精简技能内容。比如我在团队里就改过 TDD 技能把运行测试的具体命令直接从pytest改成了mvn test省得每次模型还要自己猜。3.4 把 superpowers 用到真实项目的一次记录为了说明这东西在真实项目里长什么样我回顾一次实际经历。那次任务是给一个 Java Spring Boot 项目修一个偶发性的空指针异常顺带给相关服务补单元测试。放在以前我会在提示词里写一大段请先复现、再定位、再修复的规则这次我直接说用调试技能定位这个空指针修完之后用 TDD 技能给这个服务补上单元测试。Codex 读完调试技能后先让我提供了异常堆栈和复现步骤然后在代码里定位到一处未判空的对象引用并写了一个最小化的复现用例。修复阶段它没有直接开始改而是先确认我手上有没有那个复现用例。进入 TDD 阶段后它先写了一个会失败的 JUnit 测试再改动代码让测试通过最后跑了mvn test确认没有破坏其他用例。整轮下来我的介入很少主要是确认复现条件和最终验收。对比以前模型的行为稳定了很多关键步骤没有跳最后交付的代码也带了测试。这是我愿意继续用下去的核心理由。4. 常见问题与排查技巧实录4.1 安装后 Codex 完全没反应最常见的问题是装完了Codex 对话里完全没出现技能行为。我遇到过两种情况一种是没有重启会话Codex 的技能扫描大概率在会话启动时执行你装完必须开一个新会话另一种是 Codex 版本太老某些旧版本还不支持从~/.codex/skills读技能这时候你有两个选择升级 Codex或者在提示词里手动指定技能文件路径。排查时先确认目录里有内容find ~/.codex/skills -name SKILL.md如果有输出但 Codex 不响应再看版本。我个人的做法是升级到最新版因为 skills 这类功能演进很快老版本可能有不少兼容问题。4.2 技能加载了但不按流程走比技能没加载更让人头疼的是技能加载了但模型不听话。表现是你说用 TDD 技能它也读了文件但写测试、跑测试、写实现、重构这些步骤被打乱了或者直接跳到最后一步。我分析过几次原因基本是两个一个是上下文太长技能内容被挤到边缘位置模型忘记了步骤顺序另一个是任务本身太大模型为了快速给结果自己压缩了流程。对策也简单把任务拆细一次只让技能处理一个阶段同时在提示词里加强约束比如严格按照技能步骤每完成一步先告诉我结果再进入下一步。这种交互方式虽然多了几轮对话但质量稳定多了。4.3 技能和项目实际情况冲突技能文件里经常会写一些示例命令比如测试用pytest但你的项目是 Java 的mvn或者 JS 的npm test。直接让模型照做就会出错。我的建议是别把技能当成不可修改的铁律它是一个起点而不是终点。项目里已有测试框架时第一轮对话就先说明本项目测试命令是 mvn test所有测试步骤按这个执行。如果经常出现这种冲突更彻底的办法是自己改一份项目专用技能或者维护一个包含项目上下文的自定义技能。我整理过一个简单的对应表方便理解技能中的常见假设Java 项目里的实际适配测试命令pytest改为mvn test或./gradlew test源码目录src/保持src/main/java结构依赖管理requirements.txt改为pom.xml或build.gradle调试入口 main.py根据 Spring Boot 启动类调整4.4 我的几条避坑经验最后补充几条我在实际使用中总结出来的体会不一定写在哪份文档里。第一不要把 superpowers 当成自动全能的魔法。它本质上是把工程经验结构化让 agent 有章可循但最终的代码质量还是依赖你的 review。第二装完之后先挑一个小任务验证效果不要直接拿核心业务做实验。我见过有人一上来就在生产仓库里用结果模型按技能流程写了一堆测试方向却不对白费功夫。第三技能数量多了不一定好注意按需裁剪。superpowers 默认装了多个技能实际项目中经常用到的可能就两三个把不相关的技能留在一个个目录里会占上下文空间。最后再分享一个小技巧如果你用了几个项目之后发现某个技能特别好用可以把它的SKILL.md复制到你自己的项目仓库里改成项目专用版。我就是在团队仓库里放了一个定制过的 TDD 技能让所有人不管用 Codex 还是其他支持技能的 agent都能得到一致的工程约束。这样做的好处是规范沉淀在仓库里而不是只存在于某个人的对话历史中。
