20 个 agent-skills 技能实用指南：从模糊需求到顺利上线，什么时候用哪个

20 个 agent-skills 技能实用指南：从模糊需求到顺利上线，什么时候用哪个

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills

agent-skills 是一套面向 AI 编码代理的 AI 编码代理技能集，它把资深工程师日常依赖的工作流和质量关卡，打包成 20 个可直接调用的技能，覆盖从需求到部署的全流程。本文不按开发阶段逐个罗列，而是按你日常会遇到的痛点场景来组织——需求说不清时、代码写到一半变乱时、上线前最后要查什么——帮你看懂每个技能在什么时候该出场，以及怎么把它们串起来。装好之后，多数技能可以直接用/spec、/build、/review、/ship这类斜杠命令触发，也可以打开 skills/ 目录手动调用某一个。

📖 先做这一步：让代理知道"技能怎么用"

using-agent-skills：先找到该用哪个技能

20 个技能摆在面前，代理未必每次都挑得对。这个元技能负责把当前的活儿匹配到对应的工作流上，并规定所有技能共用的执行规则，避免用错流程或跳步。会话开始时让它先跑一遍，比中途发现走错了路再回退划算得多，内容在 skills/using-agent-skills/SKILL.md 里。

🧩 接到一个说不清的需求时

interview-me：把一句话需求问成清楚的事

需求方常只丢来一句"帮我做个 X"，没人告诉你"给谁用、为什么现在做"。这个技能让代理一次只问一个问题，追问到你真实想要的东西有大约 95% 的把握为止，而不是默默替你脑补需求、做出一个方向就错的功能。你只需回一句"interview me"，它就开问。

idea-refine：先发散再收敛，顺便压一压方案

方向是对的，但想法还模糊，这时候急着动手最容易返工。它先帮你把可能性摊开多想几个，再收敛到一个，并且会主动挑战方案里的假设，把漏洞暴露在写代码之前。用"帮我压力测试一下这个方案"这类话触发它，效果最好。

spec-driven-development：规格先于代码

边写边想规格，是返工最常见的来源。这个技能要求先写清楚规格再碰代码；如果一条需求里其实藏着好几个能独立测试的能力，它会先拆成模块地图，再逐条写规格，防止"一个需求"悄悄膨胀成一锅粥。搭配/spec命令使用最顺。

planning-and-task-breakdown：把大任务拆成能动手的清单

规格写完了，任务还是大到不知从哪下手？它会按依赖关系把工作拆成有序的小任务，每块都小到可以独立交付，让你能判断先做什么、哪些能并行、大概要花多久。对应/plan命令，拆完的清单可以直接交给后面的开发技能执行。

🧱 写代码的时候：一次推进一步，接口别乱

incremental-implementation：一次写一片，每片都能跑

一口气生成一大堆代码，一旦中途出错很难定位也难回滚。它的规矩是"一次一片"：每次变更只碰少量文件、能跑通、先提交，这样不管功能多长，你随时都能退到上一个稳定点。任务只要涉及多个文件，就让代理按 skills/incremental-implementation/SKILL.md 里的切片规则走。

api-and-interface-design：接口一次设计对，少返工

接口定得含糊，之后每加一个功能都要返工一遍。它约束你设计 REST/GraphQL 端点、模块间类型契约、前后端边界的方式：稳定、显式、给变化留余地。设计接口时它会自动被触发，动手前也可以打开 skills/api-and-interface-design/SKILL.md 对照着过一遍。

frontend-ui-engineering：把界面做到生产级

代理生成的页面常有一种"AI 味"，通常就缺这一课。它覆盖组件结构、状态管理、响应式布局和 WCAG 无障碍标准，目标是页面能在生产环境用，而不只是看起来对。建页面、改组件时它会自动触发，不需要你手动点名。

test-driven-development：测试是证据，不是装饰

代理说"应该没问题"的时候，你凭什么信？它强制红绿重构节奏：先写测试、看它失败、再写刚好够通过的代码、最后简化。测试先于代码存在，代理就没法靠"解释"蒙混过关，回归也能在发生的那一刻被抓住。

🔍 出了岔子的时候：先找根因，别乱试

