一个15岁的人写了四个 Claude Code skill，力气几乎全花在写说明书上

Claude Code 的 skill，说白了就是把一段指令（有时附带脚本）打包进项目，模型在需要时自己读取执行。多数人写 skill 会把心思放在代码上，Reddit 用户 Dusk_isthetuffest 恰好反过来：四个 skill，代码没占多少时间，绝大部分精力用在写指令上。他顺带提了一句，自己 15 岁。

四个 skill 分别是代码优化、硬件感知配置、网络延迟排查、后端分析。仓库用 MIT 协议开源：https://github.com/hrmnisthetuffest/ultra-optimizer

他总结了五条，写长 system prompt 的人同样能用：

一、写清楚绝对不能做什么，别只写应该做什么。 每个命令都配一份 never touches 清单，比如不碰 BIOS、驱动、路由器、DNS 设置。skill 有权限执行命令，边界含糊，模型就可能顺手改掉系统配置。

二、每个 skill 自包含。 skill 之间互相引用，单独安装一个就断了。

三、小心 skill 正文里的替换。 skill 文本会做参数替换，还有反引号的 shell 匹配模式。措辞随便一点，写下的句子可能变成真正执行的命令。这条大概最容易被忽略：你以为在写文档，这套文档却会被当作代码处理。

四、让模型报告自己没验证的东西。 没实际跑过的 eval、没测过的安装脚本，都老实写在仓库里，不装作验证过。

五、用脚本检查结构。 这不证明行为正确，但能快速抓出坏链接和 frontmatter 错误。

最后他反问社区：怎么测试一个 prompt 的边界真的守得住？

这个问题目前没有标准答案。结构脚本只能查语法，行为层面得靠对抗性用例一条条试。有人建议把边界写成可执行的断言，有人干脆每次改 prompt 就重跑一遍红队测试。他的做法更像一种承认：写指令真正费劲的地方，是划清哪里不能碰。模型会不会照着做，是另一回事。