企业官网建设流程全解析

"技能仓鼠"自救指南：agent-skills、Superpowers、Pocock 按工作形态怎么配

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills

Skill 生态在 2026 年上半年彻底爆发：CSDN、掘金上关于 Agent Skills 的教程动辄几万阅读，前端领域"30 个值得安装的 Agent Skills"、Java 技术栈"Skills 全景指南"一类的清单满天飞。随之而来的是一批新的"技能仓鼠"——收藏夹里囤着 agent-skills、Superpowers、Matt Pocock's 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 Pocock's 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-matt，Superpowers 有自己的任务编排，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 Catalog（"Skills 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 路线。

基于以上事实，把工作形态和配置方案对齐，可以得到一张可执行的选型表：

这张表的判据不是"哪个框架更好"，而是三个问题：你的需求是不是在交付前可验证的？你的任务是不是确定性长链路？你是否愿意接受 AI 反问需求的节奏？三选一决定主路由，剩下两家的技能按能力缺口挑着装。

最后补一条实践忠告：无论选哪条路线，都值得先看一眼 skill-creator 的六步创作流程和渐进式披露规范。它能帮你判断"这个技能值不值得装"——如果某个技能的 SKILL.md 正文超过 500 行、需要靠大量重复文档撑场面，它大概率是个伪技能，装进去只会消耗公共上下文。真正值得留存的，永远是那些把复杂流程压缩进一个窄触发面、把重逻辑沉淀进scripts/和references/的自包含文件夹。

技能仓鼠的解药不是卸载焦虑，而是接受一个事实：框架是世界观，技能是工具。世界观只能信一个，工具却可以按需混用。

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills