dev-skill：一个可公开分享的 DIY Agent Skills 工具箱

项目地址：GitHub · dev-skills · Gitee · dev-skill

我做这个项目的出发点很朴素：把自己在需求分析、开发、审查和测试里反复使用的方法，整理成能被 AI 工具识别、安装和组合调用的 Skill。

dev-skill 是一个个人维护、可以公开分享的轻量仓库。它不是提示词大杂烩，也不试图包装成万能的“AI 操作系统”；更像一个 DIY Agent Skills 工具箱：每个 Skill 有明确职责，既可以单独使用，也可以沿着一条研发工作流协作。

仓库源码、安装说明和每个 Skill 的具体约束，都以 GitHub 仓库 为准；也可通过 Gitee 镜像 访问。

一、它想解决什么问题

很多 AI Coding 的经验最初都很零散：

  • 某个好用的提示词只留在聊天记录里；
  • 同一套规则要在不同客户端重复配置；
  • 需求、实现、审查之间缺少连续上下文；
  • 工作流跑顺后，下一次又得从头解释一遍。

dev-skill 想做的，是把这些一次性的经验变成可复用、可安装、可迭代的能力单元。你可以把它理解为：

把“我平时怎么让 AI 帮我做研发”沉淀成一套能继续演进的项目资产。

它更适合希望把个人工作流整理清楚的开发者；仓库刻意不包含组织专用集成、私有凭据或生产数据，文档示例也使用中性命名，方便阅读和分享。

二、一张图看懂项目结构

dev-skill 目前不是一个庞大的平台，而是一套围绕研发过程组织起来的 12 个 Skill。它们大致分成四层：先把需求想清楚，再把工程上下文找全，然后进入实现，最后用审查和测试把风险收住。

这张图可以先当成项目地图：Development 负责把“我要做什么”变成“我知道怎么做”；Review 负责把“做完了”变成“风险可解释”；Visualization 和 Platform 则是横向能力，一个负责表达复杂关系，一个负责让工具链可维护。

三、12 个 Skill 分别做什么

为了让读者不用跳到仓库里翻目录，下面按真实仓库中的 Skill 逐个说明。

分类 Skill 适合什么时候用 主要产物
Development brainstorming 需求还不够清楚，或者有多个方案需要取舍 经确认的目标、边界和设计方向
Development app-scanner 工作区里有多个前后端应用，需要先摸清业务能力和依赖关系 应用能力清单、API / 数据模型 / 外部依赖概览
Development sdd-dev-workflow 已有原始需求、PRD 或想法，需要整理成可开发任务 requirements.md、design.md、plan.md、tasks.md
Development ai-pair-programmer 已经明确要写代码、改 bug、重构或补测试 符合项目风格的代码改动和验证结果
Review author-final-review 想审查某个作者在一个范围内的最终代码状态 面向 Bug 和风险的最终态审查结果
Review code-review 需要系统检查代码质量、安全、性能、架构和兼容性 结构化代码审查报告
Review integration-test Java Dubbo 变更需要补集成测试设计 P0 / P1 测试用例、入参、预期输出和覆盖追溯
Review full-review 希望一次性拿到审查、影响面和测试设计的完整报告 完整审查报告与风险覆盖结果
Review team-cr 多人、多模块改动要开集体 CR 按风险等级和模块分组的会议讨论清单
Visualization diagram-creation 文字讲不清流程、架构、时序或学习路线 Mermaid、PlantUML 等图表源码
Platform git-worktree 多分支并行开发，或者需要隔离工作目录 标准化 worktree 目录和迁移建议
Platform skill-usage-tracker 执行技能前记录使用，或查看本地统计 写入 ~/usage_stats.json 的技能使用数据

每个 Skill 都放在 skills/<分类>/<skill 名>/ 下，以 SKILL.md 说明触发条件、输入输出和执行边界；需要时还会携带脚本、参考资料或模板。这样的结构让“能力说明”和“实际工具”留在同一个可追溯的位置。

四、开发中哪些环节可以用到这些 Skill

