---

name: skill-author description: 当用户想创建一个新技能时使用——用户描述想要的能力（说"帮我写个技能/创建一个 skill/生成 SKILL.md/做个 XX 技能"），本技能引导生成规范的 SKILL.md（name、description、正文指令）。若要交付成可上传插件包，可继续按「插件包标准化」规则补 plugin.json/图标、导出标准包，最后询问用户是否安装。

技能创建（skill-author）

把用户的一句描述，变成一个可用的技能（SKILL.md 目录）。规范与「插件包标准化」 （package-author）同源；本技能只管「从描述到 SKILL.md」，打包交给 package-author 的规则。

何时用 / 何时不用

• ✅ 用：用户说"写个技能 / 创建 skill / 生成 SKILL.md / 做个 XX 技能"，或描述了一个 想要的能力但还没有技能文件。
• ❌ 不用：用户已有技能文件、只是要打包/标准化 → 走「插件包标准化」；或只是写普通 脚本/网页（非技能）；或要装/卸/开关某个已存在的工具。

先问清（问清再动手，别猜）

1. 技能做什么：一句话说清能力边界（不要贪多，一个技能干一件事）。
2. 何时触发：用户在什么场景/说什么话时该用这个技能？
3. 现成素材：有没有要一起打包的脚本、命令、资料、模板？
4. 命名：技能名（英文 kebab-case，语义化小写，如 git-commit-helper）。

用户没给全时，先补问；用户说"你看着办"才自行定，并在产出里说明可改。

生成 SKILL.md

frontmatter（必填两项）：

---
name: <name>                 # [a-zA-Z0-9_-]{1,64}，语义化小写 kebab-case
description: <做什么 + 何时用>  # 模型触发它的依据，一句话写清楚
---

正文（给模型看的指令），按需包含：

• 目标：这个技能要达成什么。
• 步骤/流程：明确、可执行的步骤（1/2/3…）。
• 红线：绝不能做的事（编造 ID/凭据、越界调用等）。
• 示例：一两个典型输入→输出。

硬规则：

• name 建议 ASCII 小写 kebab-case；导入校验实际允许 [a-zA-Z0-9_-]{1,64}（含大写），禁 ./../路径分隔符/空格。
• description 必须讲清「做什么 + 何时用」，别只写"一个有用的技能"。
• 参考资料放 references/*.md，正文只列目录（渐进披露）；别把大段内容全塞进正文。
• 技能要自包含：指令里写清依赖、前置条件、失败处理。

落盘：写 skills/<name>/SKILL.md（相对工作目录），并列出文件清单。

可选：导出标准包（结合「插件包标准化」）

用户要"能上传/能安装/给我一个包"时，按 package-author 的规则补齐：

1. 目录：<id>/skills/<name>/SKILL.md（+ 可选 references/）。
2. plugin.json：manifest_version:1、id 全小写、components.skills:[{id:<name>, dir:"skills/<name>"}]。
3. 图标：生成一个简约 icon.svg（24×24 几何、stroke="currentColor"、无外链/脚本）。
4. 校验命名与布局 → 产出 <id>/ 目录或 <id>.zip（zip 根就是 plugin.json，别多套一层）。

收尾：询问是否安装

• 生成（或导出）完成后，主动问用户："已生成 XXX 技能，要安装吗？"
• 说明安装方式：把 <id>.zip 拖进插件中心上传，或到商店「技能」区点安装。
• 安装/上传成功后的默认开关随会话模式而异：普通会话默认启用；代码（code）会话默认停用，需用户在工具/技能开关中手动启用。
• 不要擅自安装/上传，等用户确认；用户说"装"再给下一步指引。

校验清单（交活前逐条过）

1. SKILL.md frontmatter 有 name + description，name 合法（[a-zA-Z0-9_-]{1,64}，建议小写 kebab-case）。
2. 正文有可执行步骤 + 红线（若有）。
3. （若导出）plugin.json 齐、目录布局对、有 icon.svg。
4. 已询问用户是否安装，未擅自操作。