publish-skill

技能：publish-skill

阶段 0：初始化并识别来源

必需输入

向用户收集：

1. 源技能路径：包含个人技能的目录（例如，~/.claude/skills/my-skill/ 或 ~/.agents/skills/my-skill/）
2. 目标包路径：可分发软件包所在的目录（例如，~/workspace/<your-package>/）
3. 目标许可证：软件包所采用的许可证——询问用户；可推荐 MIT 作为默认选项，切勿擅自假定

操作

1. 从源技能目录读取 SKILL.md
2. 递归盘点所有文件（ls -R）
3. 对技能类型进行分类：
   • 独立型：自包含的技能，不涉及 Agent 委派
   • 编排型：将任务委派给子 Agent（未经重构不适合分发）
   • 包装型：对其他工具/API 的轻量封装
4. 向用户展示清单表格：

| File | Lines | Type | Notes |
|------|-------|------|-------|

后续所有修正都在工作副本（下文的 <cleaned_skill_path>）或目标目录中进行。 切勿直接修改源技能，因为它是用户正在使用的原始版本。

关卡：继续前，须由用户确认源技能和目标软件包。

---

阶段 0.5：技能价值关卡

在投入精力进行个人身份信息（PII）清理和通用化之前，先确认这套工作流是否值得作为技能分发。依次通过以下三个关卡：

关卡	问题	通过条件
独特性	有能力的用户能否通过约 5 分钟的网络搜索，或向未安装该技能的通用助手提问，获得相同结果？	不能
针对性	它是否编码了特定领域或重复任务专属的工作流、决策启发式、约束或惯例，而非通用代码片段或标准库示例？	是
投入	发现它是否需要实际的调试、研究设计、运维投入，或从审查预期中总结经验（例如陷阱、验证步骤或领域惯例）？	是

关卡：任一条件不通过（或反向条件为“是”），都应停止发布——建议改为文档或记忆笔记。如果技能确有价值，但委派给了私有 Agent，则转至阶段 1 对编排型技能的处理（先重构为独立型）。只有三个条件全部通过，才可继续。

---

阶段 1：原创性检查

检查项

1. 外部来源：此技能是否改编自其他软件包或作者的作品？检查归属声明标题、许可证条款或“基于……”注释。
2. 第三方内容：references/ 中是否有文件来自外部来源（已发布的指南、教科书、标准组织）？
3. 竞争敏感性：此技能是否揭示了应保密的专有业务逻辑或竞争优势？询问用户；切勿自行作出判断。

决策矩阵

发现	操作
完全原创	继续阶段 2
基于采用兼容许可证的内容改编	添加归属声明标题，然后继续
含有许可证不兼容的第三方内容	标记以便移除或转换为 URL 引用
引用了私有 Agent 的编排型技能	停止——需先重构为独立型
竞争性/专有逻辑	停止——不适合开源

---

阶段 2：PII 去标识审查

零容忍：继续前，技能中的 PII 匹配项必须恰好为 0 个。

预扫描设置

运行前，询问用户所有对其而言独有、也应计为 PII 命中的内容：

• 他们在所有语言中的姓名及罗马字拼写（占位符格式：<First Last>|<native-script name>）
• 他们的机构隶属关系（占位符格式：<Institution>|<Hospital>）
• 可能出现在草稿或文件名中的合作者姓氏

将这些输入合并为一个以竖线分隔的 grep -E 备选模式。

自动扫描

运行随附的审计脚本。第一个参数是技能目录；第二个参数是「扫描前设置」中的用户专属替换模式。

bash ${CLAUDE_SKILL_DIR}/scripts/audit_skill.sh --strict <source_skill_path> \
    "<First Last>|<native-script name>|<Institution>|<Hospital>"

该脚本会扫描以下十个类别，以及用户模式：

