version: "1.0.0" name: improve-skills description: 改进技能：按用户的一句想法、整理要求或出厂更新，找到该改的技能和位置，在草稿里改好，交给用户确认。工作台在后台调用，参数里带改动 id、方式和草稿目录。

改进技能

参数里有 改动 id、方式（想法 / 合并出厂更新 / 整理）和 草稿目录。草稿目录是全部技能的一份副本，结构和 .claude/skills/ 一样（每个技能一个文件夹）。技能只改草稿目录里的文件，不要动 .claude/skills/ 和工作台的其他文件（想法里顺带要装别人的技能、建系列的，见下面「想法」）。改完平台会对比草稿和现在的技能，生成一张「技能改动」卡片给用户看。

技能是怎么组织的

• 每个技能一个文件夹，SKILL.md 是入口：开头的 description 是简介（Claude 靠它决定用不用这个技能），正文写步骤；细节放同目录的其他文件（references/*.md、做法的 research.md / script.md / video.md / revise.md），正文里写明什么时候读哪个；程序放 scripts/。
• 三类，格式一样，只是用途不同（SKILL.md 开头的 metadata.kind 标着）：
• 流程（没标）：一个环节的通用步骤，比如 research-topic、write-script、make-video、revise-video。
• 做法（kind: craft）：一种内容各环节具体怎么做，比如 stage-montage（原片剪辑）、explainer-video（解说视频）。
• 工具（kind: tool）：多处会用的程序怎么用，比如 voice-over（配音）、transcribe（语音转文字）。
• 放哪里的判断：只有一种做法用的，放进那个做法；几种做法都用的，放流程技能或工具技能；是程序，放进所属技能的 scripts/。
• 每次运行都能读到任何技能的任何文件。别的技能里已经写好的东西，写一句「按 xx 技能的 yy 文件」引用就行，不要抄一份，抄了以后改格式就得几处同步。
• 用户的资料（账号、系列设定、音色）、密钥和登录不写进技能。某个系列特有的要求（比如某个词怎么念）写在系列设定里，不写进技能。

按方式做

想法

用户在总控台或技能页说了一句想改的。先弄清这句话要的效果，再找该改的地方：读相关技能的简介和正文，搜关键字（grep -rn 草稿目录），一个想法可能要改好几个技能（比如「所有视频加水印」：生成视频的流程要加一步，各做法里可能还要各补一句避让）。

• 能用技能做到的，就在草稿里改：说明改在最合适的那一层；要新程序就写进对应技能的 scripts/，能跑的先跑一下确认（用命令行，在草稿目录里跑，不要改到别处）；需要一个全新的技能就在草稿目录里新建文件夹。
• 要靠工作台新功能才做得到的（比如设置页加一个新开关、平台多存一种数据），技能里能做的部分照做，做不到的部分在汇报里写清楚「这部分需要平台加功能：……」。
• 想法里顺带要的、不是改技能的事，直接做，做完写进汇报：
• 装别人的技能：npx skills add <GitHub 仓库> -g -a claude-code -y，装进 ~/.claude/skills/（和 hyperframes 这些一样，所有运行都能用），不放进草稿目录。仓库大、克隆超时就先 git clone --depth 1 到 data/programs/ 下，再 npx skills add <本地路径> -g -a claude-code -y。装好读一遍它的 SKILL.md，按里面的要求把依赖装好。自己的技能里要用它，写「按 /技能名」引用，不要把它的内容抄进来。
• 建系列、改系列：用 save_series（账号和系列是平台数据，不是技能）。
• 想法和现有规则冲突时，按想法改，把被替换的旧规则删掉，不要两条并存。
• 想法是「新建一个技能：……」时：先看现有技能里有没有已经能做这件事的，有就改它，并在汇报里说明为什么没有新建。确实要新建的，先定它是流程、做法还是工具，起一个小写加连字符的英文名，在草稿目录里建文件夹：SKILL.md 开头写 name、description（做法以「做法：」开头、工具以「工具：」开头，写清做什么、什么时候用），做法和工具加 metadata: 下的 kind: craft 或 kind: tool。做法按环节分文件（research.md、script.md、video.md、revise.md，只写和通用流程不一样的环节），SKILL.md 里列清哪个环节读哪个文件；要程序就写进 scripts/ 并试跑。

合并出厂更新

参数里有三个目录：旧出厂版、新出厂版、草稿（用户现在的版本，可能被用户或 Claude 改过）。把新出厂版相对旧出厂版的改动合进草稿：

• 出厂改的地方用户没动过：照出厂的改。
• 用户（或之前的改进）改过、出厂没动：保留用户的。
• 两边改了同一处：理解两边各自的目的，写成同时满足两边的版本；真的只能二选一的，保留用户的，在汇报里写明「出厂这次想改……，和你的……冲突，保留了你的」。
• 出厂新加的文件照加，出厂删掉的文件用户没改过就删。

整理

把技能越改越乱的地方理顺，不改变它们的意思：

• 同一主题写在几处的合并成一处；前后矛盾的按较新的改法统一；过时的删掉。
• SKILL.md 超过 300 行的，把细节挪进附录文件，正文留步骤和「什么时候读哪个附录」。
• 简介要写清「做什么、什么时候用」，做法和工具的简介以「做法：」「工具：」开头。
• 只整理，不加新规则；拿不准是不是过时的就留着。

改的原则

• 改，不要只往后追加：相同主题合并，过时的删掉，SKILL.md 保持简短，细节放附录。
• 保持原来的写法：中文、直白、写「怎么做」，不写空话。
• 不改和这次无关的地方。

汇报

自己在前台把事情做完，不要开后台任务或后台子代理（它们结束时的回复会盖掉你的说明）。最后的回复就是给用户看的说明，两到六行：这次改了哪些技能的哪里、为什么这么改；有没有需要平台加功能的部分；用户需要特别看一眼的地方。不要贴改动全文，平台会显示逐行对比。