publish-repo 是一个把 Agent Skills 仓库发布到 skills.sh 生态的技能。该生态没有发布 API，所谓“部署”实际等于两步：把仓库变成公开且可安装，然后完成第一次安装，以此播种目录的遥测数据。这个技能的作用就是把这条序列变成有意识、可复现的流程，而不是临时操作。
使用方式与限制 该技能仅支持斜杠调用。原因是它会翻转仓库的可见性，而可见性一旦公开，在社交层面很难撤销——任何曾经被推送过的内容都会变得可见。因此流程中要求在切换可见性前立即向用户确认，并且技能不会自我认证这一步。
不适用场景
- 编写或修复技能，应使用 add-skill。
- 仓库的 skills/ 目录下没有任何技能，应先构建，绝不发布空目录。
- 向已经公开的仓库做日常推送，直接用普通 git 即可。
工作流程要点 发布前检查（硬性关卡，任一失败即停止）：工作树必须干净且已由所有者推送；该技能从不运行 git commit 或 git push，若存在未提交改动，应停止并把清单交给所有者。检查包括：git status --porcelain 必须为空、make check 必须以 0 error(s) 结束、npx skills add . --list 能发现 skills/ 下每个技能、gh skill publish --dry-run 做规范校验（要求 gh >= 2.90，公共预览）、以及校验 skills.sh.json 是合法 JSON。需要处理 gh skill 的每一条警告，例如补充缺失的 license: MIT frontmatter；.claude/skills/ 警告在此属预期情况（随仓库捆绑的第一方开发技能，按设计提交，并非第三方内容）。还需核对 README 目录、CHANGELOG 为最新、每个技能描述以收益为导向（它就是列表文案）、最新提交上 CI 为绿色。
手动阻塞项需用户明确确认，绝不假设：全历史密钥扫描（gitleaks/trufflehog）已完成；个人/私有文件审查已完成（所有曾被提交的内容都会公开）。若 $ARGUMENTS 中带 --dry-run，则停在此处并报告就绪状态。分组方面，需确保 skills.sh.json 中每个技能恰好归属一个分组，且每组有一句有吸引力的描述。
切换可见性（切换前立即与用户确认）：使用 gh repo edit 命令改为 public 并接受后果。保护措施在公开后解锁：通过 gh api 启用私有漏洞报告；添加默认分支 ruleset，单人维护者默认只阻止强制推送和删除（require-PR 规则会阻塞所有者的直接推送工作流），当有外部贡献者时升级为 require-PR 加代码所有者审查加校验检查；再对 v* 添加标签 ruleset（阻止更新与删除），使已发布版本不可变。
发布与验证 发布时切割与 .claude-plugin/plugin.json 匹配的版本化 GitHub release，该命令会重新校验、在缺失时补上 agent-skills 主题，并用自动生成说明创建 release；同时补加 skills-sh 主题。之后以消费者身份验证并播种目录（在本地运行，不要在 CI 中运行——CI 会禁用遥测，且首次真实安装才会让仓库被列出）：列出技能、在临时目录中安装全部技能到 claude-code，再列出已安装技能。收尾包括：README 携带 skills.sh 徽章、设置 homepage、提醒社交预览图（手动 UI 步骤）。最后报告仓库 URL、skills.sh 页面 URL、安装命令、发布标签、已应用的保护措施、被跳过的项目及其解锁条件，并说明 skills.sh 页面会在遥测处理完播种安装后出现（页面有缓存）。
输出规范与常见陷阱 期望输出：公开仓库可通过 npx skills add <owner>/<repo> 安装（经实际安装验证）、PVR 已启用、ruleset 生效、skills.sh.json 有效且每个技能已分组、已完成播种安装、并已明确告知用户接下来会发生什么。常见陷阱：可见性翻转是历史层面的不可逆点，因此要求明确确认；npx skills add . --list 报 “No skills found” 说明 frontmatter 或目录结构有问题，应依据 make check 输出修复而非盲目重构；排行榜/仓库页面滞后于播种安装，几分钟后仍未出现属正常，不代表失败；不要在直接向 main 推送的单人仓库上启用 require-PR ruleset，它会阻塞所有者，应使用分阶段的默认设置。