1. 硬编码路径（/Users/<name>/、/home/<name>/、~/Documents、~/Desktop、~/Downloads、~/Projects）
2. 电子邮件地址（任何符合地址格式的字符串）
3. IP 地址 / 内部 URL（*.internal、*.local、*.corp）
4. 机构引用（SNUH / AMC / SMC / KAIST / SNU / ASAN / MGH / UCSF / Mayo Clinic / Johns Hopkins / Samsung Medical / Severance / Asan Medical）
5. 带姓名的学术职位（professor <Surname>、Prof. <Surname>、Dr. <Surname>、PGY[0-9]、<한글이름> 교수님）
6. 语言硬编码（"in Korean"、"한국어로"、"in Japanese"、"in Chinese"）
7. 具体地点（Seoul / Busan / Daegu / Tokyo / Beijing / Shanghai / Boston / Stanford 及其韩语写法）
8. 带日期的引用块先例（> YYYY-MM-DD ... 格式的行，会暴露内部审查时间线）
9. 作者风格的文件名（<Surname>{Year}_* 模式，例如 <Surname>2025_<Journal>_Fig01.png；允许列表排除 Issue2024_、Sample2025_ 等通用标记）
10. 二进制 EXIF 元数据（DOCX / PPTX / XLSX / PDF / PNG / JPG / TIFF — 使用 exiftool 扫描主目录路径、电子邮件地址和用户模式，匹配时不区分大小写。如果存在二进制文件但未安装 exiftool，RESULT 行将显示 INCOMPLETE，且 --strict 将以状态码 3 退出）

退出码：0 表示无问题，1 表示发现问题，2 表示用法错误 / 用户正则表达式无效 / 扫描无法运行，3（仅限 --strict）表示检查无法运行。只有退出码 0 才表示扫描通过。

已知限制：韩语职位分支（第 5 项）要求带有敬称后缀 -nim。脚本不会捕获不带 -nim 的第三人称提及（韩语姓名后直接跟职位名称），因为要将此类提及与「指导教授」等职位描述区分开来，需要使用 grep -E 无法表达的停用词列表。请手动检查此类提及。

交叉验证

对于脚本标记的类别，还要使用 Grep 工具对照 ${CLAUDE_SKILL_DIR}/references/pii-patterns.md 手动验证。尤其要留意：

• 未包含在额外模式参数中的姓名（例如，只在一份早期草稿中出现过的共同作者）
• 特定领域的机构缩写（你的机构可能不在默认列表中）
• 项目专属标识符，例如 CK-NN、MA-NN 和带日期的队列名称

输出格式

将所有发现列入整改表格：

| # | File:Line | Category | Match | Suggested Fix |
|---|-----------|----------|-------|---------------|

关卡：由用户审查所有发现。在工作副本中逐一修复。重新审计工作副本。只有确认命中数为 0 时才继续。

---

第 3 阶段：通用化

语言

• 替换："in Korean" / "한국어로" / "Korean language" → "in the user's preferred language"
• 替换："communicate in [specific language]" → "Communicate with the user in their preferred language"
• 保留：metadata.triggers 字段（或目标包的对应字段）中的多语言触发关键词（这些关键词有助于发现）

职位

• 替换："radiology researcher" → "medical researcher"（如果该技能适用于通用领域）
• 替换："professor" / "fellow" → "researcher" 或 "user"（视上下文而定）
• 保留：定义技能范围的特定领域术语（例如，"diagnostic accuracy" 可以保留）

路径

• 替换：硬编码的绝对路径 → ${CLAUDE_SKILL_DIR}，用于捆绑的参考文件
• 替换：~/Documents/... → 用户提供的输出目录
• 保留：技能目录结构中的相对路径

环境

• 删除：关于特定操作系统（macOS、Linux）的假设
• 删除：关于特定编辑器或 IDE 的假设
• 删除：对个人基础设施（Agent、其他个人技能）的引用
• 保留：技能正文中描述的工具要求（前置条件部分）。架构中没有 tools: 字段，而 allowed-tools 是预先批准工具，而非用于描述工具，因此不要将要求移到那里

互操作性

