基于 Anthropic Skills（含 skill-creator）+ addyosmani/agent-skills + obra/superpowers 三大开源框架，针对自主研发、前后端分离、集成总线架构的历史项目，提炼出一套可复用的 Skill 创建方法论。

---

前言：为什么陈旧项目最需要 Skill？

AI Coding 工具在"从零搭建新项目"上表现惊艳，但面对运行了五年以上的陈旧系统时，往往会踩进同一个坑：架构约束不了解、历史决策不清楚、隐式规则不掌握。结果就是——AI 改了代码，却破坏了系统稳定性。

Skill（技能文件）正是解决这个问题的钥匙。它不是"写一份说明文档"，而是将团队积累的项目知识编码为 AI 可执行的约束化工作流。

本文基于一套在大型遗留系统上验证过的 Skill 创建体系，提炼出通用的方法论和最佳实践。

---

一、整体策略：并行推进，先精后广

在陈旧项目上构建 Skill 体系，建议采用双轨并行策略：

通用 Skill（社区模板直接使用）
├── test-driven-development        ← 测试驱动开发
├── code-review-and-quality        ← 代码审查与质量
├── incremental-implementation     ← 增量实现
├── context-engineering            ← 上下文工程
└── debugging-and-error-recovery   ← 调试与错误恢复

            │ 并行推进 │

项目专属 Skill（Skill Creator 创建，先做 3~5 个）
├── integration-adapter-dev        ← P0：集成适配器开发
├── spec-reverse-extract           ← P0：老代码反向提取规格
├── legacy-migration               ← P1：老代码安全迁移
├── compliance-check               ← P1：合规检查
└── third-party-adapter-dev        ← P2：第三方适配器开发

核心原则：

• 通用 Skill 解决"怎么写好代码"的问题，社区有大量成熟模板
• 项目专属 Skill 解决"在这个项目里怎么写才对"的问题，必须自己创建
• 先集中精力做好 3~5 个最关键的项目专属 Skill，稳定后再扩展

---

二、Skill 创建方法论：六步评估驱动法

来源：Claude Platform Docs 评估驱动开发 + Anthropic Skill Creator 四模式

┌─────────────────────────────────────────────────────────────────┐
│                    Skill 创建六步法                              │
│                                                                  │
│  Step 1: 识别差距    Step 2: 创建评估    Step 3: 建立基线      │
│  不用 Skill 完成     基于失败点构建      测量无 Skill 时         │
│  一个代表性任务      3 个测试场景        的表现指标              │
│                                                                  │
│  Step 4: 写最小指令  Step 5: 迭代优化    Step 6: 渐进式扩展     │
│  用 Skill Creator    Claude A/B 双代理   从 1 个 Skill 开始     │
│  生成 SKILL.md 草稿  模式反复打磨        稳定后加下一个          │
└─────────────────────────────────────────────────────────────────┘

Step 1：识别差距（陈旧项目最关键的一步）

不用任何 Skill，让 AI 完成一个代表性任务，记录三类信息：

记录维度	示例
AI 在哪里犯错	“AI 修改了适配器的数据格式但没有更新对应的规格文档”
AI 缺失什么上下文	“AI 不知道业务层不能直接调用中间件，必须经过适配层”
AI 反复问你什么	“这个接口编号对应哪个后端系统？”（出现了 5 次）

这一步的目的是精准定位 AI 在项目中的知识盲区——这些盲区就是 Skill 需要填补的内容。

Step 2：创建评估

基于 Step 1 的失败点，构建 3 个测试场景，每个场景包含：

• prompt：用户实际会说的话（模拟真实工作场景）
• expected_behavior：具体可验证的预期行为列表

