直接回答我把 Prompt 做成 Skill，是为了把重复判断从聊天记录里拿出来，变成一个来源清楚、可以安装、可以运行、可以检查，也允许别人修改的工作单元。
最近整理自己写过的 Skill 时，我先碰到的不是技术问题，而是一个很现实的问题：这些东西如果一直留在本机，价值基本只体现在我下次少返工。可如果只是把 SKILL.md 上传到 GitHub，再写一句“欢迎使用”，我自己也不会觉得它已经准备好让别人用了。
我写 Skill 的起点通常很具体。某类任务反复出现，我已经踩过几次坑，也逐渐知道哪些地方必须卡住，哪些判断可以交给模型。它一开始可能只是一段 Prompt，后来会多出参考文件、检查脚本和可复用资产。真正有用的部分，往往已经不在那段 Prompt 里。
所以我选了 interactive-html-demo 做第一个公开版本。它的目标很窄：把线性的说明变成一个可以点击、可以恢复、可以在浏览器里直接演示的单文件 HTML。这个 Skill 已经有实际成品，也比较容易验证“能不能用”，很适合拿来建立第一套发布标准。
一段有效的 Prompt，还不是一个可以交付的 Skill
Prompt 主要负责告诉模型这次怎么做。Skill 要处理的是下一次、另一个环境，甚至另一个人来使用时，哪些规则仍然成立。
两者之间少的不是更多文字，而是运行边界。
| 只保存 Prompt | 做成可发布的 Skill |
|---|---|
| 依赖当时的聊天上下文 | 说明什么时候应该触发、什么时候不该触发 |
| 告诉模型生成什么 | 同时给出输入、步骤、产物和失败路径 |
| 输出看起来完整 | 有脚本或浏览器路径检查实际结果 |
| 默认作者记得历史 | 把来源、改造关系和许可证写进仓库 |
| 出错后再解释 | 预先标出模拟能力、已知限制和恢复方式 |
这也是我后来最在意的一点：不要把应该由结构承担的事情，继续塞回 Prompt 里。Prompt 越来越长，常常只是因为系统没有地方保存状态、检查结果和责任边界。
我实际放进了这个包里的东西
第一个版本没有做成复杂框架。目录里只有解决发布问题所需的几类文件：
interactive-html-demo/
├── SKILL.md
├── agents/openai.yaml
├── assets/single-file-starter.html
├── references/acceptance-checklist.md
├── scripts/validate_interactive_html.mjs
├── PROVENANCE.md
└── RELEASE.mdSKILL.md 负责工作流和边界。Starter 是真正可以打开的单文件成品。Validator 检查容易遗漏的结构问题，验收清单则保留必须在浏览器里确认的部分。来源声明和 Release 记录解决另一个问题：以后回头看时，我不需要再猜这个版本是谁写的、参考过什么、当时通过了哪些检查。
OpenAI 的 Skills 文档把 Skill 定义为包含指令、资源和可选脚本的文件夹。这个结构对我很有用，因为它没有要求所有判断都挤在一个文件里。需要按条件读取的细节可以放在 reference，确定性的检查可以留给脚本。
为什么第一个成品是单文件 HTML
我经常需要把复杂流程、产品想法或报告讲给别人看。静态文档可以解释结构，但很多判断只有点过一次才会变得清楚：按钮按下后发生什么，状态有没有变化，失败了怎么回来，演示者能不能跳到关键页面。
单文件 HTML 在这里很实用。它容易传递，也不要求对方先安装一套项目环境。网络不稳定时，核心路径仍然可以运行。
但“可以点击”不等于“可以随便模拟”。这个 Starter 会明确写出 Interactive prototype · Simulated demo，也要求每次操作出现可见反馈。真正调用了后端、只是在前端演示，或者仍未验证，必须让观看者分得出来。
这类边界不性感，却很重要。一个演示最危险的情况不是做得不够漂亮，而是让人误以为它已经具备并不存在的能力。
我怎么判断它已经够资格公开
我先给发布设了一个很低调的标准：不证明它有多厉害，只证明这个版本交付了自己承诺的东西。
Validator 跑了 15 项静态检查，结果是 15 pass、0 warning、0 error。浏览器验收覆盖桌面、平板和手机，检查横向溢出、导航、状态变化、重试和最终路径。我还单独扫了本地路径、客户信息、旧用户名和占位内容。
这些数字不是下载量，也不是效果证明。它们只能说明结构完整，关键路径在约定环境里跑通过。至于它能否适合另一个人的工作，还要看真实使用反馈。
发布证据应该回答“我实际检查了什么”，而不是借几个数字制造受欢迎的感觉。
开源之前，先把来源说清楚
我现在手里有几类 Skill。有些从零开始写，有些基于开源项目适配，还有一些来自公开资料的重新组织。它们不能都贴上“原创”标签。
所以 HEADFIRST 只使用三种来源标记：
HEADFIRST ORIGINAL：从自己的问题、规则和实现开始构建。OPEN-SOURCE ADAPTATION：明确保留上游项目、许可证和改造说明。REFERENCE-BASED REBUILD：参考过公开方法，但重新设计了结构、文案和实现；发布前仍要做来源核查。
这套标记不是为了显得严谨。它直接决定一个 Skill 能不能公开、要保留什么，以及我可以对哪部分负责。如果来源还说不清，我宁愿先不发。
interactive-html-demo 的首版标记为 HEADFIRST ORIGINAL，使用 MIT License。其他 Skill 会逐个审计，不会把本地目录一次性倒进公开仓库。
网站、文章和 GitHub 分别解决什么
我最后没有只建一个 GitHub 仓库。
GitHub 放完整源码、许可证和发布记录。Skill 详情页让第一次看到它的人先理解用途，直接操作真实 Starter，再决定要不要安装。这篇文章保留制作过程，包括我为什么这样拆、在哪里停下来检查，以及哪些判断以后还能复用。
三个入口指向同一个东西，但承担的任务不同。这样做会多一点维护成本，不过比把背景、使用说明和源码塞在一个 README 里更容易读。
我接下来不会一次性公开所有 Skill
第一个版本先解决一个完整闭环：有人看到文章，能理解为什么需要它；进入详情页，可以亲手试；到了 GitHub，能检查来源、安装并修改。
如果这个路径本身走不通，继续增加 Skill 数量只会增加维护工作。所以下一步不是批量搬运，而是先看真实反馈：别人卡在理解、安装还是使用，哪些检查确实帮到了他们，哪些内容只是我自己熟悉所以误以为很清楚。
等这个闭环跑顺，再决定第二个公开什么。到那时，选择标准也很简单：来源说得清，能交付实际资产，有办法验证，并且确实解决了一个会重复出现的问题。
公开说明这篇文章来自真实工作。客户信息、数据和未公开的实现细节已经移除。