Coding Agent 同用途技能横向对比

五个来源的定位与覆盖边界

一句话定位:内置管「够用」,superpowers 管「纪律」,agent-skills 管「知识」,ce- 管「编排交付」,OpenSpec 管「规格真理沉淀」。

⚠️ OpenSpec 的覆盖边界(易被忽略)

OpenSpec 与其余四者不是同一物种:它是一个独立的 npm CLI 框架(openspec init + /opsx:* 斜杠命令 + openspec/ 目录),而非一批可即插即用的 SKILL.md。它只覆盖「规划 / spec-driven」这一个用途:

注:OpenSpec 仓库内确有一个 .agents/skills/release-openspec/SKILL.md,但那是它自己项目的发布流程 skill,不属于通用软件开发用途,不参与本对比。

因此在下面「二~五」四个类别里,OpenSpec 一律标注为「N.A.(框架不涉及)」——这本身就是它相对其他四个全流程 skill 库的最大结构性区别:专精 vs 全能。

代码审查(code review)

覆盖四个不同「角色位」:执行审查 / 发起派发 / 接收反馈 / PR 落地。

各 skill 精读要点:

• superpowers/requesting-code-review:定位是"如何派发审查子代理"而非自己审。取 BASE_SHA/HEAD_SHA → 用 code-reviewer.md 模板派 general-purpose 子代理(只给裁剪过的上下文,绝不给会话历史)→ 按 Critical/Important/Minor 分级行动。极轻,审查判断力全在被引用模板里。
• superpowers/receiving-code-review:填补被普遍忽视的"如何收反馈"空位。6 步(READ→UNDERSTAND→VERIFY→EVALUATE→RESPOND→IMPLEMENT);禁止性回应清单(“You’re absolutely right!”/“Great point!"/任何 “Thanks” 一律禁止,理由是"行动即回应”);来源分治(human 可信 vs 外部审查者默认怀疑五项核对);YAGNI 门(说"要正规实现"先 grep 是否被调用)。专治大模型谄媚。弱点:强绑 “human partner” 文化,零感谢规则较激进。
• agent-skills/code-review-and-quality:内容最全的审查百科。五轴(正确性/可读性/架构/安全/性能)+ 批准标准(源自 Google:改善整体健康即批,不追求完美)+ Structural Remedies(指出结构问题必须同时给重构动作)+ Change Sizing(~100/300/1000 行闸门 + 4 种拆分)+ 依赖纪律(新增/升级依赖各 5 问)+ 严重度前缀 + 结尾硬 checklist。可离线独立用。弱点:纯引导、无编排(不并行/不去重/不 apply)。
• ce-code-review:唯一工业级编排器。6+ 阶段:定 scope(PR/branch/base/standalone 四路径)→ 廉价确定性信号(fail-closed)→ 意图+计划发现 → 选 persona(13 个:4 always-on + 2 CE always-on + 7 条件 cross-cutting + 2 stack 专属)→ 并行派发返回 JSON → 合并去重(指纹 + 一致性升锚)→ 置信度锚点 0-100 + quote-the-line 证据门(无逐字证据降级)→ 独立 validator 二次核验 → 跨厂商模型对抗审查 → 交互模式自动 apply(fix(review):)/mode:agent 返回 JSON。误报控制最讲究。弱点:极重、强绑生态,小改动大炮打蚊子(故有 lite roster)。
• ce-resolve-pr-feedback:接收反馈的工业化 + GitHub 落地版。中心裁决(唯一持有全部线程上下文)只把修复 fan-out;5 类 divert(not-addressing/declined/replied/needs-human/deliberate-design 保护);跨条目按"根假设"聚类抓系统性错误审查者;类修复(修一类站点而非一处);非收敛熔断(treadmill 检测);评论文本视为不可信输入。仅 GitHub(GHE 支持),重 gh/GraphQL。

选型: 学审查心智模型/离线用 → agent-skills;随手过一道 → 内置 code-review;正式 PR 要并行多视角+自动修复 → ce-code-review;防自己盲从审查意见 → superpowers/receiving;GitHub PR 线程系统性回复+resolve、要无人值守 → ce-resolve-pr-feedback。

