/writing-skills

name: writing-skills
description: 当创建新技能、编辑现有技能或在部署前验证技能是否有效时使用
version: "1.0.0"
license: MIT
metadata:
  hermes:
    tags: [skills, documentation]

编写技能

概述

**编写技能就是将测试驱动开发应用于流程文档。**

**个人技能存放在智能体特定的目录中（Claude Code 用 `~/.claude/skills`，Codex 用 `~/.agents/skills/`）**

你编写测试用例（带子智能体的压力场景），观察它们失败（基线行为），编写技能（文档），观察测试通过（智能体遵守规则），然后重构（堵住漏洞）。

**核心原则：** 如果你没有观察到智能体在没有该技能时失败，你就不知道这个技能是否教了正确的东西。

**必需背景：** 在使用此技能前，你必须理解 test-driven-development。该技能定义了基本的红-绿-重构循环。本技能将 TDD 适配到文档编写中。

**官方指南：** Anthropic 官方的技能编写最佳实践请参见 anthropic-best-practices.md。该文档提供了补充本技能 TDD 导向方法的额外模式和指南。

什么是技能？

**技能**是经过验证的技术、模式或工具的参考指南。技能帮助未来的 Claude 实例找到并应用有效的方法。

**技能是：** 可复用的技术、模式、工具、参考指南

**技能不是：** 关于你某次如何解决问题的叙事

TDD 映射到技能

| TDD 概念 | 技能创建 | |----------|---------| | **测试用例** | 带子智能体的压力场景 | | **生产代码** | 技能文档（SKILL.md） | | **测试失败（红）** | 智能体在没有技能时违反规则（基线） | | **测试通过（绿）** | 智能体在有技能时遵守规则 | | **重构** | 在保持合规的同时堵住漏洞 | | **先写测试** | 在编写技能之前先运行基线场景 | | **观察失败** | 记录智能体使用的确切合理化借口 | | **最小代码** | 编写针对那些具体违规行为的技能 | | **观察通过** | 验证智能体现在遵守规则 | | **重构循环** | 发现新的合理化借口 → 堵住 → 重新验证 |

整个技能创建过程遵循红-绿-重构。

何时创建技能

**创建条件：**

• 技术对你来说不是直觉上显而易见的
• 你会在不同项目中反复引用
• 模式具有广泛适用性（非项目特定）
• 其他人也会受益

**不要创建：**

• 一次性解决方案
• 其他地方有充分文档的标准实践
• 项目特定的约定（放在 CLAUDE.md 中）
• 机械性约束（如果可以用正则/验证强制执行，就自动化——文档留给需要判断的场景）

技能类型

技术类

有具体步骤的方法（condition-based-waiting、root-cause-tracing）

模式类

思考问题的方式（flatten-with-flags、test-invariants）

参考类

API 文档、语法指南、工具文档（office docs）

目录结构

skills/
  skill-name/
    SKILL.md              # 主参考文档（必需）
    supporting-file.*     # 仅在需要时

**扁平命名空间** - 所有技能在一个可搜索的命名空间中

**分离文件的情况：** 1. **大量参考内容**（100+ 行）- API 文档、全面的语法说明 2. **可复用工具** - 脚本、实用程序、模板

**保持内联：**

• 原则和概念
• 代码模式（< 50 行）
• 其他所有内容

SKILL.md 结构

**Frontmatter（YAML）：**