{
  "skill_name": "integration-adapter-dev",
  "evals": [
    {
      "id": 1,
      "prompt": "在适配器中新增一个查询接口，需要传入客户 ID，返回等级和等级名称",
      "expected_behavior": [
        "读取 specs/ 中的相关规格文档",
        "读取 rules/ 中的接口规范",
        "生成的数据包含追踪 ID",
        "敏感字段使用加密",
        "新增字段为可选并提供默认值",
        "运行接口验证脚本"
      ]
    },
    {
      "id": 2,
      "prompt": "修改现有查询接口的返回字段，新增一个类型字段",
      "expected_behavior": [
        "检查向后兼容性（新增字段必须可选）",
        "更新对应的规格文档",
        "运行影响面分析",
        "通知相关团队"
      ]
    },
    {
      "id": 3,
      "prompt": "在业务层直接调用中间件发送查询请求",
      "expected_behavior": [
        "拒绝在业务层直接调用中间件",
        "提示必须通过适配层",
        "说明架构约束原因"
      ]
    }
  ]
}

Step 3：建立基线

在引入 Skill 之前，先记录当前 AI 的表现指标，作为后续对比的基准：

指标	无 Skill	目标（有 Skill）
任务通过率	记录实际值	> 80%
架构约束违反次数	记录实际值	0
Token 消耗	记录实际值	减少 > 30%
人工纠正轮次	记录实际值	减少 > 50%

没有基线就没有优化方向——这是评估驱动开发的核心思想。

Step 4：用 Skill Creator 生成 SKILL.md 草稿

在 Claude Code 中启动 Skill Creator（GitHub 仓库）：

/skill skill-creator

告诉它项目的关键信息：

我要创建一个名为 integration-adapter-dev 的 Skill，用于在适配层开发。
这个项目的特殊约束是：
1. 所有中间件交互必须通过适配层
2. 数据格式遵循 rules/接口规范.md
3. 每个请求必须携带追踪 ID
4. 敏感字段加密
5. 变更后必须运行接口验证和影响面分析

Skill Creator 会自动完成：意图澄清 → 编写 SKILL.md → 创建测试用例 → 运行评估。

Step 5：Claude A/B 双代理迭代（详解）

这是整个方法论中最核心的质量打磨机制。它不是简单的"改完再测一遍"，而是一种对抗式的 Skill 优化方法。

5.1 核心概念

A/B 双代理迭代把 Skill 的优化过程拆成两个独立角色，让它们相互博弈：

    Claude A（专家/设计师）              Claude B（用户/执行者）
┌──────────────────────────┐      ┌──────────────────────────┐
│                          │      │                          │
│  加载 Skill Creator      │      │  加载待测试的 Skill       │
│  知道"好的 Skill 长什么样" │      │  不知道 Skill 的设计意图   │
│  负责设计和优化 Skill     │      │  负责执行真实的项目任务    │
│                          │      │                          │
└──────────────────────────┘      └──────────────────────────┘
          │                                    │
          │        ① 生成/修改 SKILL.md        │
          │ ─────────────────────────────────→ │
          │                                    │
          │        ② 执行任务，记录失败点       │
          │ ←───────────────────────────────── │
          │                                    │
          │        ③ 根据反馈优化 Skill        │
          │ ─────────────────────────────────→ │
          │                                    │
          │         ... 循环直到达标 ...        │
          │                                    │

关键机制：A 和 B 是两个独立的 AI 会话，互不共享上下文。B 只能看到 SKILL.md 的内容，完全不知道 A 的设计意图。这种"信息不对称"正是暴露 Skill 缺陷的核心——它模拟了一个刚拿到 Skill 文档的真实开发者场景。

5.2 为什么要这样设计？

普通做法（同一个人既写 Skill 又用它测试）有个致命问题：

你知道自己写了什么，测试时会不自觉地按照设计意图去理解 Skill，漏掉那些表述不清、模棱两可的地方。

A/B 分离后：

角色	知道什么	不知道什么
A（设计师）	Skill 的完整设计意图、项目背景知识	B 在实际执行中会遇到什么障碍
B（执行者）	只有 SKILL.md 的内容	A 的意图、项目的隐式知识、约定俗成的规则

B 就像一个"刚拿到 Skill 的新同事"——它能不能独立正确地完成任务，直接暴露了 Skill 写得好不好。

5.3 具体操作步骤

准备工作：打开两个独立的 Claude Code 会话（终端 A 和终端 B）。

---

第一轮迭代

终端 A（设计师）：

# 启动 Skill Creator
/skill skill-creator

