القائمة
在 Lion-Skills 仓库创建或修改 skill 时。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
需求模糊、含隐藏假设或 X-Y problem，需先澄清再动手时。
审查代码（自己的或别人的），需有重点、分层次地看时。
Git 改动需编写规范提交信息时。
遇到 bug、报错、崩溃或行为异常，需定位根因时。
设计或改进错误处理与日志时。
为代码标识符（变量/函数/类/文件/API/数据库字段）决定名字时。
| name | lion-writing-skills |
| description | 在 Lion-Skills 仓库创建或修改 skill 时。 |
Lion-Skills 的"造 skill 流水线"：按本仓库规范，把一个重复的工作流沉淀成可复制、经验证的 skill。
核心原则：skill 是给未来 Claude 读的"操作手册"——它的价值不在于你写了什么，而在于未来的 Claude 在触发它时，能照着做出正确的事。
不该做成 skill 的情况：一次性的、项目特定的约定（放 CLAUDE.md）、能用简单校验自动化的（写成校验脚本而不是文档）。
只是审查/优化现有 skill 时：直接对照下文相关规则做合规判断即可，不必每次重走第 1 步"值不值得做"四问——那是新增 skill 的决策；现有 skill 要不要继续存在，是另一个问题。
回答四个问题（都"是"才值得做）：
任何一个答"否"，就别做成独立 skill：项目特定的约定放 CLAUDE.md，能机械自动化的写成校验脚本，一次性的直接在对话里处理。
新 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 跳过正文。把流程留给正文。
按这个骨架：概述 / 何时使用 / 核心内容 / 常见错误（参考 template/SKILL.md）。
写作约定：
references/前置：先确认目标 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 再跑"。
输出不对就改正文，重跑。重点改：
| 问题 | 修法 |
|---|---|
| description 写了工作流（→ Claude 只读 description 跳过正文） | description 只留触发条件 |
| 正文超 500 行没拆（→ 加载慢、难维护） | 大段参考拆到 references/ |
| 堆 MUST 不讲 why（→ 死板、难泛化） | 解释原因 |
| 一个例子写多语言（→ 平庸、难维护） | 一个优秀例子 |
| name 用下划线/驼峰 | 全小写连字符 |