AGENT SKILLS · 研发能力清单

Agent Skills

技能（Skill）是写给 Agent 的作业指导书：把架构规范、SQL 审查口径、安全审计清单、 依赖风险判断这些「老工程师的直觉」固化下来，让 Agent 每次都用同一套标准干活。 本页按研发阶段与任务维度整理 9 个阶段、54 个任务维度、54 个推荐技能，覆盖设计、编码、测试、评审、 数据、交付、安全、增长与智能体协作全链路，含核心功能、仓库地址， 以及在 DeepSeek Harness 中的实际用法与管理机制。

54任务维度 54推荐技能 9研发阶段 ★方法论合集 superpowers
按需挑选下载 先看概念
⬇ / DOWNLOAD

把技能装进本地

技能目录下的 SKILL.md 与配套脚本、模板、检查清单会原样打进一份 zip； 包内附 README.md 出处对照表与 _DOWNLOAD-REPORT.txt 结果清单

技能源正在预热… 页面打开时已开始按仓库抓取，预热完成后点下载即为秒下
  • 一个技能一个目录：包内结构与仓库一致，SKILL.md 在目录根，脚本原样保留
  • 点完不用干等：页面一打开就在后台预热，预热完成后按钮会亮起「可秒下」；下载时显示毫秒精度耗时，含「包多大 / 多少文件 / 成功几个技能」
  • 取不到会说明：个别技能若源站不可达或超体积上限，包内 _DOWNLOAD-REPORT.txt 会列出名单，其余照常打包
  • 版权归原作者：聚合只为省事，使用前请阅读各仓库 LICENSE 与技能目录下的 SKILL.md
00 / WHAT IS A SKILL

技能为什么值得沉淀

先看清它到底解决了什么问题，再谈选型

技能是一个目录

通常含一份 SKILL.md：YAML frontmatter 声明元信息，正文写触发条件与操作步骤，可附带脚本、模板与检查清单。本质是可版本化、可复用的提示词工程。

按需加载，不占满上下文

好的 Harness 只在任务相关时才把技能正文注入上下文——先看元信息，命中才读全文。这也是「能装很多技能」却撑不爆窗口的原因。

它解决的是「一致性」

模型本身够聪明，但风格随机。技能把团队规范钉死，让同一个任务换人跑、换天跑，产出都八九不离十。

可组合，也可自建

一个技能只干一件事，多个技能拼起来就是一套工作流。市面上的合集都能拆着用，也能照着写自己团队的。

能见度是两个开关

技能可以「只给模型用」「只给人用」或「只给受信代码用」。它决定了哪些规范会被 Agent 自动执行，哪些必须你亲口喊。

选技能只看一件事：这个任务你平时会不会反复交代同一段话。

会，就值得做成技能。比如「注释只解释为什么，不解释代码在做什么」「索引要按最左前缀设计」——这些话说一百遍，不如写一次。

01 / METHODOLOGY

方法论合集：superpowers

专治「需求没说清就动手」——一套把资深工程师工作节奏塞进 Agent 的技能合集

🧠 头脑风暴 · 流程方法论

superpowers

一整套「资深工程师怎么把活干好」的方法论，做成可组合技能

它不是单个技能，也不是一本技术手册，而是一套工作流程方法论：核心是让 Agent 先做 头脑风暴（brainstorming）——苏格拉底式追问你真正想解决什么、探索备选方案、分块确认设计， 再进入计划、实现、TDD、调试、评审的完整链路。它最大的价值不在某个具体技巧， 而在于把工作节奏带进了 Agent——让它像个有经验的同事，而不是一台急着交差的代码机。

  • 先思考再动手：看到「要建东西」不会直接写码，而是先追问你真正想解决什么，把需求逼成一份可读的规格，并分块给你确认
  • 计划写到「新手能执行」：实施计划细到让一个没有项目上下文、不爱测试的新人都能照做，并强调真实红绿 TDD、YAGNI 与 DRY
  • 子智能体驱动开发：按计划逐个派子 Agent 执行，每个任务后做两阶段评审（先查规格符合度，再查代码质量），常能数小时不跑偏
  • 强制而非建议：它要求 Agent 在任何任务之前先检查是否有相关技能，是 mandatory workflow，不是提示
  • 跨 Harness 可用：Claude Code、Codex、Cursor、Gemini CLI、Copilot CLI、OpenCode、Antigravity、Devin、Factory Droid、Grok、Kimi 等都有对应安装方式
继续看具体技能 在 Harness 中安装

