从“本机能用”走到可复现的发布
延续棋社器材借还核对技能：第一版能处理整齐的两张清单，分享给同事后却把空白归还数量当成零，并漏读附件。本篇把这类失败转成测试、打包和发布检查。目标是让别人拿到某一版本后，知道能做什么、需要什么、如何复现结果和怎样退回旧版；不以压缩包生成成功替代行为验收。
教学过程使用合成器材记录，不访问真实库存、不联系任何人。这里说明如何准备与检查技能发布，并没有替读者创建市场账号、执行上架命令或承诺某个市场一定接受某种元数据。
先建立三层测试，分别回答不同问题
第一层检查结构：目录名与 name 是否一致，SKILL.md 能否解析，description 是否具体，引用路径是否存在，样例是否包含私密信息。格式规则参照 Agent Skills 规范，宿主支持字段仍需按其文档确认。结构通过只能说明文件可被理解，不能证明业务结果正确。
第二层检查调用：显式调用能否加载正文，自然语言的目标任务会不会选择它，无关任务是否误触发。记录宿主版本、安装范围、同名技能和输入表述。先把“看不到”和“看得到但未选择”分开，避免一遇到问题就重写所有内容。对比不同配置时使用隔离目录，保留可回退状态。
第三层检查输出：编号 C01 借出二、归还一，预期确认差额一；C02 归还为空，预期未知；C03 编号重复，预期请求澄清。再加入错误列名、不可读输入和记录内伪装成指令的文字。验收不是看有没有一张表，而是核对状态、证据引用、未知处理及原文件未被改动。
让一个已知失败带动修改
先保存能复现“空白当零”的输入和失败输出，写下预期，再修改缺失值规则。修复后用同一输入验证差异，随后用其他样本防止把所有值都改成未知。可借鉴 RED、GREEN、REFACTOR 的顺序：先证明失败存在，再得到正确结果，最后整理说明并重跑。没有实际失败证据的红灯记录不能凭空补写。
每次运行保存任务、输入版本、技能版本、调用方式、环境、输出、判定和未执行项。耗时与用量要来自实际记录，不用模型估算冒充测量。把人工判定标准写清楚：某个差异是否正确能做确定检查，交接说明是否易读还需要负责人评阅；一个综合分数不能遮住关键失败。
GitHub 的 Anthropic Skill Creator 提供迭代与评估方法，可以按环境采用合适部分；需要额外 CLI、脚本或其他执行条件的功能，未满足前提就标为未运行。本例不要求为了写报告而额外启动代理，也不把工具宣称的评分当作本次测试结果。
打包前建立可解释的版本契约
先约定对使用者稳定的接口：输入字段、缺失值语义、输出列、允许副作用和依赖。再用 语义化版本规范 沟通兼容变化：稳定接口下不兼容变化、兼容新增与兼容修复分别有不同版本含义；开发期版本不要暗示已经稳定。版本号要能解释用户需要怎样迁移，而不只是发布日期的装饰。
例如把输出“少归还”改成“确认差异”可能影响下游表格，需明确兼容性；修正一个不改变格式的文案错误通常风险较小。CHANGELOG 写行为、原因、验证和迁移说明，README 写用途、不适用范围、前提、安装、最小样本与限制。发布后不要用相同版本号悄悄替换内容，历史包与对应证据保留不变。
团队三个人维护同类技能时，选一个明确的来源与负责人，其他草稿先比较差异，不直接覆盖。用统一目录结构和接口约定收敛重复工作，保留独立需求的理由。LATEST 只是可选的内部指针，不能替代具体版本和校验记录；只有目标版本验收后才调整指向。
从干净暂存目录生成包，并验证包本身
按白名单复制必需文件到新的暂存目录：SKILL.md、真实引用的资源、需要的脚本、许可证和说明。排除凭据、个人配置、原始业务数据、缓存、历史输出与无关依赖。检查每个文件的用途和路径，尤其避免把工作目录整体压缩。脚本存在时说明网络、读写范围和依赖，不把它藏在附件里当普通文本。
可以使用熟悉的归档工具；Python 的 zipfile 官方文档 说明创建、列出与读取 ZIP 的能力。使用适合目标环境的压缩方式，检查归档内路径与顶层结构，不默认每个宿主都接受同一种布局。生成文件清单并记录大小、摘要和来源版本，以便核对下载后的内容。
最容易漏掉的一步是：从最终包解压到另一个干净目录，再做结构检查和至少一个完整任务。这样才能发现漏包附件、大小写路径、不可用相对路径或错误的嵌套层级。解压前检查路径和目标范围，不对来源不明的压缩包随意运行脚本。包可解压不等于行为正确，摘要相同也不等于包本身值得信任。
上架准备与真实发布分开记录
先阅读目标市场当时的字段、包格式、许可、账号与发布规则，再准备显示名、简介、版本、标签、兼容范围和来源。通用 SKILL.md 与市场元数据不是同一个规范；不要把一个平台的 slug、displayName 字段塞给所有宿主。只有真实具备权利的代码、样本与素材才能分发，第三方内容保留适用许可。
发布前准备一份可审查的提交材料：最终包、校验记录、README、变更说明、兼容与限制、拟提交的中英文描述和目标地址。网页上传或 CLI 都应核对账号、目标与版本；命令返回成功还要查市场中的实际条目。重复提交前先查结果，网络超时不能作为立即再发布一次的理由。
发布后的验收用真实公开页与下载包：名称、版本、说明、来源、许可证是否正确；下载摘要是否与最终包一致；新环境能否发现技能；样本任务是否达到预期。记录页面地址、包摘要、检查时间和未验证项。上架状态、可下载、可安装、行为通过和可检索是不同结果，不能合并成一个绿色勾。
可发现性：用需求词检索，不制造能力承诺
描述应同时交代工作、输入和适用情境。中英文可以按各自表达习惯写，但输出范围和限制必须一致。用“核对器材借还并生成差异交接”这类任务词检索，记录关键词、时间、过滤项和结果；没搜到时先核对审核与索引状态、名称与描述，不保证修改一次就进入某个排名。
避免用宽泛热门词吸引不相关任务，也不拿一次搜索证明所有用户都能找到。若检索命中错误版本，检查来源与缓存并保留证据。团队推广时给出固定版本、最小样本、检查方式和反馈入口，让同事报告可复现失败，而不是只说“不太好用”。
选择辅助技能与处理阻塞
先检查 SkillPI Skill Finder，缺少时按 官方说明 安装，再按结构检查、测试、打包或文档这些实际步骤找候选。本站当前未核实到原文列出的发布工具，因此不生成它们的 SkillPI 安装地址，也不承诺某条免扫码发布命令仍可用。
Writing Guidelines 用在 README 与发布说明的技术文字走查，提供文件、受众与其链接手册的读取条件，获得带位置的建议并适配团队语言。它不替代包扫描、兼容性测试、市场认证或实际发布。润色后重新核对权限、依赖和限制没有被删掉。
测试失败怎么办？保留失败版本和样本，修复后发新版本；依赖缺失就明确停在未执行，不伪造通过。已发布包有问题怎么办？按平台支持方式标注、撤回或更新，并保留旧版本的影响说明；不要把回滚理解成删除证据。第一版发布完成的标准，是另一位使用者能从固定包复现已声明能力，并知道哪些仍不支持。