光看 Skill 名字还不够直观，我们换成一个真实开发例子：给订单系统增加“优惠券抵扣”能力。

这类需求通常不会直接进入编码。它会经历需求澄清、影响面扫描、方案拆解、代码实现、测试设计、代码审查和团队评审几个阶段。dev-skill 的价值，就是把这些阶段拆开，每一步用合适的 Skill 接住。

这张图背后的使用方式可以再翻译成大白话：

开发环节 可以用的 Skill 它帮你解决什么
需求刚来 brainstorming 不急着写代码，先问清规则、边界、验收标准
需求涉及多个应用 app-scanner 找出订单、营销、支付等应用分别负责什么
准备进入开发 sdd-dev-workflow 把需求、代码证据、技术方案和任务拆分整理出来
多分支并行 git-worktree 给当前需求隔离一个干净工作区
正式编码 ai-pair-programmer 在明确授权后改代码、补测试、跑验证
自查或交付前 author-final-review、code-review 找出最终态代码里的 Bug、兼容性和架构风险
测试设计 integration-test 根据风险点生成优先级测试用例
汇总交付 full-review 把审查、影响面、测试覆盖整理成完整报告
讲给别人听 diagram-creation、team-cr 画流程图，准备集体 CR 的重点讨论项

这里有一个我很看重的边界：实现不是自动越权发生的。 前面的 Skill 负责弄清需求、建立事实和产出方案；只有用户明确授权后，才进入代码修改与验证。

对开发者来说，这比“让 AI 一次性写完”更可控：每一步都有对应的上下文、检查点和产物。

五、如何安装并开始体验

项目通过 profile 管理默认安装清单。macOS / Linux 用户在仓库根目录依次执行：

make audit-skills
make install-dry-run
make install
  • make audit-skills：检查 Skill 数量、重名和职责重叠；
  • make install-dry-run：预览同步计划，不修改任何文件；
  • make install：正式同步 config/profiles/diy.skills 中定义的 Skill。

Windows PowerShell 5.1+ 可执行：

powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 preview
powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 install

安装器会检查每个 Skill 的 SKILL.md、补齐其 depends_on 依赖，并只处理当前机器上实际检测到的 Cursor、Claude Code 与 Codex 客户端。未安装的客户端会被安全跳过。

六、为什么更新能保持一致

仓库只维护一份 Skill 源码，客户端通过链接引用它：

  • macOS / Linux 使用软链接；
  • Windows 使用 Junction；
  • 修改仓库内的 Skill 后，已链接的客户端可以直接读到新版本。

这避免了把同一份内容复制到多个工具目录后逐渐失控的问题。安装时若遇到同名冲突，也可以选择跳过、重命名或确认后覆盖；卸载只会移除该仓库创建的链接，不会删除 Skill 源码。

七、给想深入的人：它如何治理自己

一个 Skill 仓库能否长期维护，不只取决于写了多少能力，还取决于有没有把质量和边界放进流程。

  • scripts/audit-skills 用于审计数量、重名与功能重叠；
  • skill-usage-tracker 将本地使用统计写入 ~/usage_stats.json，可配合看板查看；
  • 任何 Skill 执行前都要先记录使用，避免统计只靠人工回忆；
  • 强制覆盖和删除源码属于高风险操作，推荐先使用 dry-run 核对影响范围。

我目前采用的安全同步顺序很简单：

审计 → dry-run → 处理冲突 → 安装 → 检查链接

这套流程不复杂，但能让工具箱在持续增加 Skill 时，仍保持来源清晰、更新可控、问题可回退。

八、从哪里开始

如果你第一次打开这个项目，建议这样浏览：

  1. 先读 README，了解项目定位和安装方式；
  2. 再看 skills/README.md，了解不同 Skill 的职责；
  3. 选一个真实场景，再阅读对应 Skill 的 SKILL.md。

这篇文章讲的是项目本身；如果你想先理解 Skill 为什么不只是“提示词补丁”，可以继续读：

也欢迎直接从 dev-skills GitHub 仓库 开始，按自己的工作流挑一个 Skill 试用。