技能库里有什么：14 个技能，四类分工

它不是「一个大技能」，而是 14 个各管一段的小技能，按四类分工；每一个都是「流程」而不是「知识」，装进来就能改变 Agent 的做事顺序。

流程方法 · 定节奏

决定「先做什么、后做什么」

4
  • brainstorming 头脑风暴核心技能：用苏格拉底式提问逼出真实需求，先探索 2~3 个备选方案，再分块把设计讲给你确认。它就是「别急着写代码」的那道闸。
  • writing-plans 把设计拆成 2~5 分钟一个的小任务，每个任务写清精确文件路径、验收标准与验证命令，产出「新手照着也能做」的实施计划。
  • executing-plans 按计划分批执行，每批结束设检查点停下来汇报；偏航立刻回退，而不是一口气跑完再让你收拾。
  • subagent-driven-development 把计划里的任务逐个派给子 Agent 执行，主 Agent 只做编排与验收；每个任务后做两阶段评审（先规格符合度，再代码质量），长任务不容易跑偏。

实现与验证 · 保质量

决定「怎么算真的做对了」

4
  • test-driven-development 强制 RED-GREEN-REFACTOR：先写会失败的测试、亲眼看它失败、写最小实现、看它变绿、再重构。它会拒绝在测试之前写的实现，并附测试反模式清单（断言过弱、逻辑写进测试、mock 满天飞）。
  • systematic-debugging 四阶段根因法：定位现象 → 提假设 → 验证假设 → 才改代码；配套根因溯源、纵深防御、条件等待等具体手法，禁止「改到不报错为止」。
  • verification-before-completion 在宣称「修好了」之前强制跑验证：复现原始问题、跑通测试、附上证据，杜绝口头完工。这是它敢让你合并的底气。
  • using-git-worktrees 动工前先建独立 worktree 并验证测试基线是干净的，让并行任务互不污染，也让「改坏了」的代价可控。

协作与收尾 · 能合并

决定「改动怎么进主干」

3
  • requesting-code-review 提交前自查清单：安全、边界、可读性、测试覆盖逐项过一遍，按严重程度报告，严重问题阻塞推进——把「我觉得差不多」换成「逐项检查过」。
  • receiving-code-review 收到评审意见后的响应流程：先复述问题确认理解、再判断是否成立、最后带着验证证据回复，避免 review 变成互相消耗。
  • finishing-a-development-branch 收尾时验证测试与工作区状态，明确给出「合并 / 发 PR / 保留 / 丢弃」四个选项及各自后果，而不是默默把分支留着。

元技能 · 能扩展

决定「技能本身怎么长」

3
  • writing-skills 按最佳实践编写自己的 SKILL.md：元信息怎么写、触发条件怎么定、步骤与检查清单怎么组织，让团队的规范也能沉淀成技能。
  • dispatching-parallel-agents 把互不重叠的子任务并发派发出去：先冻结接口契约再开工，按模块边界划分工作区，按拓扑顺序合并，避免「并行之后合并成灾难」。
  • using-superpowers 合集入口技能：规定「任何任务开始前先检查有没有相关技能」，把上面这些技能串成一条强制工作流，而不是等你手动一个个喊。

它的工作流长这样

四个阶段首尾相接，把「含糊需求」推成「可合并的分支」——每一步都有产出物，前一步的产出就是后一步的输入。

1
brainstorming 头脑风暴：追问需求，探索备选方案，分块确认设计，落成设计文档
2
using-git-worktrees 建隔离工作区，验证测试基线是干净的
3
writing-plans 拆成 2–5 分钟一个的小任务，每个都带验证步骤
4
subagent-driven-development 逐任务派子 Agent，两阶段评审
5
test-driven-development 红绿重构，先写会失败的测试
6
requesting-code-review 任务之间评审，严重问题阻塞推进
7
finishing-a-development-branch 验证测试，给出合并 / PR / 保留 / 丢弃的选项
✓
可合并的 PR 需求、计划、测试、评审记录齐全，改动可直接进主干
02 / MATRIX

研发常用技能矩阵

按研发阶段分成 9 个 Tab，点一下只看看得完的那一屏；每个任务维度只推一个技能——选的是该方向最常用、被大量团队在用、且能直接从对应仓库装上的那一个

日常高频 上线前必跑 按需选装 进阶/新兴 表格可横向滚动；一个维度一个技能，星标为撰写时的联网快照

