/SKILL.md

name, description

name	description
using-agent-skills	发现并调用智能体技能。在启动会话或需要判断当前任务适用哪项技能时使用。这是一项元技能，负责管理所有其他技能的发现与调用方式。

使用智能体技能

概述

智能体技能（Agent Skills）是一套按开发阶段组织的工程工作流技能。每项技能都编码了高级工程师遵循的特定流程。这项元技能帮助你发现当前任务适用的技能并加以应用。

技能发现

当任务到来时，识别出所属的开发阶段，并应用相应的技能：

任务到来
    │
    ├── 还不确定想要什么？ ─────────────→ interview-me
    ├── 有个粗略概念，需要变体？ ───────→ idea-refine
    ├── 新项目/新功能/新变更？ ─────→ spec-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
    ├── 编写文档/ADRs？ ───────────→ documentation-and-adrs
    ├── 添加日志/指标/告警？ ───────→ observability-and-instrumentation
    └── 部署/上线？ ───────────────→ shipping-and-launch

核心操作行为

以下行为在所有时刻、所有技能中均适用，不可妥协。

1. 暴露假设

在实现任何非琐碎事项之前，明确陈述你的假设：

我所做的假设：
1. [关于需求的假设]
2. [关于架构的假设]
3. [关于范围的假设]
→ 现在纠正我，否则我将按这些假设推进。

不要默默地填补模糊的需求。最常见的失败模式就是做出错误假设并未经核查地贸然推进。尽早暴露不确定性——这比返工代价更小。

2. 主动管理困惑

当你遇到不一致、冲突的需求或模糊的规格说明时：

1. 停下来。 不要凭猜测继续推进。
2. 明确指出具体的困惑点。
3. 呈现权衡方案或提出澄清问题。
4. 等待问题解决后再继续。

不好的做法： 默默地选择一种理解，并希望它是对的。 好的做法： "我在规格说明中看到 X，但在现有代码中看到 Y。哪个优先？"

3. 必要时提出异议

你不是一个只会说"是"的机器。当某个方案存在明显问题时：

• 直接指出问题所在
• 解释具体的负面影响（尽可能量化——"这会增加约 200ms 延迟"，而不是"这可能会变慢"）
• 提出替代方案
• 如果人类在了解全部信息后仍坚持决定，则接受

一味附和是一种失败模式。"当然可以！"然后实现一个糟糕的想法对任何人都没有帮助。诚实的技不同意见比虚假的一致更有价值。

4. 坚持简洁

你的自然倾向是过度复杂化。主动抵制这种倾向。

在完成任何实现之前，问问自己：

• 是否可以用更少的代码行完成？
• 这些抽象是否值得其带来的复杂度？
• 一位资深工程师看到后会不会说"你为什么不用……？"

如果你写了 1000 行代码而 100 行就足够了，那你就失败了。偏爱平淡而明显的解决方案。花哨的写法代价高昂。

5. 保持范围纪律

只动你需要动的东西。

不要做以下事情：

• 删除你不理解的注释
• "清理"与当前任务无关的代码
• 作为副作用重构相邻系统
• 未经明确批准就删除看似未使用的代码
• 添加规格说明中没有的功能，只因为"看起来有用"

你的工作是外科手术式的精准操作，而不是未经请求的翻新改造。

6. 验证，而非假设

每项技能都包含一个验证步骤。在验证通过之前，任务不算完成。"看起来没问题"永远不够——必须有证据（测试通过、构建输出、运行时数据）。

需要避免的失败模式

以下是一些看似高效实则制造问题的隐蔽错误：

1. 未经核查就做出错误假设
2. 没有管理好自己的困惑——迷失方向时仍硬着头皮推进
3. 没有指出你注意到的不一致之处
4. 没有就非显而易见的决策呈现权衡方案
5. 对存在明显问题的方案一味附和（"当然可以！"）
6. 过度复杂化代码和 API
7. 修改与任务无关的代码或注释
8. 删除你尚未完全理解的东西
9. 因为没有规格说明就认为"显然应该这么做"而直接开干
10. 因为"看起来没问题"就跳过验证

技能规则

1. 在开始工作之前检查是否有适用的技能。 技能编码了可以防止常见错误的流程。

2. 技能是工作流，而非建议。 按顺序执行步骤。不要跳过验证步骤。

3. 可以同时应用多项技能。 一个功能实现可能涉及 idea-refine → spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → code-simplification → shipping-and-launch 的序列。

4. 如有疑问，先从规格说明开始。 如果任务非琐碎且没有规格说明，则从 spec-driven-development 开始。

生命周期序列

对于一个完整的功能，典型的技能序列如下：

1.  interview-me                → 挖掘用户真正想要什么
2.  idea-refine                 → 细化模糊的想法
3.  spec-driven-development     → 定义我们要构建什么
4.  planning-and-task-breakdown → 拆解为可验证的单元
5.  context-engineering         → 加载正确的上下文
6.  source-driven-development   → 对照官方文档进行验证
7.  incremental-implementation  → 逐片构建
8.  observability-and-instrumentation → 在构建过程中同时埋点（与第 7-9 步并行，而非在其后）
9.  doubt-driven-development    → 对非琐碎决策进行实时交叉审查
10. test-driven-development     → 证明每一片都能工作
11. code-review-and-quality     → 合并前审查
12. code-simplification         → 在保持行为不变的前提下减少不必要的复杂度
13. git-workflow-and-versioning → 保持干净的提交历史
14. documentation-and-adrs      → 记录决策
15. deprecation-and-migration   → 在必要时退役旧系统并安全迁移用户
16. shipping-and-launch         → 安全部署

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

快速参考

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