agent-skills（addyosmani/agent-skills）：把资深工程师的交付纪律写成 25 个智能体技能，并用三层评测证明它真的生效

一、导读

编码智能体最大的问题不是不会写代码，而是没人管得住它跳过流程。它会说「测试稍后补」，会在失败断言旁边加一个 @ts-ignore，会在你要求评审时自己把 diff 看一遍然后说「看起来没问题」。资深工程师的纪律——先写规格、测试为证、合并前评审、上线前检查——在人类团队里靠文化和评审传递，到了智能体这里全部失效：它写代码的速度远超你能逐行读完的速度。

addyosmani/agent-skills 要解决的就是这件事。它把 Google Chrome 团队的 Addy Osmani 及其协作者在真实项目里用的工程流程，写成 25 个结构化 SKILL.md，配 9 个生命周期斜杠命令、4 个评审角色 和 7 份共享检查清单，覆盖 DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP 六个阶段。截至 2026-11-11，仓库 ★115,865、当日涨星 788，MIT 许可。

它真正区别于同类的不是技能数量，而是两件事：每个技能都带一张「反合理化表」（把智能体用来跳过步骤的借口逐条反驳），以及仓库内自带三层评测框架——用确定性 CI 检查技能描述的路由准确率，再用真实模型调用验证技能是否真的改变了智能体行为。本文拆解它的技能解剖学、三层评测的工程细节、以及那些带具体数字的评测结论。

二、项目速览

维度	内容
仓库	`addyosmani/agent-skills`
作者/团队	Addy Osmani（Google Chrome 工程负责人之一）；协作者 Federico Bartoli、Joan León；13 位贡献者
主语言	JavaScript（技能本体为纯 Markdown）
Star 总数	115,865（2026-11-11，GitHub API）
当日涨星	788（GitHub Trending daily，2026-11-11 抓取）
Fork / Watcher	12,152
License	MIT
首次创建	2026-02-15
最新版本	plugin.json 0.6.15（2026-10-31）
技能数量	25 个（24 个生命周期技能 + 1 个 `using-agent-skills` 元技能）
官方站	https://skills.addy.ie

说明：仓库共 240 个文件，其中 skills/ 25 个、docs/ 17 篇、agents/ 4 个、references/ 7 份、evals/ 25 个用例文件加一整套 plugin eval。版本节奏约每两周一个小版本（0.6.4 于 2026-07-12，0.6.15 于 2026-10-31）。

三、为什么是它：问题背景与定位

痛点一：智能体写的代码，多到你读不完。 项目文档里有一句话点破了整个定位：「你写代码的时候，读一遍就知道好不好。智能体一个下午写的量，超过你那一周能读完的量，于是判断必须从你脑子里搬出来，搬进围着循环跑的检查里。」这句话解释了为什么这个仓库的重心不是「教智能体写代码」，而是「把判断固化成可机械检查的契约」。

痛点二：软约束在智能体面前会蒸发。 传统工程规范写在文档里、靠评审执行。但智能体面对的是一个具体的、当下的、想要变绿的处境——「我先把测试注释掉，稍后补上」在它那里是一个完全合理的局部最优。constraint-driven-development 这个技能就是专门为此设计的：它把质量栏写成 CONSTRAINTS.md，并且监视 diff 里有没有出现被削弱的门槛——新增的 @ts-ignore / eslint-disable / # noqa、被跳过或删除的测试、被剥掉的断言、未实现的桩函数、被调低的阈值。

痛点三：技能描述本身就是路由，写不好就白写。 这是最反直觉的一条。技能靠 description 被智能体发现——描述进系统提示词，智能体据此决定要不要加载完整技能。所以描述必须同时说清「做什么」和「什么时候用」。仓库明确警告：不要在描述里概括工作流，因为「如果描述里含流程步骤，智能体可能照着这个摘要执行，而不去读完整技能」。

