用Google工程实践构建生产级软件
agent-skills
24个生产级工程Skill,Google工程文化打包

试试这样做
详细介绍
Agent Skills
面向AI编码代理的生产级工程技能。
这些技能封装了高级工程师在构建软件时使用的工作流、质量门和最佳实践。它们被打包成AI代理可以在开发的每个阶段一致遵循的格式。

斜杠命令
8个映射到开发生命周期的斜杠命令。每个命令会自动激活正确的技能。
| 你正在做什么 | 命令 | 关键原则 |
|---|---|---|
| 定义要构建什么 | /spec |
先写规范,后写代码 |
| 规划如何构建 | /plan |
小粒度原子任务 |
| 增量构建 | /build |
一次一个切片 |
| 证明它工作 | /test |
测试就是证据 |
| 合并前审查 | /review |
改善代码健康 |
| 审计Web性能 | /webperf |
先测量,再优化 |
| 简化代码 | /code-simplify |
清晰胜过巧妙 |
| 发布到生产 | /ship |
更快就是更安全 |
如果你希望规范存在后减少手动步骤?/build auto 会生成计划并一次性批准执行所有任务——你批准一次计划,然后它自动运行。它消除了任务之间的人工干预,但不消除验证:每个任务仍然是测试驱动并单独提交的,遇到失败或风险步骤时会暂停。
技能也会根据你正在做的事情自动激活——设计API时触发api-and-interface-design,构建UI时触发frontend-ui-engineering,以此类推。
全部24个技能
上述命令是入口点。该包共包含24个技能——23个生命周期技能加上using-agent-skills元技能。每个技能都是一个结构化工作流,包含步骤、验证门和反合理化表。你也可以直接引用任何技能。
元技能 - 发现适用的技能
| 技能 | 作用 | 使用时机 |
|---|---|---|
| using-agent-skills | 将传入的工作映射到正确的技能工作流,并定义共享操作规则 | 开始会话或决定使用哪个技能 |
定义 - 明确要构建什么
| 技能 | 作用 | 使用时机 |
|---|---|---|
| interview-me | 逐次提问的访谈,提取用户真正想要的东西,而不是他们认为自己应该想要的,直到约95%置信度 | 需求不明确,或用户调用“interview me”/“grill me” |
| idea-refine | 结构化发散/收敛思维,将模糊想法转化为具体提案 | 你有一个粗略概念需要探索 |
| spec-driven-development | 在编写任何代码前,编写涵盖目标、命令、结构、代码风格、测试和边界的PRD | 开始新项目、功能或重大变更 |
计划 - 分解任务
| 技能 | 作用 | 使用时机 |
|---|---|---|
| planning-and-task-breakdown | 将规范分解为小的、可验证的任务,带有验收标准和依赖排序 | 你有规范,需要可执行的单元 |
构建 - 编写代码
| 技能 | 作用 | 使用时机 |
|---|---|---|
| incremental-implementation | 薄垂直切片——实现、测试、验证、提交。特性开关、安全默认值、易于回滚的变更 | 任何涉及多个文件的变更 |
| test-driven-development | 红-绿-重构,测试金字塔(80/15/5),测试规模,DAMP优于DRY,Beyonce规则,浏览器测试 | 实现逻辑、修复缺陷或改变行为 |
| context-engineering | 在正确的时间向代理提供正确的信息——规则文件、上下文打包、MCP集成 | 开始会话、切换任务或输出质量下降时 |
| source-driven-development | 基于官方文档的每个框架决策——验证、引用来源、标记未经验证的内容 | 你需要为任何框架或库提供权威、来源引用的代码 |
| doubt-driven-development | 对进行中的每个非平凡决策进行对抗性新上下文审查——CLAIM → EXTRACT → DOUBT → RECONCILE → STOP,可选用户授权的跨模型升级 | 风险高(生产、安全、不可逆),在不熟悉的代码中工作,或自信的输出现在验证比以后调试更便宜 |
| frontend-ui-engineering | 组件架构、设计系统、状态管理、响应式设计、WCAG 2.1 AA可访问性 | 构建或修改面向用户的界面 |
| api-and-interface-design | 契约优先设计、Hyrum定律、One-Version规则、错误语义、边界验证 | 设计API、模块边界或公共接口 |
验证 - 证明它工作
| 技能 | 作用 | 使用时机 |
|---|---|---|
| browser-testing-with-devtools | Chrome DevTools MCP用于实时运行时数据——DOM检查、控制台日志、网络追踪、性能分析 | 构建或调试任何在浏览器中运行的内容 |
| debugging-and-error-recovery | 五步分类法:复现、定位、简化、修复、防护。停止线规则、安全回退 | 测试失败、构建中断或行为异常 |
审查 - 合并前的质量门
| 技能 | 作用 | 使用时机 |
|---|---|---|
| code-review-and-quality | 五轴审查、变更大小(约100行)、严重级别标签(Nit/Optional/FYI)、审查速度规范、拆分策略 | 合并任何变更前 |
| code-simplification | Chesterton's Fence、500规则、降低复杂度同时保留精确行为 | 代码能工作但比应有的更难读或难维护 |
| security-and-hardening | OWASP Top 10预防、认证模式、秘密管理、依赖审计、三层边界系统 | 处理用户输入、认证、数据存储或外部集成 |
| performance-optimization | 先测量再优化——Core Web Vitals目标、性能分析工作流、打包分析、反模式检测 | 存在性能要求或怀疑有回归 |
发布 - 自信地部署
| 技能 | 作用 | 使用时机 |
|---|---|---|
| git-workflow-and-versioning | 基于主干开发、原子提交、变更大小(约100行)、提交即保存点模式 | 进行任何代码变更(始终) |
| ci-cd-and-automation | 左移、更快即更安全、特性开关、质量门流水线、失败反馈循环 | 设置或修改构建和部署流水线 |
| deprecation-and-migration | 代码即负债思维、强制性与建议性弃用、迁移模式、僵尸代码移除 | 移除旧系统、迁移用户或淘汰特性 |
| documentation-and-adrs | 架构决策记录、API文档、内联文档标准——记录为什么 | 做架构决策、变更API或发布特性 |
| observability-and-instrumentation | 结构化日志、RED指标、OpenTelemetry追踪、基于症状的告警——边构建边检测 | 添加遥测,或发布任何在生产中运行的内容 |
| shipping-and-launch | 发布前检查清单、特性开关生命周期、分阶段发布、回滚程序、监控设置 | 准备部署到生产环境 |
代理角色
预配置的专家角色,用于针对性审查:
| 代理 | 角色 | 视角 |
|---|---|---|
| code-reviewer | 高级职员工程师 | 以“高级职员工程师会批准这个吗?”为标准进行五轴代码审查 |
| test-engineer | QA专家 | 测试策略、覆盖率分析以及Prove-It模式 |
| security-auditor | 安全工程师 | 漏洞检测、威胁建模、OWASP评估 |
| web-performance-auditor | Web性能工程师 | 快速/深度模式下的Core Web Vitals审计,以及指标诚实规则;通过/webperf运行 |
参考清单
技能在需要时拉入的快速参考材料:
| 参考 | 涵盖内容 |
|---|---|
| definition-of-done.md | 项目范围的完成标准,每个变更必须满足,与每任务验收标准相对照 |
| testing-patterns.md | 测试结构、命名、模拟、React/API/E2E示例、反模式(JavaScript/TypeScript) |
| security-checklist.md | 提交前检查、认证、输入验证、头部、CORS、OWASP Top 10 |
| performance-checklist.md | Core Web Vitals目标、前端/后端检查清单、测量命令 |
| accessibility-checklist.md | 键盘导航、屏幕阅读器、视觉设计、ARIA、测试工具 |
| observability-checklist.md | 值班问题、结构化日志、RED/USE指标、追踪、基于症状的告警、预发布门 |
| orchestration-patterns.md | 认可的多角色编排模式、反模式,以及“角色不调用角色”规则 |
技能如何工作
每个技能遵循一致的结构:
- Frontmatter:名称、描述、使用时机。
- Overview:该技能做什么。
- When to Use:触发条件。
- Process:逐步工作流。
- Rationalizations:借口 + 反驳。
- Red Flags:出问题的迹象。
- Verification:证据要求。
关键设计选择:
- 过程而非散文。 技能是代理遵循的工作流,而不是它们阅读的参考文档。每个都有步骤、检查点和退出标准。
- 反合理化。 每个技能都包含一个表格,列出代理常用跳过步骤的借口(例如“我稍后添加测试”),并附有文档化的反驳论据。
- 验证不可协商。 每个技能都以证据要求结束——测试通过、构建输出、运行时数据。“看起来正确”永远不够。
- 渐进式披露。
SKILL.md是入口点。支持性参考仅在需要时加载,保持token使用最小化。
为什么需要Agent Skills?
AI编码代理默认走最短路径——这通常意味着跳过规范、测试、安全审查以及使软件可靠的实践。Agent Skills为代理提供结构化工作流,强制执行高级工程师在生产代码中使用的相同纪律。
每个技能编码了来之不易的工程判断:何时编写规范,测试什么,如何审查,以及何时发布。这些不是通用提示——它们是那种有意见、过程驱动的工作流,将生产质量的工作与原型质量的工作区分开来。
这些技能融入了Google工程文化的最佳实践——包括来自Software Engineering at Google和Google的工程实践指南的概念。你会在API设计中发现Hyrum定律,在测试中发现Beyonce规则和测试金字塔,在代码审查中发现变更大小和审查速度规范,在简化中发现Chesterton's Fence,在Git工作流中发现基于主干开发,在CI/CD中发现左移和特性开关,以及一个专门的弃用技能将代码视为负债。这些不是抽象原则——它们直接嵌入到代理遵循的逐步工作流中。
对比
想知道它与Superpowers或Matt Pocock's skills相比如何?请参阅comparison.md以获得诚实的并排对比,了解三个项目如何不同,以及何时使用哪个——包括一个受控的头对头实验的链接。