技能仓鼠自救指南agent-skills、Superpowers、Pocock 按工作形态怎么配【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skillsSkill 生态在 2026 年上半年彻底爆发CSDN、掘金上关于 Agent Skills 的教程动辄几万阅读前端领域30 个值得安装的 Agent Skills、Java 技术栈Skills 全景指南一类的清单满天飞。随之而来的是一批新的技能仓鼠——收藏夹里囤着 agent-skills、Superpowers、Matt Pococks skills 三套完整框架一口气全装进 Codex结果路由互相打架、上下文被元数据吃光、同一个任务三个 Skill 争着触发。本文不教你哪个最强而是给你一套按工作形态做减法的配置思路三大框架分别对应哪类工作流、为什么主路由框架不可叠加而单技能必须 cherry-pick、以及 OpenAI 官方 Skills Catalog 更新后的落地选型表。所有结论都对照本地仓库的真实源码给出证据。一、先认清三者的性格定位差异决定配置方式社区里对三大框架的共识性分类本质是它们对**AI 与人的控制权边界**的不同假设。对照 OpenAI 官方仓库 skills/.system/skill-creator/SKILL.md 里反复强调的设计哲学可以看得更清楚。agent-skills全生命周期交付用 eval 换确定性agent-skills 的定位是从需求到交付的全生命周期覆盖。它的核心卖点之一是三层 eval 框架——在交付前对技能产出做可验证的评估把AI 写得对不对变成可度量的关卡。这与本仓库中 define-goal 的设计同构它拒绝make checkout faster这类活动型目标要求目标必须回答完成时什么具体事情为真、什么证据能证明、量化或二元的成功阈值是什么。全生命周期框架的共同前提是交付质量必须能被显式验证所以它们天然拥抱 TDD、eval 和 CI 闸门。Superpowers长周期自主执行为放手设计Superpowers 对应的是另一种工作形态需求边界相对清晰、执行链路长、中间不需要频繁人工介入。它赌的是把任务拆细、把步骤写死Agent 就能自己跑完马拉松。这种框架适合批处理、迁移、数据清洗这类过程确定性高于结果创造性的场景。Pocock需求质询驱动把 AI 塞进现有工程流程Matt Pococks skills 是三者中哲学最鲜明的一个。掘金社区有一篇实战拆解《Codex Matt Pocock Skills 实战》核心结论一句话它的目标不是让 Agent 完全接管开发而是把 AI 放进现有软件工程流程同时保留人工决策权。它把流程切成需求澄清 → Spec → 拆 Ticket → 逐 Ticket 实现 → 人工审核 → AI Review → 人工再审核 → 人工决定提交每一步都有人工卡点。关键细节是它的路由层设计——ask-matt不负责实现只负责回答这个问题应该走哪条流程加个失败重试走grill-with-docs → to-spec → to-tickets → implement修 Bug 走diagnosing-bugs → tdd → code-review。这就是所谓需求质询驱动在写代码之前先逼着 Agent 反问需求。它甚至建议你改掉原版implement里自动 Commit的设计把提交权收回到人手里。二、为什么主路由框架不能叠加单技能却可以 cherry-pick如果你把三套框架全装上第一个崩坏点就在路由层。每个框架都自带一个我应该被触发吗的入口Pocock 是ask-mattSuperpowers 有自己的任务编排agent-skills 也有生命周期调度而 Skill 的触发机制只有一个——SKILL.md frontmatter 里的description。看本仓库 skills/.system/skill-creator/SKILL.md 的原文frontmatter 的 name 和 description 是 Codex 判断何时使用这个技能时读取的唯一字段而正文只有在技能被触发之后才会加载。这意味着多个框架叠在一起时每个框架的元数据都常驻上下文、互相竞争触发权——三套路由同时盯着一句话判断这是我的活最终行为不可预期。第二个崩坏点是资源。同一份文件里有一句被反复引用的原则The context window is a public good. Skills share the context window with everything else Codex needs.上下文窗口是公共资源。仓库给出的三层渐进式披露Progressive Disclosure预算非常具体元数据约 100 词常驻、SKILL.md 正文在触发后加载控制在 5k 词以内、脚本/资源按需加载。三套框架叠装等于让三个常驻路由各自吃掉一份元数据预算还没开始干活窗口已经被框架说明书占满。那为什么单技能可以 cherry-pick因为 Skill 的本质是自包含的文件夹一个SKILL.md加可选的scripts/、references/、assets/彼此之间没有硬依赖。从不同框架里各挑一个能力缺口最大的技能装进来它们不会互相调度、也不会争夺路由——只要你不装它们的路由入口它们就是安静的工具人。仓库里的精选技能就是最好的例子。看看skills/.curated/里的实际组织方式gh-fix-ci用 gh 定位失败 CI、汇总日志、草拟修复计划并在用户明确批准后才实施、gh-address-comments把 PR review 评论编号列出、由人选择处理哪些、security-threat-model威胁建模报告输出前要求用户确认假设、migrate-to-codex把 Claude Code 的指令/技能/MCP 配置迁入 Codex——这些技能每个都只解决一个窄问题横跨不同生态互不冲突。它们共同遵守 skill-creator 里那条自由度原则脆弱且易错的操作给低自由度具体脚本创造性决策给高自由度文本指令而不是试图垄断整个开发流程。三、加入 OpenAI 官方仓库后的最新选型表本仓库就是这份生态的坐标系本身它是 OpenAI 的 Skills CatalogSkills Catalog for Codex在 README.md 里给出了两条关键信息。其一仓库已进入维护模式。README 开头的 IMPORTANT 块明确声明本仓库已弃用deprecated当前 Codex 的 skill 与插件示例已迁移到 OpenAI Plugins 仓库新增技能应走skill-only plugin的构建方式。这解释了为什么社区里OpenAI 官方仓库的讨论总在变——官方形态已经从技能目录演进为插件生态但.system预装技能与.curated精选技能的分级思路延续了下来。其二安装机制是分层的。skills/.system/下的技能skill-creator、skill-installer、plugin-creator、imagegen、openai-docs在最新版 Codex 中自动预装skills/.curated/的 39 个精选技能通过内置的$skill-installer按名安装$CODEX_HOME/skills是默认落地目录见 skills/.system/skill-installer/SKILL.md。也就是说官方自己就在践行预装最小集 按需装精选的 cherry-pick 路线。基于以上事实把工作形态和配置方案对齐可以得到一张可执行的选型表你的工作形态首选主路由建议 cherry-pick 单技能人工卡点从 PRD 到交付的全生命周期、要可度量质量agent-skills 体系define-goal量化验收、notion-spec-to-implementationSpec 转任务、security-threat-model交付前威胁建模eval 关卡、验收标准长周期自主执行、批处理/迁移类任务Superpowers 编排migrate-to-codex配置迁移、cli-creator把反复操作固化为可运行 CLI目标健康状态、失败阈值已有工程流程、想让 AI 融入而非接管ask-matt / grill-with-docsgh-fix-ci修 CI 先出计划再实施、gh-address-comments评论先编号由人选择提交权、合并权、上线权留在人侧这张表的判据不是哪个框架更好而是三个问题你的需求是不是在交付前可验证的你的任务是不是确定性长链路你是否愿意接受 AI 反问需求的节奏三选一决定主路由剩下两家的技能按能力缺口挑着装。最后补一条实践忠告无论选哪条路线都值得先看一眼 skill-creator 的六步创作流程和渐进式披露规范。它能帮你判断这个技能值不值得装——如果某个技能的 SKILL.md 正文超过 500 行、需要靠大量重复文档撑场面它大概率是个伪技能装进去只会消耗公共上下文。真正值得留存的永远是那些把复杂流程压缩进一个窄触发面、把重逻辑沉淀进scripts/和references/的自包含文件夹。技能仓鼠的解药不是卸载焦虑而是接受一个事实框架是世界观技能是工具。世界观只能信一个工具却可以按需混用。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考