涨星动因：Agent Skills 这个格式在 2026 年成了事实标准（Anthropic 的 anthropics/skills、Google 的 google/skills 都在推），而 Addy Osmani 的版本是其中唯一自带评测框架的。当社区开始意识到「技能写了到底有没有用」是个真问题时，一个用数字回答这个问题的仓库自然被推到台前。

四、架构原理

4.1 整体架构

agent-skills 是一个纯 Markdown 的技能包，没有任何运行时。它的「架构」指的是三层分发结构与一套评测闭环：

┌──────────── 分发层（同一份技能，多种宿主适配）────────────┐
│ npx skills add（70+ agents）· Claude Code marketplace    │
│ Codex plugin · Gemini CLI · Cursor · Copilot · Kiro ...  │
└────────────────────────┬─────────────────────────────────┘
                         │ 各宿主按约定扫描目录
┌────────────────────────▼─────────────────────────────────┐
│  便携核心（portable core）                                │
│  ┌────────────┐ ┌──────────┐ ┌──────────────┐            │
│  │ skills/    │ │ agents/  │ │ references/  │            │
│  │ 25 技能    │ │ 4 角色   │ │ 7 检查清单   │            │
│  └────────────┘ └──────────┘ └──────────────┘            │
│  ┌──────────────────────────────────────────┐            │
│  │ 宿主适配目录：.claude/ .gemini/ .codex-  │            │
│  │ plugin/ .agents/ commands/ hooks/        │            │
│  └──────────────────────────────────────────┘            │
└────────────────────────┬─────────────────────────────────┘
                         │ 每次改动都过闸门
┌────────────────────────▼─────────────────────────────────┐
│  评测闭环（evals/）                                       │
│  Tier 1 结构校验 ── CI，免费                              │
│  Tier 2 触发与路由（TF-IDF）── CI，免费                   │
│  Tier 3 行为评测（headless claude）── 按需，耗 token      │
│  Plugin eval（claude plugin eval，双臂对照）── 按需       │
└──────────────────────────────────────────────────────────┘

关键设计是便携核心与宿主适配分离。skills/、agents/、references/ 三个目录是所有宿主共用的；.claude/commands/、.gemini/commands/、.codex-plugin/、.agents/plugins/ 等则是各宿主的原生发现约定。文档特别强调：这些路径不是品牌别名，而是原生发现约定，重命名或合并会破坏扫描这些确切位置的工具。

4.2 分层模块拆解

技能层（skills/，25 个）：每个技能一个目录，SKILL.md 是唯一必需文件，可选带 scripts/（可执行辅助脚本）与 references/（技能专属参考）。25 个技能按生命周期六阶段分组：Define 4 个（interview-me、idea-refine、spec-driven-development、constraint-driven-development）、Plan 1 个、Build 7 个、Verify 2 个、Review 4 个、Ship 6 个，外加 1 个元技能 using-agent-skills。

角色层（agents/，4 个）：code-reviewer（资深 Staff 工程师视角，五轴评审）、test-engineer（QA 视角）、security-auditor（安全工程师视角）、web-performance-auditor（Web 性能视角）。它们被 /ship 并行 fan-out 调用。

共享参考层（references/，7 份）：definition-of-done、testing-patterns、security-checklist、performance-checklist、accessibility-checklist、observability-checklist、orchestration-patterns。

命令层（9 个斜杠命令）：/spec /plan /build /test /constraints /review /webperf /code-simplify /ship，与生命周期阶段一一对应。

评测层（evals/）：25 个技能各有一个 evals/cases/<skill>.json，加 evals/fixtures/ 里约 60 个真实项目输入，再加 evals/plugin/ 下的双臂对照用例。

4.3 核心机制：技能解剖学

每个技能遵循同一套结构，这是整个仓库最值得抄的部分：