debugging-and-error-recovery：从"坏了"到"找到根因"

测试挂了、行为不对，第一反应不该是改代码碰运气。它要求先收集证据、缩小范围，再定位真正的根因，修完还要验证并防止复发，同一个坑就不会踩第二遍。任何" unexpected 的错误"都值得先套这套流程。

browser-testing-with-devtools：看真实页面，别信"理论上没问题"

前端问题的真相在浏览器里，不在想象里。它让代理通过 Chrome DevTools 直接检查真实页面：DOM 结构、控制台报错、网络请求、性能数据都基于实际运行状态说话。需要配置 chrome-devtools MCP 才能用，具体步骤见 skills/browser-testing-with-devtools/SKILL.md。

✅ 合并之前：代码要过的四道关

code-review-and-quality：合并前的五轴审查

代码是代理写的，更需要人来审——尤其当它看起来"很像对"的时候。它从五个轴审查变更，让缺陷、安全、性能、可读性、测试覆盖这些维度都不漏。跑/review之前把这条流程走完，是合并前最省心的最后一步检查。

code-simplification：能跑的代码，再简化一遍

"能跑"不等于"好维护"，复杂代码往往在不知不觉中积累的。它在行为完全不变的前提下简化代码：去掉多余分支、拆掉过长函数、把命名改清楚。你发现某个文件越写越厚的时候，就是/code-simplify该上场的时候。

git-workflow-and-versioning：给仓库留下能读的史

提交得随性，出问题时追溯全靠翻聊天记录。它规范分支策略、提交粒度、冲突处理和发版时的版本号与 changelog 写法，让仓库历史任何时候都读得下去。你每做一次代码变更，它其实都在背后生效。

security-and-hardening：上线前把输入和会话查一遍

凡是接收用户输入、管理登录态、调用第三方服务的功能，都是漏洞最爱出没的地方。它逐条检查输入校验、会话管理、隐私合规（GDPR/CCPA）这些项，把问题挡在上线之前，而不是等漏洞被曝出来再补。处理不可信数据之前，值得先翻一遍它的清单。

🚀 上线之前：最后要查的事

performance-optimization：先看数据，再动手优化

没有测量的"优化"，很可能越优化越慢。它坚持先取数定位真正的瓶颈——Core Web Vitals、N+1 查询、数据库慢点都在范围内——再针对性下手。对应/webperf命令，适合在上线前给整个应用做一次体检。

ci-cd-and-automation：把重复的活交给流水线

每次部署都靠手动操作，人越多越容易出事故。它帮你搭好流水线：CI 里跑测试和质量关卡，部署策略、环境隔离各就各位，重复环节全部自动化。第一次搭 GitHub Actions 时照着 skills/ci-cd-and-automation/SKILL.md 的步骤走，不容易漏配置。

shipping-and-launch：分阶段发布，留好退路

上线不是点一下部署按钮就结束的事。它给你一份上线前检查清单、一套分阶段发布计划，还有一条明确的回滚路径——出问题时能体面地退回去，而不是硬扛。发布前跑一次/ship，整套检查就不用你自己记了。

🌱 上线之后：让项目活得久一点

documentation-and-adrs：把"为什么"写下来

代码能看懂，但当初为什么这么决策，没人说得清——这是长期维护最大的坑。它让你用 ADR（架构决策记录）的方式记关键决定：选了什么、为什么、放弃了什么。新同事和代理下次接手时，上手时间会短很多。

deprecation-and-migration：下掉旧功能，别吓跑用户

要废弃一个功能，最难的是做得不吓人。它走完整流程：提前公告、新旧实现并行、引导用户迁移、最后再清理，每一步都有明确顺序，升级过程有序且可回退。决定砍掉某块旧代码之前，先按它的流程估一遍影响面。

想自己动手试试的话，最快的路径是把整个仓库克隆下来，装进你正在用的编码代理，之后每次开发就都有一位"有经验的同事"在旁边把关：

git clone https://gitcode.com/GitHub_Trending/agentskill/agent-skills

克隆后按 docs/getting-started.md 的步骤完成安装，不同工具（Claude Code、Cursor、Gemini CLI 等）在 docs/ 下都有各自的配置指南。

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills