using-agent-skills

用途

Using Agent Skills 是一个元技能，帮助你在开始工作时发现并应用正确的技能。Agent Skills 是一组按开发阶段组织的工程工作流技能，每个技能编码了资深工程师遵循的特定流程。当任务到来时，先识别开发阶段，再应用对应技能。

主要能力

技能发现

根据任务状态选择技能：

还不知道想要什么 → interview-me
有粗略概念、需要变体 → idea-refine
新项目/功能/变更 → spec-driven-development
没有写下质量标准 → constraint-driven-development
已有规格、需要任务 → planning-and-task-breakdown
正在实现代码 → incremental-implementation
- UI 工作 → frontend-ui-engineering
- API 工作 → api-and-interface-design
- 需要更好上下文 → context-engineering
- 需要文档验证的代码 → source-driven-development
- 高风险/不熟悉的代码 → doubt-driven-development
编写/运行测试 → test-driven-development
- 基于浏览器 → browser-testing-with-devtools
出问题了 → debugging-and-error-recovery
审查代码 → code-review-and-quality
- 太复杂 → code-simplification
- 安全顾虑 → security-and-hardening
- 性能顾虑 → performance-optimization
提交/分支 → git-workflow-and-versioning
CI/CD 流水线工作 → ci-cd-and-automation
弃用/迁移 → deprecation-and-migration
编写文档/ADR → documentation-and-adrs
添加日志/指标/告警 → observability-and-instrumentation
部署/发布 → shipping-and-launch

核心操作行为

这些行为在所有技能中始终适用，不可协商：

显式声明假设：在实现任何非平凡内容前，明确说明你的假设（关于需求、架构、范围），并请对方立即纠正。不要默默填补模糊需求。
主动管理困惑：遇到不一致、冲突需求或不清楚的规格时，停止，不要猜测；指出具体困惑；呈现权衡或提出澄清问题；等待解决后再继续。
必要时提出反对：你不是应声虫。当方案有明显问题时，直接指出问题，解释具体缺点（尽可能量化），提出替代方案，若对方在充分知情下坚持则接受其决定。谄媚是一种失败模式。
强制简洁：主动抵制过度复杂化。完成实现前问：能否用更少行完成？这些抽象是否值得其复杂度？资深工程师会不会说“你为什么不直接……”？优先选择无聊、显而易见的方案。
保持范围纪律：只触碰被要求触碰的内容。不要删除不理解的注释，不要“清理”与任务无关的代码，不要顺带重构相邻系统，不要未经明确批准删除看似未使用的代码，不要因为“看起来有用”而添加规格外的功能。
验证而非假设：每个技能都包含验证步骤。任务在验证通过前不算完成。“看起来对”永远不够，必须有证据（通过的测试、构建输出、运行时数据）。每个技能的验证是局部检查；适用于每次变更的项目级标准是 Definition of Done：测试通过、无回归、运行时行为已验证、文档已更新。

需要避免的失败模式

未经检查就做出错误假设
不管理自己的困惑——迷失时仍硬着头皮前进
不指出你注意到的不一致
对非显而易见的决策不呈现权衡
对有明显问题的方案谄媚（“当然！”）
过度复杂化代码和 API
修改与任务无关的代码或注释
删除你未完全理解的内容
因为“这很明显”而不写规格就构建
因为“看起来对”而跳过验证

技能规则

开始工作前检查是否有适用的技能。技能编码了防止常见错误的流程。
技能是工作流，不是建议。按顺序遵循步骤，不要跳过验证步骤。
多个技能可以同时适用。一个功能实现可能依次涉及 idea-refine → spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → code-simplification → shipping-and-launch。
有疑问时，从规格开始。如果任务非平凡且没有规格，从 spec-driven-development 开始。

使用方式

生命周期序列

对于完整功能，典型技能序列为：

interview-me → 提取用户真正想要的东西
idea-refine → 细化模糊想法
spec-driven-development → 定义我们要构建什么
planning-and-task-breakdown → 拆分为可验证的块
context-engineering → 加载正确的上下文
source-driven-development → 对照官方文档验证
incremental-implementation → 逐片构建
observability-and-instrumentation → 边构建边埋点（与 7-9 并行，而非之后）
doubt-driven-development → 在过程中交叉审查非平凡决策
test-driven-development → 证明每一片可用
code-review-and-quality → 合并前审查
code-simplification → 在保持行为的同时减少不必要的复杂度
git-workflow-and-versioning → 干净的提交历史
documentation-and-adrs → 记录决策
deprecation-and-migration → 需要时安全退役旧系统并迁移用户
shipping-and-launch → 安全部署

并非每个任务都需要每个技能。一个 bug 修复可能只需要：debugging-and-error-recovery → test-driven-development → code-review-and-quality。

快速参考

阶段	技能	一句话摘要
Define	interview-me	在任何计划、规格或代码存在前，先弄清用户真正想要什么
Define	idea-refine	通过结构化的发散与收敛思维细化想法
Define	spec-driven-development	代码之前先有需求和验收标准
Plan	planning-and-task-breakdown	分解为小的、可验证的任务
Build	incremental-implementation	薄垂直切片，扩展前先测试每一片
Build	source-driven-development	实现前对照官方文档验证
Build	doubt-driven-development	对每个非平凡决策进行对抗性全新上下文审查
Build	context-engineering	在正确的时间提供正确的上下文
Build	frontend-ui-engineering	具备无障碍性的生产级 UI
Build	api-and-interface-design	具有清晰契约的稳定接口
Verify	test-driven-development	先写失败测试，再使其通过
Verify	browser-testing-with-devtools	使用 Chrome DevTools MCP 进行运行时验证
Verify	debugging-and-error-recovery	复现 → 定位 → 修复 → 防护
Review	code-review-and-quality	五轴审查与质量门禁
Review	code-simplification	在保持行为的同时减少不必要的复杂度
Review	security-and-hardening	OWASP 防护、输入验证、最小权限
Review	performance-optimization	先测量，只优化重要的部分
Ship	git-workflow-and-versioning	原子提交、干净历史
Ship	ci-cd-and-automation	每次变更上的自动化质量门禁
Ship	deprecation-and-migration	移除旧系统并安全迁移用户
Ship	documentation-and-adrs	记录为什么，而不仅是是什么
Ship	observability-and-instrumentation	结构化日志、RED 指标、追踪、基于症状的告警
Ship	shipping-and-launch	发布前检查清单、监控、回滚计划

适用场景

适用于开始一个会话时，或需要判断当前工作应适用哪个技能或工作流时。适合希望按资深工程师流程组织开发工作的场景，覆盖从需求定义、规划、构建、验证、审查到发布的完整生命周期。

限制

资料未提供该技能的具体安装命令、收费方式、支持平台或运行环境要求。