# Lion Writing Skills

> 在 Lion-Skills 仓库创建或修改 skill 时。

- Skill: `lion-1209/lion-writing-skills` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lion-1209/lion-writing-skills`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lion-1209/lion-writing-skills/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Lion-1209 (https://skillmd.com/u/lion-1209)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lion-1209/lion-writing-skills

---


# Lion Writing Skills

## 概述

Lion-Skills 的"造 skill 流水线"：按本仓库规范，把一个重复的工作流沉淀成可复制、经验证的 skill。

核心原则：skill 是给未来 Claude 读的"操作手册"——它的价值不在于你写了什么，而在于未来的 Claude 在触发它时，能照着做出正确的事。

## 何时使用

- 用户想新增一个 skill（"帮我加个 X 的 skill"）
- 用户想修改/优化现有 skill
- 用户想检查某个 skill 写得是否符合规范
- 想把对话里反复出现的工作流沉淀成 skill

**不该做成 skill 的情况**：一次性的、项目特定的约定（放 CLAUDE.md）、能用简单校验自动化的（写成校验脚本而不是文档）。

**只是审查/优化现有 skill 时**：直接对照下文相关规则做合规判断即可，不必每次重走第 1 步"值不值得做"四问——那是**新增** skill 的决策；现有 skill 要不要继续存在，是另一个问题。

## 核心内容

### 第 1 步：判断值不值得做

回答四个问题（都"是"才值得做）：
1. 高频吗？（反复出现，不是一次性的）
2. 跨项目吗？（不止一个代码库用得到）
3. 有判断空间吗？（需要决策/经验，不是机械操作——机械操作写成脚本）
4. 未来 Claude 不读这个 skill，会做错或做差吗？

任何一个答"否"，就别做成独立 skill：项目特定的约定放 CLAUDE.md，能机械自动化的写成校验脚本，一次性的直接在对话里处理。

### 第 2 步：复制模板，填 frontmatter

新 skill 建在 `skills/<name>/SKILL.md`（同名目录，里面放 `SKILL.md`，可选再放 `evals/` 存验证用例）。复制 `template/SKILL.md` 过去，填两个字段：
- `name`：全小写、连字符，用 skill 的核心动作或概念命名（如 `commit-message`、`error-handling`、`onboarding-unknown-codebase`）。不要下划线或驼峰（`commit_message`、`CommitMessage` 都错）
- `description`：**只写"何时触发"**，第三人称，中文，用三段式——**①触发场景**（"当用户……时使用"）+ **②典型信号**（把用户实际会说的原话尽量列全）+ **③涉及关键词**（中文说法 + 常见英文术语）。这样覆盖面广、不易漏触发。上限 1024 字符

> 关键：description 绝不能写工作流（"先做 A 再做 B"）。原因——测试发现 Claude 会偷懒只读 description 跳过正文。把流程留给正文。

### 第 3 步：写正文

按这个骨架：概述 / 何时使用 / 核心内容 / 常见错误（参考 `template/SKILL.md`）。

写作约定：
- **解释 why**，少用全大写 MUST（讲道理比下命令管用）
- **一个优秀例子** > 多语言版本；例子尽量覆盖该 skill 最核心的 2–3 类场景，而非只示范单类
- 正文 < 500 行；超了拆 `references/`
- 中文为主，工具名/术语保留英文

### 第 4 步：轻量验证

**前置**：先确认目标 SKILL.md 在手（文件路径或正文）。用户只说"帮我验证"却没给内容时，先向用户要；skill 还在草稿态没落盘时，把全文直接贴进 subagent 的 prompt 即可，效果等同落盘。

写 2–3 个真实测试 prompt，用 subagent 带着新 skill 跑，看产出对不对。**这一步最容易被跳过，但也最能发现问题，别省。**

**怎么算"真实" prompt**：要像真实用户会说的、带具体细节——好的如"我把组件状态从 useState 换成 useReducer，还修了个内存泄漏，写个 commit message"；坏的如"测一下你的能力"（太抽象，既测不出触发、也测不出指引力）。

**范式**：派一个 general-purpose subagent（让它只读 skill、把产出放进报告，不要改动仓库——除非任务就是要它落地文件），prompt 写「读取 `skills/<name>/SKILL.md`，然后按其指引处理这个需求：<测试 prompt>。完成后报告：你走了哪些步骤、产出什么、哪里卡壳」。多个 prompt 可以并行派。

**通过标准**：subagent 的产出 (a) 解决了用户问题，且 (b) 遵循 skill 的设计意图。把该 skill 正文里"该走的流程""该遵循的约定"抽成几条可勾选项来核（如 description 没写工作流、正文解释了 why、例子覆盖核心场景）。**跑偏长这样**：该走五步的跳过了验证、该三段式的 description 写成了能力清单、该按维度系统的退化成逐条枚举——出现这些就改正文重跑。

**把用例固化下来**：把这几个 prompt + 预期结果写进 `skills/<name>/evals/evals.json`（格式：`{skill_name, evals: [{id, prompt, expected}]}`）。evals.json 是验证的"存档"（记录测过什么、预期什么），subagent 实跑是"当下执行"。两者配合时注意时序：prompt 可以先定，但 `expected` 往往要跑一轮、看到实际产出才写得准——所以实操是「粗定 prompt → 跑 → 用实际产出校准 expected → 固化」，而不是单向的"先写完 evals.json 再跑"。

### 第 5 步：迭代

输出不对就改正文，重跑。重点改：
- 触发不准 → 改 description（补关键词、加症状）
- 做错了 → 正文讲清 why 或加常见错误
- 啰嗦/跑偏 → 删冗余
- **正文流程漏了关键步骤 → 补步骤**（这种问题几乎只能靠验证暴露，是迭代里最高频也最有价值的产出）

## 常见错误

| 问题 | 修法 |
|------|------|
| description 写了工作流（→ Claude 只读 description 跳过正文） | description 只留触发条件 |
| 正文超 500 行没拆（→ 加载慢、难维护） | 大段参考拆到 `references/` |
| 堆 MUST 不讲 why（→ 死板、难泛化） | 解释原因 |
| 一个例子写多语言（→ 平庸、难维护） | 一个优秀例子 |
| name 用下划线/驼峰 | 全小写连字符 |