# 告诉它你要创建/优化一个 Skill
我要优化 integration-adapter-dev 这个 Skill。
当前版本在 project/skills/integration-adapter-dev/SKILL.md。
请先读取当前版本。

A 读取当前 Skill，根据 Step 1~4 的积累生成优化版本，写入文件。

终端 B（执行者）：

# 加载 A 刚刚写好的 Skill（B 不需要启动 Skill Creator）
# 直接在当前会话中执行真实项目任务：

请帮我在适配层新增一个客户等级查询接口。
需求：传入 customerId，返回 level 和 levelName。

B 执行任务。在这个过程中，重点观察四个维度：

#	检查点	观察方式
1	B 是否遵循了架构约束？	B 有没有绕过适配层直接调中间件？
2	B 是否读取了正确的 Spec 和 Rules？	B 的引用路径是否正确？读取顺序是否符合 Process？
3	B 是否在修改后运行了验证？	B 改完代码后有没有运行 contract-verify？
4	B 在哪些步骤反复卡住或出错？	B 在哪里问了问题？哪个步骤跳过了？

---

反馈循环

B 执行完后，把失败点和问题整理成反馈，回到终端 A：

B 在执行时出现了以下问题：
1. B 没有读取 rules/接口规范.md，直接写了数据格式
2. B 把新字段设为了必填，违反了"新字段必须可选"的约束
3. B 在改完代码后没有运行 contract-verify

请根据这些反馈优化 Skill，让这些错误不再发生。

A 据此修改 Skill（不是直接告诉 B 答案，而是改进 Skill 的表述），然后 B 再次执行同一个任务验证。

---

迭代终点

当 B 连续 3 次执行不同任务都能满足所有 expected_behavior 时，这一轮迭代结束。

5.4 常见误区

误区	正确做法
用同一个会话既当 A 又当 B	必须两个独立会话，B 不知道 A 的设计意图
A 看到 B 出错后直接告诉 B 怎么做	A 应该修改 Skill 让 Skill 引导 B 做对，而不是"作弊"
只用一个任务测试	至少用 3 个不同任务，覆盖正常、边界、异常场景
B 的任务太简单	必须用真实的、有代表性的项目任务
迭代一次就认为完成了	必须换不同任务连续验证，单个任务通过不代表 Skill 完善

5.5 完整迭代示例

以打磨 legacy-migration 这个 Skill 为例：

Round 1：

• A 写了第一版 SKILL.md
• B 接到任务：“把订单查询模块从 AngularJS 迁移到 Vue”
• B 直接改了代码，没加回归测试，没创建特性开关
• 反馈：Skill 的 Process 中 Step 3（写回归测试）和 Step 4（创建特性开关）约束不够强

Round 2：

• A 在 Process 中给 Step 3 和 Step 4 加了 MUST 标记
• B 再次执行，这次写了回归测试，但仍然没创建特性开关
• 反馈：Rationalizations 表缺少"这个改动太小不需要特性开关"的借口反驳

Round 3：

• A 在 Rationalizations 表中新增：“I don’t need a feature flag for this small change” → “All migrations need rollback capability. Feature flags are mandatory.”
• B 再次执行，所有步骤正确完成
• 通过，换一个新任务验证

Round 4（换任务验证）：

• B 接到新任务：“升级依赖库版本”
• B 正确完成了所有步骤
• 继续换第三个任务验证…

Round 5（第三个不同任务）：

• B 接到新任务：“替换已废弃的接口调用”
• B 再次正确完成
• 连续 3 个不同任务通过 → 本轮迭代结束，Skill 达到可交付标准

5.6 一句话总结

A/B 双代理迭代 = 用两个互不知情的 AI 会话模拟"Skill 设计师"和"Skill 使用者"的对抗博弈，通过 B 的真实执行反馈来暴露 Skill 的表述缺陷，A 据此持续优化，直到 B 能独立正确地完成所有任务。

Step 6：渐进式扩展

第一个 Skill 稳定后（通过率 > 80%，稳定运行 2 周），再创建下一个。

推荐顺序：

integration-adapter-dev → spec-reverse-extract → legacy-migration → compliance-check