表中每个任务维度只给一个技能，就是该方向最常用、社区采用最多的那个，右侧仓库地址即该技能的出处，不是泛泛的合集主页。 表中仓库均已联网核对，根目录都带有 skills/ 文件夹，且所推荐的技能名就是该文件夹下的真实目录，可直接对上安装。 仓库均为第三方开源项目，同一技能名在不同合集里实现口径可能不同，安装前建议先扫一眼技能的 SKILL.md，确认它的判断口径和你团队一致。 星标为撰写时的联网快照，仅作热度参考；热度低不等于不好用—— 有些细分方向的技能只有几十星，但恰好解决你的问题（比如 Git 流程、单元测试这两个维度）。

54任务维度
54推荐技能
9研发阶段
22核对过的仓库
∞可自建扩展
03 / DETAILS

按任务维度详解

每个维度讲清「什么时候用、怎么组合、注意什么」

架构规范

spec-driven-development · 适合「动手前」

设计阶段

谈架构最容易翻车的地方，是讨论变成空转。这个技能的价值在于：让 Agent 先产出可检查的结构方案——分层怎么切、依赖指向哪、边界靠什么守住，而不是直接甩一段代码给你。

  • 从零设计：新模块先要一份分层与依赖说明，确认后再写实现
  • 存量重构：先让它标出「跨层调用」「循环依赖」这类结构性问题，再谈怎么拆
  • 组合建议：与 superpowers 的「先设计后实现」流程叠加，效果最明显

API 规范

api-and-interface-design · 适合「对外契约」

契约阶段

接口一旦发出去了就很难改。这个技能把「命名、方法语义、错误码、分页、版本」这些散落在多人脑子里的约定，收敛成一份可生成、可校验的 OpenAPI 文档。

  • 先文档后代码：让它先出 OpenAPI 3.1 规范，评审通过再生成实现骨架
  • 版本与兼容：新增字段、废弃字段、破坏性变更要它明确标注
  • 错误处理统一：让错误响应结构和状态码口径全站一致，前端才好写统一处理

SQL 规范与优化

optimizing-sql-queries · 适合「性能问题」

性能阶段

慢 SQL 的坑往往不在写法本身，而在索引设计与调用次数。这个技能会带着 EXPLAIN 结果讲因果：为什么走全表、为什么索引失效、N+1 是哪一层炸的。

  • 先看执行计划：让它必须先给出 EXPLAIN 判断，再提优化建议
  • 索引最左匹配：新增索引必须说明服务于哪条查询、代价是什么
  • ORM 场景：顺手检查关联查询是否触发 N+1，给出批量加载改法

代码注释

writing-clearly-and-concisely · 适合「长期维护」

日常高频

注释最怕两种：一种是把代码翻译一遍的废话，另一种是改完代码忘了改的谎言。这个技能只写永久信息：为什么这么写、坑在哪、什么条件下不能动。

  • 解释为什么：反直觉的取舍、绕开的具体缺陷、依赖的外部约束
  • 不解释是什么：方法名已经说清的事不再重复
  • 多语言适配：JavaDoc / JSDoc / docstring 形态按语言自动切换

重构与死代码

code-simplification · 适合「重构前后」

清理阶段

死代码不占运行时间，占的是理解成本。它的难点从来不是「找出来」，而是「别删错」——反射调用、配置注入、外部入口都可能让静态分析误判。

  • 先出清单再动手：按「确定可删 / 疑似 / 保留」三档分类，逐档确认
  • 依赖分析：未使用的导入与依赖一并清掉，顺手瘦身构建产物
  • 不可达路径：识别永远进不去的分支与永远为真的判断

性能检查

performance-diagnosis · 适合「上线前体检」

优化阶段

性能优化最常见的错误，是先优化了不重要的地方。这个技能会先给优先级排序，再给分阶段路线图——先解决影响面最大的那 20%，而不是一上来就抠微秒。

  • 跨层视角：前端、后端、基础设施一起看，避免只顾一头
  • 收益估算：每条建议要给出预期收益与改造成本的对比
  • 分阶段实施：拆成「立刻能做 / 迭代内做 / 排期做」三批

安全性审计

security-audit · 上线前必跑

上线前

安全问题的特点是「没出事时看不出价值」。这类技能把 OWASP 方法论固化成多阶段流程：先扫攻击面，再逐类深挖，最后出可交付的报告（SARIF / PDF）。

  • 覆盖攻击面：注入、越权、鉴权绕过、敏感信息泄漏、依赖漏洞一路扫过去
  • 可交付产物：扫描结果能进 CI 平台，报告能直接给到评审人
  • 自动修复：备选技能支持对明确问题直接给修复补丁，仍需人工确认