• 两个必需字段：`name` 和 `description`（完整支持字段参见 [agentskills.io/specification](https://agentskills.io/specification)）
• 总计最多 1024 字符
• `name`：只使用字母、数字和连字符（不要用括号、特殊字符）
• `description`：第三人称，仅描述何时使用（不是做什么）
• 以"Use when..."开头，聚焦于触发条件
• 包含具体的症状、场景和上下文
• **绝不总结技能的流程或工作流**（参见 SDO 章节了解原因）
• 尽量控制在 500 字符以内

---
name: Skill-Name-With-Hyphens
description: Use when [具体的触发条件和症状]
---

# 技能名称

## 概述
这是什么？用 1-2 句话说明核心原则。

## 何时使用
[如果决策不明显，使用小型内联流程图]

症状和用例的要点列表
不适用的场景

## 核心模式（技术/模式类）
前后代码对比

## 快速参考
用于快速浏览常见操作的表格或要点

## 实现
简单模式内联代码
大量参考或可复用工具链接到文件

## 常见错误
常见问题 + 修复方法

## 实际效果（可选）
具体结果

技能发现优化（SDO）

**发现至关重要：** 未来的 Claude 需要找到你的技能

1. 丰富的描述字段

**目的：** Claude 读取描述来决定为当前任务加载哪些技能。让它能回答："我现在应该读这个技能吗？"

**格式：** 以"Use when..."开头，聚焦于触发条件

**关键：描述 = 何时使用，不是技能做什么**

描述应该只描述触发条件。不要在描述中总结技能的流程或工作流。

**为什么这很重要：** 测试表明，当描述总结了技能的工作流时，Claude 可能会跟随描述而非阅读完整的技能内容。一个写着"任务间进行代码审查"的描述导致 Claude 只做了一次审查，尽管技能的流程图清楚地展示了两次审查（先规格合规再代码质量）。

当描述改为仅"在当前会话中执行包含独立任务的实现计划时使用"（无工作流摘要）时，Claude 正确地阅读了流程图并遵循了两阶段审查流程。

**陷阱：** 总结工作流的描述创建了 Claude 会走的捷径。技能正文变成了 Claude 跳过的文档。

# 错误：总结了工作流 - Claude 可能会跟随描述而非阅读技能
description: Use when executing plans - dispatches subagent per task with code review between tasks

# 错误：流程细节太多
description: Use for TDD - write test first, watch it fail, write minimal code, refactor

# 正确：只有触发条件，无工作流摘要
description: Use when executing implementation plans with independent tasks in the current session

# 正确：仅触发条件
description: Use when implementing any feature or bugfix, before writing implementation code

**内容：**

• 使用具体的触发条件、症状和场景来表明此技能适用
• 描述问题（竞态条件、行为不一致）而非语言特定的症状（setTimeout、sleep）
• 保持触发条件技术无关，除非技能本身是技术特定的
• 如果技能是技术特定的，在触发条件中明确说明
• 用第三人称写（注入到系统提示中）
• **绝不总结技能的流程或工作流**

# 错误：太抽象、模糊，未包含何时使用
description: For async testing

# 错误：第一人称
description: I can help you with async tests when they're flaky

# 错误：提到了技术但技能并非该技术特定的
description: Use when tests use setTimeout/sleep and are flaky

# 正确：以"Use when"开头，描述问题，无工作流
description: Use when tests have race conditions, timing dependencies, or pass/fail inconsistently

# 正确：技术特定的技能带有明确的触发条件
description: Use when using React Router and handling authentication redirects

2. 关键词覆盖

使用 Claude 会搜索的词语：

• 错误信息："Hook timed out"、"ENOTEMPTY"、"race condition"
• 症状："flaky"、"hanging"、"zombie"、"pollution"
• 同义词："timeout/hang/freeze"、"cleanup/teardown/afterEach"
• 工具：实际命令、库名称、文件类型

3. 描述性命名

**使用主动语态，动词优先：**

• ✅ `creating-skills` 而非 `skill-creation`
• ✅ `condition-based-waiting` 而非 `async-test-helpers`

4. Token 效率（关键）

**问题：** getting-started 和频繁引用的技能会加载到每个对话中。每个 token 都很重要。

**目标字数：**

• getting-started 工作流：每个 <150 词
• 频繁加载的技能：总计 <200 词
• 其他技能：<500 词（仍要简洁）

**技巧：**

**将细节移到工具帮助中：**

# 错误：在 SKILL.md 中列出所有参数
search-conversations supports --text, --both, --after DATE, --before DATE, --limit N

# 正确：引用 --help
search-conversations 支持多种模式和过滤器。运行 --help 查看详情。

**使用交叉引用：**

# 错误：重复工作流细节
搜索时，用模板分派子智能体……
[20 行重复的说明]

# 正确：引用其他技能
始终使用子智能体（节省 50-100 倍上下文）。必需：使用 [other-skill-name] 工作流。

**压缩示例：**

# 错误：冗长的示例（42 词）
你的搭档："我们之前是怎么处理 React Router 中的认证错误的？"
你：我来搜索过去对话中的 React Router 认证模式。
[用搜索查询分派子智能体："React Router authentication error handling 401"]

# 正确：精简的示例（20 词）
搭档："我们之前是怎么处理 React Router 中的认证错误的？"
你：正在搜索……
[分派子智能体 → 整合]

**消除冗余：**

• 不要重复交叉引用的技能中已有的内容
• 不要解释从命令中就能看出的东西
• 不要为同一模式提供多个示例

**验证：**

wc -w skills/path/SKILL.md
# getting-started 工作流：目标 <150 每个
# 其他频繁加载的：目标总计 <200

**用你做的事或核心洞察来命名：**

• ✅ `condition-based-waiting` > `async-test-helpers`
• ✅ `using-skills` 而非 `skill-usage`
• ✅ `flatten-with-flags` > `data-structure-refactoring`
• ✅ `root-cause-tracing` > `debugging-techniques`

**动名词（-ing）适合描述流程：**

• `creating-skills`、`testing-skills`、`debugging-with-logs`
• 主动的，描述你正在进行的操作

5. 交叉引用其他技能

**编写引用其他技能的文档时：**

仅使用技能名称，带有明确的必需标记：

• ✅ 好的：`**必需子技能：** 使用 test-driven-development`
• ✅ 好的：`**必需背景：** 你必须理解 systematic-debugging`
• ❌ 差的：`参见 skills/testing/test-driven-development`（不清楚是否必需）
• ❌ 差的：`@skills/testing/test-driven-development/SKILL.md`（强制加载，浪费上下文）

**为什么不用 @ 链接：** `@` 语法会立即强制加载文件，在你需要之前就消耗 200k+ 的上下文。

流程图使用

digraph when_flowchart {
    "需要展示信息?" [shape=diamond];
    "我可能在决策中犯错?" [shape=diamond];
    "使用 markdown" [shape=box];
    "小型内联流程图" [shape=box];

    "需要展示信息?"