┌─ Frontmatter（必需）────────────────────────┐
│ name: lowercase-hyphen-name               │
│ description: 做什么 + Use when 触发条件    │
└───────────────────────────────────────────┘
  Overview         → 这个技能做什么、为什么重要
  When to Use      → 触发条件 + 明确的不适用条件
  Process          → 分步工作流（核心）
  Rationalizations → 借口 + 反驳（表格）
  Red Flags        → 技能被违反的可观察信号
  Verification     → 退出条件（每项都要证据）

frontmatter 是硬契约。 顶层键被限制为 Agent Skills 规范允许的字段：name、description、license、compatibility、metadata、allowed-tools。model、tools、max_turns、context 这类厂商或运行时控制必须放进 metadata 或各宿主的适配文件——校验器会拒绝任何其他顶层键。description 上限 1024 字符，且必须同时含「做什么」与「何时用」。

「反合理化表」是最具辨识度的发明。 它把智能体跳过步骤时说的每一句话都列出来，配上事实性反驳。文档里的原话是：「想想每一次智能体说『我稍后再补测试』或者『这个够简单，规格就免了』——那些都进这张表，配上事实性反论。」

Verification 段不可协商。 每个技能以证据要求收尾：测试通过、构建输出、运行时数据。「看起来对」永远不够。

4.4 三层评测框架（本仓库最硬的工程贡献）

文档明确说：社区对「怎么评测 SKILL.md」没有统一标准，但有两个先行者——Anthropic 的 skill-creator v2（每个技能一个 evals.json，含 prompt 与 expectations[]，从对话记录评分）与 Superpowers（bash + claude -p + 提示词夹具 + 评分脚本）。本仓库采用了前者的 schema，并补上了两者都没有的东西：对多技能目录的确定性、CI 安全的检查。

层级	检查什么	何时跑	成本
Tier 1 结构	frontmatter、命名、必需段落、行数预算、`references/` 链接、命令一致性、产物路径、清单版本	CI（5 个校验脚本）	免费
Tier 2 触发与路由	正向提示词能把对应技能排进 top-k；负向提示词不会误触发；任意两个描述不近似碰撞	CI（`--min-rank1 95`）	免费
Tier 3 行为	遵循技能的智能体是否满足 `expectations[]`	按需（`--behavioral`）	耗 token

Tier 2 是路由的词汇近似（对描述做词干化 TF-IDF），它抓的是两类真实触发 bug：描述缺了用户实际会说的词（假阴性），以及描述过宽、压过正确的技能（假阳性）。文档给了一条很实用的判断：Tier 2 失败通常意味着「改描述」，而不是改评测。

Tier 3 支持两种产物类型：execution（默认，在一次性 git 仓库里跑，从 evals/fixtures/ 物化真实输入并提交为基线，评分器判读完整的 stream-json 执行轨迹，含工具调用）与 dialogue（技能产物就是对话本身，需人工审核豁免）。执行器以 --permission-mode acceptEdits 加预批准工具列表运行，确保它真的能改文件、跑命令、看 diff、提交，而不是被拒绝后改成叙述。轨迹在评分提示词里被围栏为不可信数据，并经 stdin 管道传给评分器（可能有数 MB，走 argv 会撞上操作系统参数长度上限）。

Plugin eval 是双臂对照。 claude plugin eval 加载整个插件、一次跑全部技能，对每个用例分别在装与不装插件两种情况下评分，报告里给出 Δ 列。文档提醒两条纪律：报告数字时必须固定 --model 并记录 Claude Code 版本（CLI 会自我更新，默认模型一天内变过两次）；用例的轮次预算给 10 以上。

4.5 性能优化与设计取舍

渐进披露压上下文。 启动时只有技能名与描述进上下文；完整 SKILL.md 只在智能体判定相关时才加载。配套三条硬规则：SKILL.md 保持在 500 行以内；描述要具体；优先用脚本而不是内联代码——「执行一个脚本不消耗上下文，只有它的输出消耗；内联代码块每次加载都要付费」。