依赖库检查

security-scan · 上线前必跑

上线前

供应链安全已经是最现实的攻击面之一：你用不到的传递依赖，可能是别人攻进来的门。这两个技能覆盖 CVE、许可证、膨胀与未使用依赖四件事。

  • CVE 与升级路径：不只是报漏洞，还要给出可执行的升级顺序
  • 许可证合规：商用项目最怕的 GPL 类传染性许可，必须提前发现
  • 依赖膨胀：为一个小功能引入一整棵树的情况，值得清理

SEO 调整

seo-audit · 面向内容与流量

增长阶段

SEO 早已不是堆关键词。这类技能覆盖技术 SEO、结构化数据、E-E-A-T 与内容集群，适合独立开发者和内容站运营者。

  • 技术 SEO：站点地图、canonical、结构化数据、抓取预算一次过一遍
  • 内容策略：按主题集群规划内链与内容缺口，而不是零散写文章
  • 平台差异：备选技能面向 WordPress 生态，选和你站点匹配的那套

测试与验证

test-driven-development · verification-before-completion · 适合「改完要敢合」

日常高频

测试最容易被 Agent 糊弄成「写个能过的用例」。真正的 TDD 技能会卡住顺序：先写会失败的测试，再写让它变绿的实现，最后才重构——顺序错了，测试就只是摆设。配套的「完成度验证」还会在它说「修好了」时逼它拿出复现证据。

  • 红绿重构：每一步都有明确红灯/绿灯信号，防止「先写实现再补测试」的假 TDD
  • 反模式清单：断言过弱、逻辑写在测试里、mock 满天飞这类问题会被点名
  • 完工要有证据：复现原始问题、跑通测试、给出结果，杜绝口头「已修复」

系统化调试与评审

systematic-debugging · requesting/receiving-code-review · 适合「卡住」与「要合并」

日常高频

卡住时最费劲的动作是「瞎试」。系统化调试技能把它拉回四阶段：定位现象 → 提假设 → 验证假设 → 才改代码，并带着根因溯源、条件等待、纵深防御这些具体手法。评审类技能则把「提交前自查」和「收到意见后怎么改」都流程化，避免 review 变成互相消耗。

  • 先解释再动手：要求它说清「为什么失败」，说不清就不许改
  • 根因而非症状：修完要能解释触发链条，而不是把报错 try-catch 掉
  • 评审有清单：安全、边界、可读性、测试覆盖逐项过，减少主观拉扯

前端设计与「AI 味」

frontend-design · ui-craft · taste-skill · 适合「做界面」

设计阶段

Agent 生成的界面常常一眼就能认出来：同一套渐变、同一个圆角、同一份灰色文案。设计类技能的价值就在于把「审美判断」拆成可执行规则——间距体系、层级对比、状态覆盖，而不是让它自由发挥。

  • 先定设计令牌：颜色、字号、间距、圆角一次定好，后面所有组件都从令牌取值
  • 要求状态完整：空态、加载、错误、超长文案、窄屏，缺一个都算没做完
  • 拒绝通用感：明确告诉它「不要用默认渐变 + 通用插画」，并让技能把这条写进检查清单
  • 可追溯：从现有页面提取设计令牌，让新页面自动对齐既有体系

上下文工程与多智能体

context-compression · subagent-driven-development · 适合「长任务」

进阶

任务一长，Agent 就会「忘了前面说过什么」，或者被无关历史带偏。上下文工程类技能解决的正是这件事：在有限窗口里保住关键约束与已验证结论，把可丢的部分压缩掉。多智能体类技能则解决「一个大任务如何拆开并行、又不互相打架」。

  • 压缩有取舍：优先保住验收标准、已发现的失败证据与接口契约，历史讨论可以丢
  • 划分要互斥：并行子任务先按模块边界切到互不重叠的工作区，先冻结接口契约再开工
  • 合并按拓扑：底层契约先合并并通过测试，再合依赖它的模块，每批合并后跑集成测试
  • 别拆太碎：子任务数量超过收益拐点后，协调成本会反超并行收益

技能供应链安全

skill-inspector · 容易被忽略的一环

上线前