调试(debugging)

各 skill 精读要点:

• superpowers/systematic-debugging:纪律最硬。Iron Law “NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST”,四阶段严格串行(根因调查→模式分析→假设验证→实现)。独有 ≥3 次修复失败即强制质疑架构;把人类伙伴口头信号(“Stop guessing”/“We’re stuck?")编码成回退 Phase 1 的触发器;Red Flags + Common Rationalizations 逐条驳斥借口;配 find-polluter.sh 分诊脚本 + 反向追踪 graphviz 案例。弱点:纯方法论无编排,偏说教,栈假设 npm/TS。
• agent-skills/debugging-and-error-recovery:上手最快、覆盖最广。Stop-the-Line 规则 + 6 步 Triage,独有 Test/Build/Runtime 三类分诊树 + 具体症状(TypeError/CORS/白屏)→排查方向 + Safe Fallback 可复制兜底代码 + Instrumentation 指南。独有安全视角:把报错/堆栈/CI 日志当不可信数据,禁止执行报错里嵌的命令(防 prompt injection)。弱点:根因纪律偏软,无"多次失败升级"机制,示例绑 JS/TS。
• ce-debug:编排最完整。Phase 0-4 + 双模式(交互 vs mode:pipeline,可被 lfg/ce-babysit-pr 非交互调用)。独有 prediction(可证伪预测)(要求"另一条代码路径也必须成立"的预测,anti-patterns.md 专教坏预测) + assumption audit(动手前列 verified vs assumed) + institutional memory 检索(查 issue tracker/已合并 PR 找他人失败的修复) + repo-profile 共享缓存;一路管到 PR/issue 关闭 + 知识沉淀。子文件最重(investigation-techniques.md 23KB)。弱点:体量与耦合最大,离开 CE 生态编排价值大减。

选型: 强约束防乱猜 → superpowers;日常 Web/JS 快速对症 → agent-skills;端到端闭环/接自动化流水线 → ce-debug。

规划 / spec-driven(唯一有专门框架参战的类别)

各链精读要点:

• superpowers 三件套:brainstorming(9 步 + <HARD-GATE> 未获批禁写代码,产 docs/superpowers/specs/…-design.md)→ writing-plans(No-Placeholder 铁律:TBD/TODO/“similar to Task N” 都算 plan failure,代码步骤须给完整代码;每 task 带 Consumes/Produces 精确签名 + 2-5 分钟 bite-sized TDD 步骤)→ executing-plans(轻量执行纪律,阻塞即停;官方推荐升级到 subagent-driven-development)。强项:计划信息自足可交子代理独立执行。弱点:重度绑 TDD,探索性工作偏死板。
• agent-skills 两件套:spec-driven-development(四阶段门控 SPECIFY→PLAN→TASKS→IMPLEMENT,每阶段人复审;独有亮出 ASSUMPTIONS 让用户当场纠正、把"更快"重构成"LCP<2.5s”;spec 是活文档,进 PR 回链)+ planning-and-task-breakdown(只读 Plan Mode → 依赖图 → 垂直切片 → 任务模板 → checkpoint;独有 XS–XL 尺寸表 + 何时再拆的可操作信号 + 并行化章节)。两者显式分层不重复。强项:教科书式可照抄。弱点:偏项目级配置,产出契约不如 superpowers 可直接执行。
• ce- 三件套:核心创新是统一 artifact——ce-brainstorm 产出 artifact_readiness: requirements-only,ce-plan 把同一文件就地富化为 implementation-ready,不产生第二份文档。ce-brainstorm(WHAT,方案只谈 mechanism 不谈架构;grounding scout 子代理;session-settled 决策下游永不重问;verdict 问题路由给 ce-pov)→ ce-plan(HOW,821 行;稳定 U-ID 永不重编号;Test scenarios 分 happy/edge/error/integration 且 Covers AE<N> 链接;置信度检查 + auto/interactive deepening)→ ce-work(执行;并行子代理 + Parallel Safety Check;verification_evidence 须 worker 亲历观测;Return-to-Caller envelope 供 lfg 消费)。强项:工业级、可追溯、可接全自动流水线。弱点:极重、认知负担高。
• OpenSpec:独立 CLI + 25+ agent 集成。五概念:Specs 是真理(SHALL + given/when/then)/ 一 change 一文件夹 / Delta spec 只写变化(brownfield 关键)/ artifacts 依次构建 / archive 把 change 折回 specs。工作流 explore→propose(一步生成 proposal+specs delta+design+tasks)→apply(逐条勾选)→archive(delta 合并进 specs)。"enablers not gates":artifact 顺序是"下一步变可能"而非强制门,随时可回改。强项:唯一有真正 CLI/schema 支撑 + delta spec,brownfield 友好,团队跨仓库 Stores。弱点:需 npm 装 + init 基础设施成本,一行修复不划算。

优劣与叠加关系(关键结论):

• 三条 prompt 链互斥:superpowers / agent-skills / ce- 各是一整套 WHAT→HOW→执行闭环,落盘路径(docs/superpowers/ vs tasks/ vs docs/plans/)、artifact 契约、移交对象都不同,混用产生重复文档与路径冲突——整链择一。
• OpenSpec 正交可叠加:独立 openspec/ 目录 + delta 机制,不占用上述 docs/ 路径,可作为"规格真理层"与任一实现链并存。
• 轻重排序:内置 Plan < planning-and-task-breakdown < brainstorming/spec-driven < OpenSpec < ce-brainstorm < ce-work < ce-plan(最重)。

选型: 一次性小规划 → 内置 Plan Mode 或 agent-skills 轻链;重测试先行、要子代理照做不出错 → superpowers;大型高风险/接 lfg 全自动 → ce- 链;已有大代码库、多人多仓库、spec 当长期真理 → OpenSpec 做底座 + 上面挑一条实现链。

TDD / 测试与完成验证

各 skill 精读要点:

• superpowers/TDD:Iron Law “NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST”;先写实现就删了重来(“Delete means delete”);dot 状态机图编码 RED→verify→GREEN→verify→REFACTOR;两张反合理化表点名沉没成本谬误;Verify RED/GREEN 标 MANDATORY。纪律塑造最强,弱点:教条、缺测试分层/mock 纵深。
• agent-skills/TDD:重心在工程体系——Prove-It Pattern(bug 先写复现测试)、测试金字塔(80/15/5)、Small/Medium/Large 规模模型、mock 偏好序 Real>Fake>Stub>Mock、DAMP 而非 DRY、浏览器运行时验证(Chrome DevTools MCP)+ 安全边界。工程知识最全,弱点:强制力弱易被绕过。
• superpowers/verification-before-completion:140 行但强制程度最高。Gate Function:声称"完成/通过/修好"前必须 IDENTIFY→RUN→READ→VERIFY→才 claim;把"没验证就声称完成"定义为不诚实;Common Failures 表列每类声明需什么证据(如"agent 报告成功"不够,要查 VCS diff);“Great!/Perfect!/Done!” 都是 red flag。正交,可叠加任何流程后。弱点:只讲要证据、不讲怎么设计验证。
• 内置 verify:与 superpowers/verification 互补——它教你怎么驱动真实流程观察行为(有 how),端到端跑受影响的 flow 而非只跑测试/typecheck。
• superpowers/subagent-driven-development:同 session 内每 task 派全新 implementer 子代理(隔离上下文)→ 写 diff 文件 → task reviewer 双裁决 → fix 循环 → 全分支终审。独有文件化 handoff(避免把历史堆进控制器上下文)+ 模型分级选型 + .superpowers/sdd/progress.md durable ledger(防 compaction 后重复派发)。重,适合大型多 task plan。
• agent-skills/incremental-implementation:薄垂直切片(Implement→Test→Verify→Commit)。Rule 0 Simplicity First + Rule 0.5 Scope Discipline(“NOTICED BUT NOT TOUCHING” 记录不顺手改);阈值信号(>100 行没跑测试即红旗、第三次用例前别造抽象)。轻量单 agent 即可执行。

选型: 强纪律防偷懒 → superpowers/TDD;要团队测试规范 → agent-skills/TDD;收尾诚信闸门 → superpowers/verification(叠加)+ 内置 verify(驱动真实流程);大型 plan 自动执行 → subagent-driven-development;轻量单 agent 增量交付 → incremental-implementation。

代码简化(code simplification)

各 skill 精读要点:

• agent-skills/code-simplification:教学/判断力最强。四步(理解→识别→增量改→复查)+ 五原则;Chesterton’s Fence(查 git blame 再动)、以"新同事理解速度"而非行数为标尺、单列过度简化失败模式(过度内联/合并无关逻辑/删可测性抽象)、Rule of 500(大改动用 codemod/AST)。自包含可学,弱点:全靠自律、无编排。
• ce-simplify-code:唯一可自动落地。67 行运行手册:定 scope → 并行派 3 个 reviewer 子代理(code-reuse/code-quality/efficiency,rubric 逐字从磁盘 persona 传入)→ 逐条修(每条前自检行为保持)→ typecheck+lint+scoped 测试验证 → 按维度量化。Preflight 空扫描门(纯文档/机械 churn 跳过)、安全检查列为不可简化红线、禁止用净删行数邀功。弱点:“如何简化"知识全外置在 persona 文件,脱离 CE 生态难独用。
• 内置 simplify:介于两者之间——比 agent-skills 少教学厚度,比 ce- 少多视角编排,但零依赖随手可用;定位同 ce-simplify-code 而更轻。理想组合是「ce 的流程 × agent-skills 的原则」。

选型: 想学"何时该/不该简化” → agent-skills;PR 前一键分支级多视角简化 → ce-simplify-code;随手清理 → 内置 simplify。

总选型矩阵

两个贯穿全局的规律:

1. 强制手段光谱:内置(能力内嵌) → agent-skills(软引导) → superpowers(律令) → ce-(确定性协议)。越往右防偷懒越强,但越重、越绑生态。
2. 正交 vs 互斥:
   • 同来源内部是设计好的流水线(可叠);
   • 三条实现主链(superpowers / agent-skills / ce-)之间互斥(择一);
   • superpowers/verification、内置 verify、OpenSpec 是正交件,能跨链叠加;
   • OpenSpec 专精 spec 一类、其余四类缺席,所以它不是"第五条实现链",而是可垫在任一链下的规格真理底座。

附:各来源的完整 skill 清单(本次涉及范围)

• superpowers(14 篇):using-git-worktrees, test-driven-development, systematic-debugging, using-superpowers, dispatching-parallel-agents, executing-plans, finishing-a-development-branch, brainstorming, writing-plans, requesting-code-review, receiving-code-review, writing-skills, verification-before-completion, subagent-driven-development
• agent-skills(24 篇):idea-refine, debugging-and-error-recovery, using-agent-skills, test-driven-development, planning-and-task-breakdown, incremental-implementation, api-and-interface-design, ci-cd-and-automation, interview-me, context-engineering, frontend-ui-engineering, shipping-and-launch, spec-driven-development, code-review-and-quality, security-and-hardening, deprecation-and-migration, observability-and-instrumentation, code-simplification, doubt-driven-development, source-driven-development, performance-optimization, browser-testing-with-devtools, git-workflow-and-versioning, documentation-and-adrs
• compound-engineering(30 篇,ce- 前缀):sweep, ideate, polish, simplify-code, optimize, plan, code-review, commit, resolve-pr-feedback, dogfood, compound, doc-review, worktree, lfg, compound-refresh, work, test-xcode, setup, strategy, pov, proof, brainstorm, product-pulse, explain, riffrec-feedback-analysis, debug, test-browser, babysit-pr, commit-push-pr, promote
• OpenSpec:非 skill 集,是 CLI 框架(/opsx:explore|propose|apply|archive + openspec/ 目录 + delta spec)
• Claude 内置(流程类):code-review, review, security-review, simplify, verify, run, init, deep-research, loop 等(打包在 CLI 二进制内)