不要一口气创建所有 Skill——每个 Skill 都需要在实际使用中打磨，贪多嚼不烂。

---

三、Skill 标准解剖结构

每个 Skill 必须包含以下七个部分。来源：addyosmani/agent-skills 解剖结构 + Claude Platform Docs 规范。

skill-name/
├── SKILL.md                  # 主文件（<500 行）
│   ├── YAML Frontmatter      # name + description（必须）
│   ├── Overview              # 2~3 句概述
│   ├── When to Use           # 触发条件（具体场景）
│   ├── Process               # 分步工作流（可勾选清单）
│   ├── Rationalizations      # 借口 + 反驳（陈旧项目关键！）
│   ├── Red Flags             # 出问题的迹象
│   └── Verification          # 证据要求（不可协商）
│
├── references/               # 按需加载的参考文档
│   ├── message-guide.md      # 接口编写详细指南
│   └── service-map.yaml      # 接口清单
│
├── scripts/                  # 可执行脚本
│   └── validate-message.py   # 格式验证脚本
│
└── evals/                    # 评估用例
    └── evals.json            # 3+ 个测试场景

Frontmatter 规范

---
name: integration-adapter-dev
description: Develop and modify integration adapter code in the adapter layer.
Use when working with adapter modules, message formats, backend system integration,
interface changes, or data format modifications.
Make sure to use this skill whenever the user mentions integration, adapter,
message bus, backend system calls, or needs to add/modify interface-based
interactions, even if they don't explicitly mention "adapter".
---

Description 撰写原则

原则	说明
第三人称	“Use when…” 而非 “I help you…”
做什么 + 何时用	两者缺一不可
Pushy 但不夸张	“Make sure to use this skill whenever…”
包含边界情况	什么情况下不应该触发
包含关键词	集成、适配器、接口编号、数据格式、消息总线

---

四、陈旧项目 Skill 的四个关键设计原则

原则	说明	陈旧项目应用
流程，非散文	Skill 是工作流（步骤+检查点+退出标准），不是参考文档	不要写"项目历史介绍"，写"修改适配器时的 5 个必须步骤"
反合理化	每个 Skill 包含一张"常见借口表"，附带文档化的反驳论据	老项目开发者最容易说"这代码五年没动过，不用加测试"
验证不可协商	以证据要求结束——测试通过、构建输出。"看起来对"永远不够	接口变更后必须运行合约验证
渐进式披露	SKILL.md 是入口（<500行），引用文件按需加载	老项目知识图谱作为引用文件，不常驻上下文

反合理化表的设计

这是陈旧项目 Skill 最有特色的部分。每个 Skill 都应包含一张这样的表格：

常见借口	反驳论据
“这只是一个小改动，不需要验证”	陈旧系统中，最小的改动也可能触发隐藏依赖。所有变更必须验证。
“这代码明显是错的，我迁移时顺便改掉”	迁移和重构是不同关注点。行为修复应放在单独的变更中。
“我不需要特性开关来处理这么小的变更”	所有迁移都需要回滚能力。特性开关是强制要求。
“旧测试已经覆盖了”	陈旧代码通常缺乏测试。迁移前必须补充回归测试。
“这只是测试数据”	测试环境必须使用合成数据。真实数据永远不应出现在非生产环境。
“日志只用于调试”	日志必须脱敏。调试用追踪 ID，不用敏感数据。

---

五、三个核心项目专属 Skill 模板

Skill 1：integration-adapter-dev（P0 —— 最先创建）

---
name: integration-adapter-dev
description: Develop and modify integration adapter code in the adapter layer.
Use when working with adapter modules, message formats, backend system integration,
or interface changes. Make sure to use this skill whenever the user mentions
integration, adapter, message bus, backend system, or interface definitions.
---

## Overview

Guides all development in the adapter layer. This is the sole entry/exit point
for all backend system interactions.

## When to Use

- Adding, modifying, or removing interface calls
- Changing data exchange formats
- Debugging async message flow issues
- Integrating with a new backend system

## Process

