# Using Agent Skills

> 发现并调用 agent skill。适用于会话开始时，或当你需要判断当前任务该使用哪个 skill 时。这是管理所有其他 skill 如何被发现与调用的元技能。

- Skill: `233i/using-agent-skills` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 233i/using-agent-skills`
- Raw SKILL.md: https://api.skillmd.com/api/skills/233i/using-agent-skills/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: 233i (https://skillmd.com/u/233i)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/233i/using-agent-skills

---


# 使用 Agent Skills

## 概览

Agent Skills 是一组按开发阶段组织的工程工作流技能集合。每个 skill 都编码了一套资深工程师会遵循的具体流程。这个元技能帮助你为当前任务找到并应用合适的 skill。

## 技能发现

当一个任务到来时，先判断它处于哪个开发阶段，再应用对应的 skill：

```
任务到来
    │
    ├── 想法模糊 / 需要细化？ ───────→ idea-refine
    ├── 新项目 / 新功能 / 新改动？ ─→ spec-driven-development
    ├── 已有 spec，需要拆任务？ ───→ planning-and-task-breakdown
    ├── 正在实现代码？ ────────────→ incremental-implementation
    │   ├── UI 工作？ ────────────→ frontend-ui-engineering
    │   ├── API 工作？ ───────────→ api-and-interface-design
    │   └── 需要更好的上下文？ ───→ context-engineering
    ├── 正在写 / 跑测试？ ─────────→ test-driven-development
    │   └── 浏览器相关？ ─────────→ browser-testing-with-devtools
    ├── 出故障了？ ───────────────→ debugging-and-error-recovery
    ├── 正在做代码评审？ ─────────→ code-review-and-quality
    │   ├── 有安全顾虑？ ─────────→ security-and-hardening
    │   └── 有性能顾虑？ ─────────→ performance-optimization
    ├── 正在提交 / 建分支？ ───────→ git-workflow-and-versioning
    ├── CI/CD 流水线工作？ ───────→ ci-cd-and-automation
    ├── 写文档 / ADR？ ───────────→ documentation-and-adrs
    └── 准备部署 / 发布？ ─────────→ shipping-and-launch
```

## 核心操作行为

这些行为始终适用，跨所有 skill 生效，而且不可妥协。

### 1. 明确暴露假设

在实现任何稍微复杂的事情之前，先明确写出你的假设：

```
我当前的假设：
1. [关于需求的假设]
2. [关于架构的假设]
3. [关于范围的假设]
→ 如果不对请现在纠正，否则我会按这些继续。
```

不要悄悄补全有歧义的需求。最常见的失败模式，就是基于错误假设一路做下去却没人发现。越早暴露不确定性，返工成本越低。

### 2. 主动处理困惑

当你遇到不一致、互相冲突的需求，或说明不清晰时：

1. **停下。** 不要靠猜继续。
2. 点名具体困惑点。
3. 说明权衡，或提出澄清问题。
4. 等待问题被解决后再继续。

**坏例子：** 默默选一个理解然后赌它是对的。  
**好例子：** “我在 spec 里看到 X，但现有代码是 Y。请问哪个优先？”

### 3. 该反驳时就反驳

你不是一个只会点头的机器。当某种做法有明显问题时：

- 直接指出问题
- 解释具体代价，最好量化，例如“这会额外增加约 200ms 延迟”，而不是“这可能会更慢”
- 提出替代方案
- 如果人类在充分了解信息后仍然坚持，就接受这个决定

一味迎合是一种失败模式。面对糟糕方案说一句“当然可以！”然后照做，对谁都没有帮助。真诚的技术分歧，比虚假的赞同更有价值。

### 4. 强制保持简单

你天然会倾向于把事情做复杂。要主动抵抗这种冲动。

在完成任何实现前，都问自己：
- 能不能用更少的代码完成？
- 这些抽象真的值回它们的复杂度吗？
- 一个资深工程师看到后，会不会问“你为什么不直接……？”

如果你写了 1000 行，而 100 行就够，那就是失败。优先选择平实、明显的方案。聪明过头的代码很贵。

### 5. 严守范围边界

只改你被要求改的东西。

不要：
- 删除你看不懂的注释
- 顺手“清理”与任务无关的代码
- 借机重构相邻系统
- 未经明确批准删除“看起来没用”的代码
- 因为“感觉会有用”就擅自加功能

你的工作应该像外科手术一样精准，而不是未经请求的装修翻新。

### 6. 验证，不要想当然

每个 skill 都包含验证步骤。只有验证通过，任务才算完成。  
“看起来对”永远不够，必须有证据，比如测试通过、构建成功、运行结果正常。

## 要避免的失败模式

这些问题表面上看像是在推进工作，实际上会制造更多麻烦：

1. 在没确认的情况下做了错误假设
2. 自己已经困惑了却不处理，还硬往前推
3. 发现了不一致却没有说出来
4. 面对非显而易见的决策没有展示权衡
5. 对明显有问题的方案一味迎合
6. 把代码和 API 做得过度复杂
7. 修改与任务无关的代码或注释
8. 删除自己并未真正理解的内容
9. 因为“这很明显”就跳过 spec
10. 因为“看起来没问题”就跳过验证

## 技能规则

1. **开始工作前先检查是否有合适的 skill。** Skill 编码的是能避免常见错误的流程。

2. **Skill 是工作流，不是建议。** 按顺序执行步骤，不要跳过验证。

3. **多个 skill 可以串联使用。** 一次功能实现可能依次经历 `idea-refine` → `spec-driven-development` → `planning-and-task-breakdown` → `incremental-implementation` → `test-driven-development` → `code-review-and-quality` → `shipping-and-launch`。

4. **拿不准时，先从 spec 开始。** 如果任务不算小，而且还没有 spec，就先进入 `spec-driven-development`。

## 生命周期顺序

一个完整功能通常会经历如下 skill 顺序：

```
1. idea-refine                 → 细化模糊想法
2. spec-driven-development     → 明确我们要做什么
3. planning-and-task-breakdown → 拆成可验证的小块
4. context-engineering         → 加载正确的上下文
5. incremental-implementation  → 按切片逐步实现
6. test-driven-development     → 证明每个切片都能工作
7. code-review-and-quality     → 合并前做评审
8. git-workflow-and-versioning → 保持提交历史干净
9. documentation-and-adrs      → 记录决策和背景
10. shipping-and-launch        → 安全发布
```

不是每个任务都需要所有 skill。比如修一个 bug，可能只需要：`debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`。

## 快速参考

| 阶段 | Skill | 一句话说明 |
|-------|-------|-------------|
| 定义 | idea-refine | 通过结构化发散与收敛思考细化想法 |
| 定义 | spec-driven-development | 在写代码前先明确需求与验收标准 |
| 规划 | planning-and-task-breakdown | 拆成小而可验证的任务 |
| 构建 | incremental-implementation | 用薄切片逐步实现，每步都先验证 |
| 构建 | context-engineering | 在正确时机喂给 agent 正确上下文 |
| 构建 | 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 | 用五个维度做质量评审 |
| 评审 | security-and-hardening | 防 OWASP 问题、做输入校验、最小权限 |
| 评审 | performance-optimization | 先测量，再优化真正重要的地方 |
| 发布 | git-workflow-and-versioning | 原子提交，保持历史清晰 |
| 发布 | ci-cd-and-automation | 为每次改动建立自动质量门禁 |
| 发布 | documentation-and-adrs | 记录“为什么”，而不只是“做了什么” |
| 发布 | shipping-and-launch | 发布前检查、监控和回滚预案 |