技能正文是要被读进上下文的。这意味着一个恶意技能除了「教坏模型」，还可能诱导它去读敏感文件、执行危险命令，或者把数据外发。装第三方技能，本质上和引入第三方依赖是同一类风险。

  • 先读再装：扫一遍 SKILL.md，看它会不会读工作区外的文件、要不要执行脚本
  • 查恶意模式：用专门的检测技能过一遍，识别提示注入与危险指令模式
  • 控分发来源：企业场景用自托管技能注册中心，而不是谁都能往项目里塞一个目录
  • 最小权限：技能需要的命令能力，交给沙箱与审批去兜底，别指望技能自己守规矩

交付与运维

ci-cd-and-automation · kubernetes-patterns · git-workflow · 适合「上线那一刻」

交付阶段

从本地到生产这一段最容易「本地能跑线上炸」。这类技能把流水线、发布策略、容器编排、Git 流程这些被反复踩坑的环节标准化：流水线怎么编排、发布怎么灰度、回滚怎么留退路，都能让 Agent 先给方案再动手。

  • 发布策略可选：蓝绿 / 灰度 / 金丝雀按风险挑，别每次都全量
  • K8s 排障：从探针、资源配额到调度失败，给出定位路径而非重启大法
  • Git 流程规范：提交信息、PR 描述、分支合并决策统一口径

自建技能与上下文管理

writing-skills · skill-creator · context-compression · 适合「用顺手之后」

进阶

别人的技能只解决通用问题，团队内部的口径还得自己写。自建技能类技能会教你按最佳实践写 SKILL.md：元信息怎么写、触发条件怎么定、怎么测试它是否真的有效。上下文管理则解决长任务跑着跑着「忘了前面约束」的问题。

  • 技能有结构：名称、描述、适用场景、步骤、检查清单，一样不少
  • 能测有效性：同一任务装/不装技能各跑一次，对比产出是否更稳
  • 上下文不失控：压缩策略 + 关键信息留存，长任务也能守住最初约束
04 / COMBOS

四套即用组合

不用一个一个试，照场景抄；每套都是「方法论打底 + 专项补刀」，1~5 个技能够用。下面的技能名都能在矩阵里找到对应维度

新功能开发

从「一句话需求」到「可合并的 PR」

  1. superpowers头脑风暴问清需求，出可执行的实施计划
  2. spec-driven-development定分层与依赖方向，边界先划清
  3. api-and-interface-design先出接口契约，评审通过再写实现
  4. test-driven-development红绿重构写实现，测试当验收标准
  5. verification-before-completion合并前跑证据，别口头说「做完了」

产出：设计说明 + 契约文档 + 带测试的改动

存量重构

老代码不敢动，先缩小战场再迁移

  1. superpowers先摸清现状与风险边界，别一上来就重写
  2. code-simplification小步安全迁移，未使用代码与坏味道一并清掉，每步都保持可运行
  3. optimizing-sql-queries顺手把查询与索引一起修了

产出：问题清单 + 分批迁移计划，全程可回滚

上线前体检

发布前必跑，把问题拦在用户看到之前

  1. security-audit多阶段安全审计，产出机器可读结果
  2. security-scanCVE 与许可证合规，附升级顺序
  3. performance-diagnosis按 ROI 排序的性能清单
  4. shipping-and-launch部署前配置与差异核对
  5. seo-audit对外页面再做一轮 SEO

产出：安全 / 依赖 / 性能 / 配置四份检查结论

线上故障排查

先稳住现场，再定位根因，最后留证据

  1. systematic-debugging四阶段定位根因，不许瞎试
  2. debugging-and-error-recovery跨服务链路追问题，先稳住现场再定位
  3. observability-and-instrumentation补上缺失的埋点与告警
  4. verification-before-completion修复后拿证据复验，附复盘结论

产出：时间线 + 根因 + 修复 + 防复发的监控补齐

组合不是越多越好：一次挂 1~3 个最相关的技能，命中率最高。

技能之间如果判断口径打架，模型会左右为难。上面每套都尽量按「先定标准、再动手、最后验证」的顺序排列，照着挂即可。

05 / ENGINEERING

技能工程化：不只是放个文件

知道机制，你才敢把技能放进团队工作流

一个技能文件的解剖

---frontmatter 开始
name: sql-reviewkebab-case 标识，也是调用时的名字
description: 审查 SQL 与索引设计…会注入目录，决定「何时被选中」
whenToUse: 新增/修改慢查询时额外路由提示
disable-model-invocation: true可选：不让模型自动调用
---frontmatter 结束
# SQL 审查正文：步骤、检查清单、示例
## 步骤
## 检查清单
## 示例与模板

调用策略：谁有权使用这个技能

模型可调用 disable-model-invocation: false

出现在模型可见目录里，任务相关时会被自动加载。规范、流程类技能都应该开这个。