• 检查：该技能是否按名称引用其他技能（例如“路由至 analyze-stats”）？
• 如果目标软件包中存在被引用的技能：保留该引用
• 如果目标软件包中不存在被引用的技能：将其设为可选，并提供备用指引

输出

展示所有通用化更改的统一差异，供用户审阅。

---

第 4 阶段：许可证兼容性检查

针对技能 references/ 和 scripts/ 目录中的每个文件：

1. 检查文件中的许可证标头或声明
2. 检查同一目录中的 LICENSE 文件
3. 如果文件包含来自已知标准（报告指南、临床评分等）的内容，识别其来源及许可证

使用 ${CLAUDE_SKILL_DIR}/references/license-compatibility-matrix.md（针对 MIT 目标编写；其中也列出了常见清单和软件包许可证）对每个文件进行分类。将兼容内容与所需的署名标头或许可证声明一并打包；将不兼容内容转换为矩阵中的 URL Reference Pattern；将 GPL/LGPL 工具标记为可选外部依赖；将未知许可证视为不兼容（删除或获取许可）。

输出

提供许可证审计表：

| File | Source | License | Compatible? | Action |
|------|--------|---------|------------|--------|

---

第 5 阶段：验证与测试

结构验证

1. YAML frontmatter：解析并验证必需字段（Agent Skills 规范中的 name 和 description，以及目标软件包自身验证器要求的任何字段）
2. 文件引用：每个 ${CLAUDE_SKILL_DIR}/... 路径都能解析为实际文件
3. 脚本可执行性：scripts/ 中的脚本具有适当的 shebang
4. 行数：SKILL.md 应少于 500 行，以便优化加载
5. 描述质量：描述应以动词开头，并包含触发关键词

最终 PII 复查

最后对清理后的技能运行一次 audit_skill.sh --strict。退出代码必须为 0。

跨平台适配器审查

检查该技能能否在常见的桌面 Agent 环境中运行：

平台	检查
Claude Code	除非有说明，否则不得硬编码依赖私有 ~/.claude 路径。
Codex	SKILL.md 是自包含的，并可安装到 ~/.agents/skills/ 下。
Cursor	简短的 .cursor/rules/*.mdc 适配器可以指向规范的 SKILL.md。
Windows	命令应避免仅适用于 Unix 的假设，或提供 PowerShell/Python 替代方案。
macOS/Linux	Shell 示例尽可能使用可移植路径。

如果软件包面向工作坊或课堂，请阅读 ${CLAUDE_SKILL_DIR}/references/classroom-distribution.md 并遵循其中的要求（直接下载 ZIP、发布资源、课堂清单）。

README 条目草案

生成一行与目标软件包 README 格式相符的表格条目：

| **{skill-name}** | {One-sentence description of what the skill does.} |

用户测试

请用户：

1. 将清理后的技能复制到测试位置：cp -r <cleaned_skill> ~/.claude/skills/<skill-name>
2. 重启 Claude Code
3. 输入 /<skill-name> 或相关触发短语，测试技能是否触发
4. 使用示例输入验证所有阶段能否端到端正常运行

关卡：用户确认测试已完成。

---

第 6 阶段：打包与提交

复制到目标软件包

cp -r <cleaned_skill_path> <target_package>/skills/<skill-name>/

更新 README

应用第 5 阶段拟定的 README 条目：

• 将条目添加到适当的表格（Available Now / Coming Soon）
• 如果该技能新增了一个阶段，则更新流程图
• 如果正文中提及技能数量，则更新数量

生成提交命令

展示准确的命令，但不要自动执行推送：

cd <target_package>
git add skills/<skill-name>/
git add README.md
git diff --cached   # User reviews
git commit -m "Add <skill-name>: <one-line description>"

门槛：用户检查 git diff --cached 并明确批准提交。推送始终由手动执行。

发布后

提醒用户：

• 如果适用，将该技能添加到各个市场列表中
• 从干净克隆测试安装：git clone <repo> && cp -r <repo>/skills/<skill-name> ~/.claude/skills/
• 如需用于课堂分发，请完成 references/classroom-distribution.md 中的发布步骤。