共享 references 的取舍。 多技能共用的检查清单放在仓库根的 references/，而不是塞进某个技能目录。文档把两种替代方案讲得很清楚：复制到每个技能会漂移，让某个技能「拥有」它、其他技能伸手进去也会漂移。代价是便携性：整仓安装（如 Claude Code marketplace 插件）会带上 references/，但按技能单独安装只复制 skills/<name>/，那些链接就会指向空（issue #361）。

「写流程，不写补丁」是最有远见的一条。 规则是：如果一个步骤无法在不点名某个模型、某个模型版本或某个智能体的私有工具名的情况下被论证，那它属于 issue，不属于技能。文档引用了跨模型迁移的测量结果（WikiSkill，arXiv:2608.27454）警告：针对某个模型执行失败而写的技能，可能让更强的模型表现得比完全不用技能还差。要描述能力（「运行聚焦的测试命令」），而不是某个运行时恰好暴露的机制（run_command）。

4.6 与其他架构路线的差异

三条路线的分野在于「为哪个时刻优化」：本仓库组织的是整个产品生命周期（Define 到 Ship），带评审角色、反合理化护栏和仓库内评测框架；Superpowers（obra）偏向自主、重推理的长程运行，用子代理、严格管线和 git worktree 隔离；Matt Pocock 的 skills 是一位专家日常流程的锐利工具箱，招牌是「grill me」逐题盘问循环。仓库自己维护了一份 docs/comparison.md 做诚实对比，并刻意不列 star 数，理由是「各家博客引用差异极大且每周都在变」。

五、应用场景

场景一：绿地项目走完整生命周期

痛点：新项目最容易「先写代码、规格回头补」，等回头时已经没人记得当初为什么这么设计。

解决：用 9 个斜杠命令按阶段推进，每个阶段有一个人工检查点。

# 安装（任选其一）
npx skills add addyosmani/agent-skills              # 装全部 25 个技能
npx skills add addyosmani/agent-skills --list       # 先浏览再装

# Claude Code 原生插件
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

/spec        → 先写 PRD：目标、命令、结构、代码风格、测试、边界
/plan        → 拆成小而可验证的任务，带验收标准与依赖顺序
/build       → 一次一个垂直切片：实现、测试、验证、提交
/test        → 测试即证明
/constraints → 决定一次，处处执行
/review      → 合并前提升代码健康度
/ship        → 上线前检查清单

收益：/build auto 在规格确定后只需批准一次计划，即可自动生成计划并实现全部任务。文档特意说明它「移除的是任务之间的人工介入，而不是验证环节」——每个任务仍然测试驱动、单独提交，遇到失败或高风险步骤会暂停。

边界：绿地全流程适合新项目；存量代码库应走 docs/adoption-guide.md 里的验证优先渐进落地路径，而不是一次性全量套用。

场景二：给自主循环装上质量闸门

痛点：/build auto 这类自主循环最危险的时刻，是「挡在它和 main 之间的只有一套它自己写的测试」。

解决：先跑 /constraints，把质量栏写成 CONSTRAINTS.md。技能会先检测再提问——读 package.json/pyproject.toml/go.mod/Cargo.toml 判断技术栈，读 devDependencies 与 test 脚本判断测试运行器，读 coverage/ 判断当前覆盖率，读 .github/workflows/ 判断 CI，读 .claude/、.codex/、AGENTS.md 判断智能体宿主——「永远不要问你能读到的东西」。

然后只问四个问题，每个都有默认值，所以「我不知道」是一个完整答案：

Q1: 除了底线，还要强制哪些？(a) 新代码覆盖率 (b) 安全扫描
    (c) 性能预算 (d) 无障碍 (e) 架构边界
    猜测：(a)+(b)——你已经有测试运行器，而且在处理用户输入
Q2: 检查失败时阻塞还是警告？  猜测：阻塞
Q3: 有目标数字，还是我测量现状并守住这条线？  猜测：测量并守住
Q4: 智能体交回工作前，你能忍受最慢的检查多久？  猜测：约 90 秒