Task Progress:
- [ ] Step 1: Read the relevant Spec from `specs/capabilities/`
- [ ] Step 2: Read `rules/接口规范.md` for format rules
- [ ] Step 3: Read `rules/适配器规范.md` for integration rules
- [ ] Step 4: Implement the change in the adapter layer
- [ ] Step 5: Run `contract-verify` to validate format compliance
- [ ] Step 6: If format changed, run `diff-analysis` for impact assessment
- [ ] Step 7: Update Spec in `specs/capabilities/` if behavior changed
- [ ] Step 8: Update `knowledge-graph/interface-map.yaml`

## Architecture Constraints (MUST NOT violate)

1. **NEVER call backend systems directly from the business layer.**
   Always route through the adapter layer.
2. **Every outbound request MUST carry a TraceID.** No exceptions.
3. **Sensitive fields MUST be encrypted.** See `rules/接口规范.md`.
4. **New fields MUST be optional with default values.**
   Backward compatibility is mandatory.
5. **Deleted fields require a new interface version.**
   Never remove fields from existing interfaces.

## Rationalizations

| Excuse | Refutation |
|--------|-----------|
| "This is a small change, no need to verify" | Even the smallest change in legacy systems can trigger hidden dependencies. Always verify. |
| "I'll add the TraceID later" | TraceID is non-negotiable. Without it, production debugging is impossible. |
| "This field is obviously safe to make required" | Backward compatibility is mandatory. All new fields must be optional. |

## Verification

- [ ] Contract verification passed
- [ ] Diff analysis shows expected impact
- [ ] Spec updated
- [ ] Interface map updated
- [ ] TraceID present in all outbound requests

Skill 2：spec-reverse-extract（P0 —— 从代码反向提取规格）

---
name: spec-reverse-extract
description: Extract structured Specifications from existing legacy code using
knowledge graph and code analysis. Use when the project lacks formal Specs, when
onboarding new team members, or when documenting existing system capabilities
from code rather than writing Specs from scratch.
---

## Overview

Reverse-engineers formal Specs (Given/When/Then format) from legacy code that
lacks documentation. Uses the codebase knowledge graph to trace call paths and
extract behavior patterns.

## When to Use

- Documenting an existing capability that has no Spec
- Onboarding new team members to understand existing system behavior
- Preparing for a legacy module refactor or migration
- Auditing existing integrations for compliance

## Process

Task Progress:
- [ ] Step 1: Identify the target capability (e.g., "order query flow")
- [ ] Step 2: Use knowledge graph to trace the full call chain:
  `Business Layer → Adapter Layer → Message Bus → Backend System`
- [ ] Step 3: Extract interface IDs, request fields, and response fields from code
- [ ] Step 4: Identify normal and error scenarios from exception handling code
- [ ] Step 5: Generate Spec in Given/When/Then format
- [ ] Step 6: Review with domain expert for accuracy
- [ ] Step 7: Save to `specs/capabilities/{capability-name}.spec.md`

## Output Format

