【AI实践】如何构建AI Coding Skill：从零到一的六步方法论

基于 Anthropic Skills含 skill-creator addyosmani/agent-skills obra/superpowers 三大开源框架针对自主研发、前后端分离、集成总线架构的历史项目提炼出一套可复用的 Skill 创建方法论。前言为什么项目尤其旧有系统需要 SkillAI Coding 工具在从零搭建新项目上表现惊艳但面对运行了五年以上的就有系统时往往会踩进同一个坑架构约束不了解、历史决策不清楚、隐式规则不掌握。结果就是——AI 改了代码却破坏了系统稳定性。Skill技能文件正是解决这个问题的钥匙。它不是写一份说明文档而是将团队积累的项目知识编码为 AI 可执行的约束化工作流。本文基于一套在大型遗留系统上验证过的 Skill 创建体系提炼出通用的方法论和最佳实践。一、整体策略并行推进先精后广在陈旧项目上构建 Skill 体系建议采用双轨并行策略通用 Skill社区模板直接使用 ├── test-driven-development ← 测试驱动开发 ├── code-review-and-quality ← 代码审查与质量 ├── incremental-implementation ← 增量实现 ├── context-engineering ← 上下文工程 └── debugging-and-error-recovery ← 调试与错误恢复 │ 并行推进 │ 项目专属 SkillSkill 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%架构约束违反次数记录实际值0Token 消耗记录实际值减少 30%人工纠正轮次记录实际值减少 50%没有基线就没有优化方向——这是评估驱动开发的核心思想。Step 4用 Skill Creator 生成 SKILL.md 草稿在 Claude Code 中启动 Skill CreatorGitHub 仓库/skill skill-creator告诉它项目的关键信息我要创建一个名为 integration-adapter-dev 的 Skill用于在适配层开发。 这个项目的特殊约束是 1. 所有中间件交互必须通过适配层 2. 数据格式遵循 rules/接口规范.md 3. 每个请求必须携带追踪 ID 4. 敏感字段加密 5. 变更后必须运行接口验证和影响面分析Skill Creator 会自动完成意图澄清 → 编写 SKILL.md → 创建测试用例 → 运行评估。Step 5Claude 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 刚刚写好的 SkillB 不需要启动 Skill Creator# 直接在当前会话中执行真实项目任务请帮我在适配层新增一个客户等级查询接口。 需求传入 customerId返回 level 和 levelName。B 执行任务。在这个过程中重点观察四个维度#检查点观察方式1B 是否遵循了架构约束B 有没有绕过适配层直接调中间件2B 是否读取了正确的 Spec 和 RulesB 的引用路径是否正确读取顺序是否符合 Process3B 是否在修改后运行了验证B 改完代码后有没有运行 contract-verify4B 在哪些步骤反复卡住或出错B 在哪里问了问题哪个步骤跳过了反馈循环B 执行完后把失败点和问题整理成反馈回到终端 AB 在执行时出现了以下问题 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 1A 写了第一版 SKILL.mdB 接到任务“把订单查询模块从 AngularJS 迁移到 Vue”B 直接改了代码没加回归测试没创建特性开关反馈Skill 的 Process 中 Step 3写回归测试和 Step 4创建特性开关约束不够强Round 2A 在 Process 中给 Step 3 和 Step 4 加了MUST标记B 再次执行这次写了回归测试但仍然没创建特性开关反馈Rationalizations 表缺少这个改动太小不需要特性开关的借口反驳Round 3A 在 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-devdescription: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 dont 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 1integration-adapter-devP0 —— 最先创建--- 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. | | Ill 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 requestsSkill 2spec-reverse-extractP0 —— 从代码反向提取规格--- 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 traceSkill 3legacy-migrationP1 —— 安全迁移--- name: legacy-migration description: Safely migrate legacy code modules following Chestertons 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 hasnt 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 ## Chestertons 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, Ill fix it while migrating | Migration and refactoring are separate concerns. Fix behavior in a separate change. | | I dont 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-mscripts.aggregate_benchmarkworkspace/iteration-1 --skill-name integration-adapter-dev# 2. 查看评估报告python eval-viewer/generate_review.pyworkspace/iteration-1 --skill-name integration-adapter-dev# 3. 描述优化提升触发准确率python-mscripts.run_loop --eval-set trigger-eval.json\--skill-path skills/integration-adapter-dev --max-iterations5七、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 1P0 │ │ ├── SKILL.md │ │ ├── references/ │ │ ├── scripts/ │ │ └── evals/ │ ├── spec-reverse-extract/ ← 项目专属 Skill 2P0 │ ├── legacy-migration/ ← 项目专属 Skill 3P1 │ ├── compliance-check/ ← 项目专属 Skill 4P1 │ ├── third-party-adapter-dev/ ← 项目专属 Skill 5P2 │ ├── [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% 才能投入使用。核心要点回顾双轨并行通用 Skill社区模板 项目专属 Skill自建同时推进六步评估驱动识别差距 → 创建评估 → 建立基线 → 生成草稿 → A/B 迭代 → 渐进扩展四原则流程非散文、反合理化、验证不可协商、渐进式披露反合理化表陈旧项目 Skill 的灵魂——预判开发者会找的借口并文档化反驳先精后广先做好 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 Skillsanthropics/skills官方维护Claude 官方 Skill 示例集合包含 skill-creatorSkill 创建助手及 docx/pdf/pptx/xlsx 等文档 Skill。含完整的 Agent Skills 规范agentskills.io。agent-skillsaddyosmani/agent-skills45kGoogle 资深工程师 Addy Osmani 维护的生产级工程 Skill 集合。覆盖 Define → Plan → Build → Verify → Review → Ship 完整生命周期共 24 个 Skill 4 个专家代理角色。支持 Claude Code、Cursor、Gemini CLI、OpenCode 等多平台。Superpowersobra/superpowers活跃维护面向 AI 编码代理的完整软件开发方法论基于可组合 Skill 集 子代理驱动开发流水线。支持 Claude Code、Codex、Cursor、Gemini CLI、Kimi 等 11 个平台。核心流程头脑风暴 → Git Worktree 隔离 → 任务拆分 → 子代理执行 → TDD → 代码审查 → 分支收尾。安装与使用Anthropic SkillsClaude Code# 注册官方插件市场/plugin marketplaceaddanthropics/skills# 安装文档 Skill 集/plugininstalldocument-skillsanthropic-agent-skills# 安装示例 Skill 集/plugininstallexample-skillsanthropic-agent-skillsagent-skillsClaude Codegitclone https://github.com/addyosmani/agent-skills.git# 将 skills/ 目录复制到项目的 .claude/skills/ 下即可使用SuperpowersClaude Codegitclone https://github.com/obra/superpowers.git# 按照仓库 README 中的安装指引配置插件本文方法论来源Anthropic Skills 评估驱动开发模式、addyosmani/agent-skills 解剖结构、obra/superpowers 通用 Skill 体系。