收益：产出的 CONSTRAINTS.md 含一个底线（Floor）——永远强制、无需配置：不新增抑制注释、不留未实现桩、不无理由跳过或删除测试、源码里不放密钥、这个文件本身不得为了让改动通过而被削弱。文档明确说「停在第 4 个问题」：十二题的问卷只会产出一份没人看得懂的配置和一个后悔开始的用户。

边界：这个技能需要真人交互，文档明确要求不要在 CI、/loop、自主运行等非交互场景里跑它；那种情况下应套用底线、注明已套用，并把其余部分标记给人处理。

场景三：高风险决策的对抗式复核

痛点：长会话会把假设悄悄变成「事实」，而一个自信的输出不等于正确的输出。

解决：doubt-driven-development 在决策还在飞行中时就引入一个偏向证伪而非批准的新上下文评审者。它明确区分于 /review：后者是对已完成产物的裁决，前者是飞行中的姿态。

Doubt cycle:
- [ ] Step 1: CLAIM      — 写下主张 + 为什么重要
- [ ] Step 2: EXTRACT    — 隔离产物 + 契约，剥掉推理过程
- [ ] Step 3: DOUBT      — 用对抗式提示词唤起新上下文评审者
- [ ] Step 4: RECONCILE  — 把每条发现对照产物文本分类
- [ ] Step 5: STOP       — 满足停止条件（发现变琐碎 / 3 轮 / 用户覆盖）

收益：最有价值的是 Step 3 的一条纪律——只传 ARTIFACT 与 CONTRACT，不要传 CLAIM。理由是「把你的结论交给评审者，会把它偏向同意」。对抗式提示词要求评审者「假设作者过度自信」，去找未言明的假设、未处理的边界、隐藏耦合、契约可能被违反的方式。

边界：技能明确列出不该用的场景——机械操作（重命名、格式化、移动文件）、遵循清晰无歧义的指令、阅读或总结既有代码、正确性显而易见的一行改动、纯工具操作。「如果每个按键都要怀疑，你什么都发布不了。」另有一条硬约束：不要把 doubt-driven 加进某个角色的 skills: frontmatter，因为角色会再唤起角色，这是 orchestration-patterns.md 明确禁止的编排反模式。

场景四：多宿主团队的统一交付纪律

痛点：团队里有人用 Claude Code、有人用 Cursor、有人用 Codex，工程规范没法统一。

解决：同一份 skills/ 通过不同适配器分发到 70+ 智能体。

# Codex（CLI v0.122+）
codex plugin marketplace add addyosmani/agent-skills
codex plugin add agent-skills@agent-skills

# Gemini CLI
gemini skills install https://github.com/addyosmani/agent-skills.git --path skills

# Antigravity CLI
agy plugin install https://github.com/addyosmani/agent-skills.git

