技能创建（skill-author）
把用户的一句描述，变成一个可用的技能（SKILL.md 目录）。规范与「插件包标准化」
（package-author）同源；本技能只管「从描述到 SKILL.md」，打包交给 package-author 的规则。
何时用 / 何时不用
- ✅ 用：用户说"写个技能 / 创建 skill / 生成 SKILL.md / 做个 XX 技能"，或描述了一个 想要的能力但还没有技能文件。
- ❌ 不用：用户已有技能文件、只是要打包/标准化 → 走「插件包标准化」；或只是写普通 脚本/网页（非技能）；或要装/卸/开关某个已存在的工具。
先问清（问清再动手，别猜）
- 技能做什么：一句话说清能力边界（不要贪多，一个技能干一件事）。
- 何时触发：用户在什么场景/说什么话时该用这个技能？
- 现成素材：有没有要一起打包的脚本、命令、资料、模板？
- 命名：技能名（英文 kebab-case，语义化小写，如
git-commit-helper）。
用户没给全时，先补问；用户说"你看着办"才自行定，并在产出里说明可改。
生成 SKILL.md
frontmatter（必填两项）：
markdown--- 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 的规则补齐：
- 目录：
<id>/skills/<name>/SKILL.md（+ 可选references/）。 plugin.json：manifest_version:1、id全小写、components.skills:[{id:<name>, dir:"skills/<name>"}]。- 图标：生成一个简约
icon.svg（24×24 几何、stroke="currentColor"、无外链/脚本）。 - 校验命名与布局 → 产出
<id>/目录或<id>.zip（zip 根就是plugin.json，别多套一层）。
收尾：询问是否安装
- 生成（或导出）完成后，主动问用户："已生成 XXX 技能，要安装吗？"
- 说明安装方式：把
<id>.zip拖进插件中心上传，或到商店「技能」区点安装。 - 安装/上传成功后的默认开关随会话模式而异：普通会话默认启用；代码（code）会话默认停用，需用户在工具/技能开关中手动启用。
- 不要擅自安装/上传，等用户确认；用户说"装"再给下一步指引。
校验清单（交活前逐条过）
- SKILL.md frontmatter 有
name+description，name合法（[a-zA-Z0-9_-]{1,64}，建议小写 kebab-case）。 - 正文有可执行步骤 + 红线（若有）。
- （若导出）
plugin.json齐、目录布局对、有icon.svg。 - 已询问用户是否安装，未擅自操作。