用户可调用 user-invocable: true

出现在人类可用的命令目录里，需要你主动喊。适合有副作用的操作类技能。

两者皆否 model: false · user: false

只对受信代码可见（ctx.skills.get()），模型和用户目录里都不会出现。

本地提供方读取 frontmatter 时，省略的字段默认为 true。 这意味着一个不小心写漏的技能默认是「谁都能用」——涉及危险操作时最好显式关掉。

技能从哪来：六层根目录，rank 小的赢

100.dsh/skills项目专属，随仓库版本化
200.agents/skills跨工具共享的项目技能
300customSkillDirs团队私有技能目录
400<DSH_HOME>/skills你个人的常用技能
500<AGENTS_HOME>/skills跨工具共享的个人技能（默认 ~/.agents）
600bundledSkillDir随发行版打包，默认禁用需显式开启

项目根目录定义为「包含 .git 的最近祖先目录」，找不到才用当前 cwd。 重名时最近层直接赢，同一层内才按 rank、提供方顺序、本地顺序裁决—— 所以想让某条技能生效，把项目级版本放进 .dsh/skills 往往是最快的办法。

长会话里目录会自己更新

首个非空完整视图

会话里注入一条持久的目录消息，只含排序后的 name 与 description。

后续每个模型步骤前

对「标签之间的确切条目」算一次 digest，与上一次基线比较。

digest 变了

追加一条持久的完整目录替换；技能被删光时追加一条显式空替换。

压缩把历史目录藏掉了

下一份完整快照会重新建立当前目录，不会让模型「彻底忘记有技能可用」。

不完整的快照（提供方失败或目录正在变）会保留上一份可用视图而不是抖动， 所以技能根目录被临时挂掉时，正在跑的会话不会突然失去全部技能。

版本与权限：企业落地绕不开的两件事

技能也要版本化

  • 语义化版本：破坏性变更升 major，新增兼容特性升 minor，修复升 patch
  • 依赖与兼容范围要声明：依赖升级不能悄悄破坏本技能
  • 发布走 CI：描述与实现一致性校验 + 示例回归测试
  • 支持多版本并存与灰度切换，废弃要有提示期

技能也要权限边界

  • 显式声明「能做/不能做」，调用前按授权校验，不能越权
  • 敏感技能（写操作、外发、涉及结算的操作）必须走人工审批
  • 输入输出脱敏与最小化，只拿任务需要的字段
  • 调用留痕（谁、何时、参数、结果），第三方技能放沙箱执行
一句话总结：技能是「可复用、可治理、可审计」的能力资产。

版本管理保证它可演进，权限边界保证它不失控——两条腿缺一条，技能就只能停在「个人收藏」的层面，进不了团队工作流。

06 / HOW TO USE

在这些技能怎么用起来

技能本身只是文档，得有 Harness 这类工具把它接进工作流

技能包可以手动复制到项目里，但真正省事的做法是用一个 Agent Harness （比如深度求索开源的 dsh）：它负责发现技能、按任务相关性挑选、控制注入的上下文预算， 并在改完代码后跑测试、给你 diff。也就是说——技能定义「按什么标准干」，Harness 负责「真的去干」。 本页所有技能都可以通过下面的方式挂到 DeepSeek Harness 上使用。

STEP 1

安装技能

harness skill add superpowers

支持内置市场短名，也支持直接给 Git 仓库地址；项目级技能放进 .harness/skills/ 后随仓库一起版本化。

STEP 2

按任务挂载

harness run --skill 名称 "任务描述"

一次挂 1~3 个最相关的即可。挂太多会互相干扰，模型反而抓不住重点。

STEP 3

验证再合并

harness diff && harness review

技能不替代验证。改动必看 diff，能跑测试就跑测试——这也是「回滚成本低」的前提。

完整的安装、配置与进阶技巧，见《Agent Harness 上手》

包含 CLI 安装、模型密钥配置、任务四要素写法、九条使用技巧与常见坑排查，建议与本页对照阅读。

前往 Agent Harness 上手
两件必须先做的事

一，第三方技能会读进上下文，安装前先看它写了什么，别把内网地址和密钥写进技能文件；二，任何自动修复都要过一遍人工 review，技能能提高下限，但不能替你负责。

技能的终点，是你自己的技能库

先用别人的技能把流程跑顺，再把团队反复交代的那些规范写成自己的一份——那一刻起，Agent 才算真的接进了你的工作流。

查看 Harness 上手 回到技能矩阵