收益：技能是纯 Markdown，任何接受系统提示词或指令文件的智能体都能用。仓库为 11 个宿主提供了专门的 docs/*-setup.md。

边界：各宿主的保真度不同。GitHub Copilot 里生命周期斜杠命令不出现，要按技能名直接调用；Cursor 需要把工作流技能放到 .cursor/skills/、短策略放 .cursor/rules/*.mdc，不要把完整技能粘进 rules；Antigravity CLI 某些版本里旧命令 TOML 会被报告为已转换但包装命令不可发现。

适用边界与不建议使用的场景

不要指望它替你写业务逻辑：它编码的是流程与质量栏，不是领域知识。
不要在非交互场景跑 /constraints：它需要真人回答四个问题。
不要按技能单独安装后依赖共享清单：按技能安装不会复制仓库根 references/（issue #361）。
不要为特定模型写「补丁式」技能步骤：跨模型迁移测量显示这可能让更强的模型表现更差。
不要把角色串成链：personas don't invoke personas 是硬规则。

六、快速上手

# 最快路径：一条命令装进 70+ 智能体
npx skills add addyosmani/agent-skills

# 只装单个技能
npx skills add addyosmani/agent-skills --skill code-review-and-quality
npx skills add addyosmani/agent-skills --skill interview-me
npx skills add addyosmani/agent-skills --skill test-driven-development

# 本地开发
git clone https://github.com/addyosmani/agent-skills.git
claude --plugin-dir /path/to/agent-skills

# 跑评测（Tier 2 免费，CI 安全）
node scripts/run-evals.js
node scripts/run-evals.js --min-rank1 95

# 跑行为评测（耗 token）
node scripts/run-evals.js --behavioral test-driven-development --dry-run

项目级覆盖：部分技能需要项目特定事实（规格与计划存哪、怎么起开发服务器、智能体能否建分支、派发器用哪种面向用户语言）。默认值已内置，任何项目都可以用 .ai/agent-skills-overrides.md 单文件覆盖。

七、横向对比

维度	agent-skills	Superpowers（obra）	Matt Pocock's skills
核心思想	把完整资深工程生命周期编码成技能	基于可组合技能的完整开发方法论	一位专家的 Claude Code 工作流
组织原则	SDLC 六阶段 + 元技能路由	单一纪律循环：头脑风暴→计划→执行→评审	聚焦、可组合的命令工具箱
技能数量	25（覆盖全生命周期）	约 14（深挖内层构建循环）	约 30（工程/效率/进行中/已废弃）
生命周期覆盖	广：创意、API/UI 设计、安全、性能、CI/CD、可观测性、废弃、ADR、上线	深但窄：TDD、调试、计划、评审、技能编写	偏 Define 与 Build：盘问、PRD、issue、TDD、架构
标志性机制	反合理化表 + Red Flags + 并行评审角色 + 三层评测框架	子代理驱动开发 + 任务评审者 + worktree 隔离 + 技能写技能	grilling 原语（一次一问、走设计树）
质量度量	触发、路由、行为三层评测（部分在 CI）	压力测试是方法论核心，评测套件已迁至独立仓库	仓库内未提供
工具覆盖	Claude Code、Cursor、Gemini CLI、Antigravity、OpenCode、Windsurf、Copilot、Kiro、Codex、Command Code + `npx skills`	覆盖最广且迭代最活跃	Claude Code 优先
治理	积极评审并合并社区贡献，每个技能都带 eval	基本单人作者，有大量未合并 PR 积压	单人作者，自行合并，公开开发
License	MIT	见仓库	见仓库

四维小结：能力上本仓库生命周期覆盖最广，但「广」意味着单点深度不如 Superpowers；性能上渐进披露把常驻上下文压到只剩技能名与描述，代价是每次加载要多一跳；生态上 70+ 智能体加 11 份宿主文档是最像「产品」的一个；成本上 MIT 免费，真正的成本是你得先想清楚自己的质量栏是多少。

八、局限、风险与社区观察

维护活跃度（正面信号）：2026-02-15 创建，pushed_at 为 2026-11-01，12 个正式版本从 0.6.4（2026-07-12）到 0.6.15（2026-10-31）。提交记录显示近期主线集中在评测与质量闸门：Merge #736: validate review findings against code and baseline、Merge #694: enforce security and accessibility quality gates、Merge #758: say git-workflow applies when the diff is pasted inline。最后一条尤其能说明这个项目的性格——它把「技能描述怎么改才能提高触发率」当成一个需要合并 PR 来验证的工程问题。

License 风险：MIT，商用友好，无附加条款。

生产可用性风险：

技能触发是随机的。 这是官方自己公布的数字，也是最有价值的一条诚实披露。在 Claude Code 2.1.278 + claude-opus-5 上，评审技能在用例措辞下7 次里只触发 5 次；TDD 技能在「测试优先」提示词上 7 次里触发 2 次。文档的结论是：「读 Δ 和报告，而不是读退出码。」
描述里的一句话能带来数量级差异。 官方记录：给评审技能加上「即使 diff 是内联粘贴的也适用」这一句后，四种评审措辞的触发率从 7/27 提升到 21/27，而九个相邻的「必须不触发」提示词两种情况下都是 0/27。TDD 技能同样处理，四个提示词从 6/24 提升到 19/24，八个必须不触发的提示词保持 0/24。代码简化技能从 0/9 提升到 8/9，五个必须不触发的提示词保持 0/15。文档同时承认这「是变好了，但没有解决」——最平实的措辞仍只从 0/9 到 3/9。
技能可能在不被调用的情况下影响输出。 官方观察到一次运行中评审技能没有触发，但回复仍然使用了它的严重度分类作为标题，而九次基线运行里都没有出现这种情况。推测是「已加载的技能描述可能在不发生调用的情况下塑造回复」。
按技能安装会丢共享清单（issue #361），这是已知的便携性缺口。
部分宿主保真度不足：Antigravity CLI 某些版本的包装命令不可发现；Copilot 里斜杠命令不出现。
行为评测的通过率并不完美：TDD 用例中，技能每次都触发了，但「先写失败测试再修」的顺序在装插件时 4 次里只有 2 次、不装时 3 次里 0 次。文档把这种失败定性为「技能在无 shell 会话里的遵循缺口，而不是路由问题」。

社区观察：讨论集中在两点。一是「技能到底是文档还是代码」——本仓库的答案很明确：是代码，因为它有 schema 校验、有 CI、有评测、有回归台账（evals/skill-impact.md 是一份只追加的「被评测证据否决的技能改动」账本，让贡献者在提重叠工作前能先查历史尝试）。二是「跨模型可迁移性」——Write the Procedure, Not the Workaround 那一节引用的 WikiSkill 结论（针对弱模型失败写的技能会让强模型表现更差）在社区里被反复引用，它把「提示词工程」推向了一个更严格的工程标准。

九、小结与行动建议

先只装一个技能试水：建议从 code-review-and-quality 开始，因为它有最完整的官方触发率数据（21/27）和明确的「必须不触发」对照，最容易验证它在你团队里是否真的生效。
把「反合理化表」当成你的模板：即使你不打算用这个仓库，也值得抄它的技能结构——尤其那张把智能体借口逐条反驳的表，以及「Verification 必须可验证」这条纪律。
在跑自主循环之前先跑 /constraints：/build auto 这类模式的价值取决于质量栏是否被写下来。四个问题、90 秒预算、一个 CONSTRAINTS.md，成本很低。
给高风险决策加 doubt 循环，但别滥用：只对「不可逆、跨边界、类型系统无法验证」的决策用，最多 3 轮，且绝不把 CLAIM 传给评审者。
报告触发率时固定模型与版本：官方明确要求「报告数字时固定 --model 并记录 Claude Code 版本」，因为 CLI 会自我更新、默认模型一天内变过两次。不固定版本的数字没有可比性。

数据来源与获取日期：GitHub API /repos/addyosmani/agent-skills、/releases、/git/trees/main?recursive=1（2026-11-11）；GitHub Trending daily 榜（2026-11-11 抓取）；仓库一手文件读取（README.md、plugin.json、docs/skill-anatomy.md、docs/comparison.md、evals/README.md、evals/skill-impact.md、skills/constraint-driven-development/SKILL.md、skills/doubt-driven-development/SKILL.md，2026-11-11 读取）；Addy Osmani 官方站 https://skills.addy.ie ；第三方目录页（agenticskills.io、claudemarketplaces.com、deps.dev、skillsmp.com）。文中触发率数字全部来自仓库 evals/README.md 的官方记录，模型与版本已在原文标注；docs/comparison.md 刻意不列 star 数，本文的 star 数据来自 GitHub API。标注「待确认」处为无法从一手来源核实的信息。