用途
GitHub Ops 是一个 GitHub 远程操作技能，负责所有通过 gh CLI 与 api.github.com 对话的工作：仓库创建、元数据配置、版本发布，以及 0xDarkMatter 仓库在 GitHub 上的呈现约定。
它与其他两个技能并列协作：git-ops 负责本地 git 操作，push-preflight 负责推送前预检，github-ops 负责 GitHub 侧。
主要能力与硬性规则
- 可见性默认 private。除非用户明确表示要公开某个具体仓库，创建时都传 --private。
- 主版本号提升需要明确批准。默认 minor；仅修复时用 patch；从不根据 BREAKING CHANGE 标记自动建议 1.0.0，而是提出并询问。
- 任何推送前都运行 push-preflight，无例外。若预检拒绝，则停止、修复并重跑。
- 本地 git 操作委托给 git-ops，不重新实现 commit/tag/push 逻辑。
- 每次发布都更新 README 的“Recent Updates”。
- 创建仓库时把可见性作为可翻转的一行显示，而非埋在参数里。
- 提交内容中不得出现本地机器路径，须使用通用占位符或规范路径。
- 任何带作者声音、发布到第三方面板的内容（issue/PR 正文、评论、发布说明、合并提交信息）都必须在对话中逐字引用、指名发送命令，并等待明确批准后才能执行。无正文的机械动作（打标签、指派、里程碑、标记 ready、无消息关闭）跳过预览。
三种模式
Mode new — 仓库首次发布：触发词包括“publish to github”“create repo on github”等。流程为：审计（LICENSE、README、包元数据、tag、CHANGELOG）；起草/完善 README 简介；构建落地页层（先选 Showcase 或 Reference 版式并显式告知用户）；添加“Recent Updates”章节；向用户展示发布方案并等待确认；用 gh repo create 创建仓库（绝不传 --push）；运行 push-preflight；推送 main 与 tags；用 gh repo edit 设置 topics；用 gh release create 创建发布；最后验证并报告 URL。
Mode update — 后续发布：触发词包括“ship a release”“cut a release”等。流程为：审计自上次发布以来的提交并按 Conventional Commits 分类；确定版本号提升（feat 为 minor，仅 fix/chore/docs/perf/style/test 为 patch，BREAKING CHANGE 则停止询问）；更新 CHANGELOG.md；更新 README“Recent Updates”；通过 git-ops 提交；创建本地 tag；运行 push-preflight；推送提交与 tag；用 gh release create 创建发布；验证并报告 URL。
Mode audit — 只读检查清单：触发词包括“audit github repo”“is this repo ready to publish”等。先运行 scripts/repo-scorecard.sh 得到每仓库 0–100 分及前 3 项修复建议（严格只读）。清单涵盖本地文件检查（LICENSE、README 要素、简介字数、Recent Updates）、落地页检查（这些为 WARN 级，永不硬性失败，需先推断 README 版式再据此判断）以及 GitHub 状态与安全态势检查（描述、主页、topics、分支、发布、安全）。输出为逐行 pass/fail/warn、总分与修复列表，建议但不自动应用。
操作
原子级 GitHub 侧操作，适用于不属于上述三种多步模式的动作。写入作者声音到第三方面板的操作受预览门控；机械动作跳过预览。
Issues：读取无需预览；创建、评论、编辑标题/正文、关闭评论受预览门控；打标签、指派、里程碑、关闭/重开、转移为机械动作。
Pull Requests：读取无需预览；创建、评论、审查、编辑标题/正文受预览门控；标签、审查者、标记 ready 为机械动作。合并需要用户明确批准并先过合并前门控。PR 创建属于本技能而非 git-ops。
合并前门控——调用 gh pr merge 前必须确认：
- gh pr view 确认 mergeable 为 MERGEABLE、mergeStateStatus 为 CLEAN
- gh pr checks 所有检查通过（或经用户批准显式忽略）
- 审查 gh pr diff，确认无意外范围、无提交的密钥或本地路径、无过时 PR 正文声明
- 选定合并策略：默认对含多个 WIP 提交的 fix/feature 分支用 squash；仅当单个提交重要时用 --merge；线性历史仓库用 --rebase。不确定则询问。
- 删除分支是单独的显式步骤，不捆绑。默认保留分支，仅在用户明确同意后删除远程与本地分支。
强制约定（详见引用文件）
默认：feat 为 minor、仅 fix 为 patch、major 需批准；README 简介 2–3 段具体文字；落地页先定版式、绝不混用；Recent Updates 按版本分块；除非要求公开否则 --private；issue/PR 正文受预览门控；默认 squash；分支删除单独一步。
适用场景与限制
该技能适用于在 GitHub 上创建仓库、发布版本、管理 issue 与 PR、审计仓库健康度，以及撰写 README 落地页的场景。它存在若干限制：可见性默认私有而非公开；主版本号不会自动提升；推送必须通过预检；所有面向第三方的作者声音内容必须经预览批准；不涵盖本地 git 操作（委托给 git-ops）和推送前预检（委托给 push-preflight）；Actions、secrets、分支保护写入等扩展功能尚未构建。
文档未提供具体的收费、价格或平台要求等信息。