```markdown
# Spec: {Capability Name}

## 概述
[Auto-generated from code analysis]

## Requirements

### Requirement: {Requirement Name}
[Extracted from service method]

#### Scenario: Normal flow
- GIVEN [extracted from input validation]
- WHEN [extracted from method invocation]
- THEN [extracted from return processing]
- AND [extracted from additional processing]

#### Scenario: Error flow
- GIVEN [extracted from exception handling]
- WHEN [extracted from error condition]
- THEN [extracted from error response]

## Verification

- [ ] Spec reviewed by domain expert
- [ ] All interface IDs correctly extracted
- [ ] All error codes documented
- [ ] Call chain verified with knowledge graph trace

Skill 3：legacy-migration（P1 —— 安全迁移）

---
name: legacy-migration
description: Safely migrate legacy code modules following Chesterton's Fence
principle. Use when refactoring old code, upgrading dependencies, migrating
between frontend frameworks, or replacing deprecated patterns.
---

## Overview

Guides safe migration of legacy code. Every migration must preserve existing
behavior, include rollback plans, and pass regression tests.

## When to Use

- Refactoring a module that hasn't been touched in > 1 year
- Migrating between frontend frameworks (e.g., AngularJS to Vue)
- Upgrading dependencies with breaking changes
- Replacing deprecated interfaces

## Process

Task Progress:
- [ ] Step 1: Run `detect_changes` to map impact radius
- [ ] Step 2: Extract current behavior as Spec (use `spec-reverse-extract`)
- [ ] Step 3: Write regression tests that pass on current code
- [ ] Step 4: Create feature flag for the migration
- [ ] Step 5: Implement migration behind feature flag
- [ ] Step 6: Run regression tests — MUST pass before proceeding
- [ ] Step 7: Enable feature flag in test environment, monitor for 1 week
- [ ] Step 8: Enable in production, monitor for 1 week
- [ ] Step 9: Remove old code and feature flag

## Chesterton's Fence Rule

Before removing or changing any legacy code, you MUST understand WHY it exists.
If you cannot explain the original purpose, do not modify it.

## Rationalizations

| Excuse | Refutation |
|--------|-----------|
| "This code is obviously wrong, I'll fix it while migrating" | Migration and refactoring are separate concerns. Fix behavior in a separate change. |
| "I don't need a feature flag for this small change" | All migrations need rollback capability. Feature flags are mandatory. |
| "The old tests cover this" | Legacy code often lacks tests. Always add regression tests before migrating. |

## Verification

- [ ] Regression tests pass on current code
- [ ] Regression tests pass on migrated code
- [ ] Feature flag tested (on/off) in test environment
- [ ] Rollback plan documented and tested
- [ ] Monitoring dashboard shows no anomalies after 1 week

---

六、Skill 评估体系

评估结构

{
  "skill_name": "integration-adapter-dev",
  "baseline": {
    "pass_rate": "记录无 Skill 时的通过率",
    "token_usage": "记录无 Skill 时的 Token 消耗",
    "correction_rounds": "记录无 Skill 时的人工纠正轮次"
  },
  "target": {
    "pass_rate": "> 80%",
    "token_usage": "减少 > 30%",
    "correction_rounds": "减少 > 50%"
  },
  "evals": [
    {
      "id": 1,
      "prompt": "用户实际会说的话",
      "expected_behavior": ["具体可验证的行为1", "行为2", "行为3"],
      "should_trigger_skill": true
    }
  ]
}

评估运行命令

# 1. 启动评估
python -m scripts.aggregate_benchmark <workspace>/iteration-1 --skill-name integration-adapter-dev

# 2. 查看评估报告
python eval-viewer/generate_review.py <workspace>/iteration-1 --skill-name integration-adapter-dev

# 3. 描述优化（提升触发准确率）
python -m scripts.run_loop --eval-set trigger-eval.json \
  --skill-path skills/integration-adapter-dev --max-iterations 5

---

七、Skill 质量检查清单

创建每个 Skill 后必须通过以下检查：

核心质量

• Description 具体且包含关键词（做什么 + 何时用）
• Description 使用第三人称
• SKILL.md 正文在 500 行以内
• 额外细节在 references/ 中（如需要）
• 全文术语一致
• 文件引用仅一层深
• Process 有可勾选的步骤清单

陈旧项目特有

• Rationalizations 包含至少 3 条老项目常见借口 + 反驳
• Architecture Constraints 明确标注 MUST NOT violate
• 老项目特有的架构约束被显式列出（如"业务层不直接调用中间件"）

代码与脚本

• 脚本显式处理错误（不踢给 AI）
• 无魔法数字（所有值有注释）
• 关键操作有验证步骤

测试

• 至少 3 个评估用例
• 包含 should-trigger 和 should-not-trigger 查询
• 用真实老项目任务测试过
• 描述优化器运行过（触发准确率 > 80%）

---

八、项目目录集成参考

project/
├── skills/
│   ├── integration-adapter-dev/   ← 项目专属 Skill 1（P0）
│   │   ├── SKILL.md
│   │   ├── references/
│   │   ├── scripts/
│   │   └── evals/
│   ├── spec-reverse-extract/      ← 项目专属 Skill 2（P0）
│   ├── legacy-migration/          ← 项目专属 Skill 3（P1）
│   ├── compliance-check/          ← 项目专属 Skill 4（P1）
│   ├── third-party-adapter-dev/   ← 项目专属 Skill 5（P2）
│   ├── [Superpowers Skills]       ← 通用 Skill（[obra/superpowers](https://github.com/obra/superpowers)）
│   └── [agent-skills 参考]        ← 通用 Skill 模板参考（[addyosmani/agent-skills](https://github.com/addyosmani/agent-skills)）
│
├── specs/                         ← spec-reverse-extract 输出目标
├── rules/                         ← Skills 引用的规范文档
├── knowledge-graph/               ← Skills 引用的知识图谱
└── mcp/
    └── codebase-memory.json       ← Skills 依赖的代码分析工具

---

九、总结

一句话总结：陈旧项目 Skill 创建不是"写文档"，而是"编码工作流"——用 Skill Creator 的评估驱动开发法，为每个项目专属场景创建包含反合理化表的精准 Skill。先做 3~5 个最关键的项目专属 Skill，与通用 Skill 并行推进，每个 Skill 必须通过 3 个评估用例 + 触发准确率 > 80% 才能投入使用。

核心要点回顾

1. 双轨并行：通用 Skill（社区模板）+ 项目专属 Skill（自建），同时推进
2. 六步评估驱动：识别差距 → 创建评估 → 建立基线 → 生成草稿 → A/B 迭代 → 渐进扩展
3. 四原则：流程非散文、反合理化、验证不可协商、渐进式披露
4. 反合理化表：陈旧项目 Skill 的灵魂——预判开发者会找的借口并文档化反驳
5. 先精后广：先做好 3~5 个 P0/P1 Skill，稳定运行 2 周后再扩展

推荐启动路径

阶段	时间	动作
第 1 周	识别差距	不用 Skill 完成 3~5 个代表性任务，记录失败点
第 2 周	创建 P0 Skill	用 Skill Creator 创建 integration-adapter-dev 和 spec-reverse-extract
第 3~4 周	A/B 迭代	Claude A/B 双代理模式打磨，目标通过率 > 80%
第 5~6 周	创建 P1 Skill	创建 legacy-migration 和 compliance-check
第 7~8 周	稳定运行	实际项目中使用，收集数据，持续优化

---

十、社区资源速查

本文方法论涉及的三大社区开源资源：

资源	GitHub 仓库	Star 数	简介
Anthropic Skills	anthropics/skills	官方维护	Claude 官方 Skill 示例集合，包含 skill-creator（Skill 创建助手）及 docx/pdf/pptx/xlsx 等文档 Skill。含完整的 Agent Skills 规范（agentskills.io）。
agent-skills	addyosmani/agent-skills	45k+	Google 资深工程师 Addy Osmani 维护的生产级工程 Skill 集合。覆盖 Define → Plan → Build → Verify → Review → Ship 完整生命周期，共 24 个 Skill + 4 个专家代理角色。支持 Claude Code、Cursor、Gemini CLI、OpenCode 等多平台。
Superpowers	obra/superpowers	活跃维护	面向 AI 编码代理的完整软件开发方法论，基于可组合 Skill 集 + 子代理驱动开发流水线。支持 Claude Code、Codex、Cursor、Gemini CLI、Kimi 等 11 个平台。核心流程：头脑风暴 → Git Worktree 隔离 → 任务拆分 → 子代理执行 → TDD → 代码审查 → 分支收尾。

安装与使用

Anthropic Skills（Claude Code）：

# 注册官方插件市场
/plugin marketplace add anthropics/skills

# 安装文档 Skill 集
/plugin install document-skills@anthropic-agent-skills

# 安装示例 Skill 集
/plugin install example-skills@anthropic-agent-skills

agent-skills（Claude Code）：

git clone https://github.com/addyosmani/agent-skills.git
# 将 skills/ 目录复制到项目的 .claude/skills/ 下即可使用

Superpowers（Claude Code）：

git clone https://github.com/obra/superpowers.git
# 按照仓库 README 中的安装指引配置插件

---

本文方法论来源：Anthropic Skills 评估驱动开发模式、addyosmani/agent-skills 解剖结构、obra/superpowers 通用 Skill 体系。