1实现原理 · 为什么它能做到
全篇第一原则：交付被请求的 GitHub 状态，而不是一条看起来成功的命令——2xx 只证明 GitHub 接受了请求，不证明字段真的改了、邀请被接受、异步任务完成或业务结果达成。
github-ops/SKILL.md
Deliver the requested GitHub state, not a successful-looking command.
注：后半段原文把它展开：'`202`, or `204` response is evidence that GitHub accepted a request; it is not proof'（续行 'that every requested field changed, an invitation was accepted, an asynchronous job'）。后续七步契约、四态结论与每个 reference 结尾的 Terminal evidence 都从这条推出。
SKILL.md 本体只是「硬契约 + 路由表」：按操作域把任务分派到 8 个 reference，并要求只读当前任务需要的那一份，避免一次性加载全部约 95KB 知识。
github-ops/SKILL.md
Read only the reference required for the task:
注：路由表 8 行把 PR / issue / 仓库 / 组织权限 / 分支保护 / Actions / 原始 REST-GraphQL / 自动化脚本分别指向 references/*.md。这是「薄主文件 + 分片知识库」架构：主文件约 10KB，装的是不可协商的契约与边界。
第 1 步先给请求分类（读-only / 具名状态变更 / 破坏性·公开·涉凭证·触发生产·对外沟通），分类决定授权范围与是否可以在写之前停下。
github-ops/SKILL.md
- **Answer, inspect, diagnose, or review:** read-only. Do not create a PR, issue,
注：原文续行：'comment, invitation, workflow run, or setting change.'。同一段还有硬约束：'Do not turn a read-only investigation into a mutation because the fix looks obvious.'——禁止把只读诊断自动升级成写操作；并禁止发送收件人或内容未经本任务授权的评论/审查/issue/邀请。
第 2 步在第一次写之前绑定身份、主机与目标：先验证活跃账号（--hostname HOST）再解析全限定目标，并对多 GitHub 实例强制显式 HOST。
github-ops/SKILL.md
gh auth status --hostname HOST
注：同段紧接 'gh api --hostname HOST user --jq '.login''；目标解析用 'gh repo view HOST/OWNER/REPO' 加 '--json nameWithOwner,visibility,isPrivate,viewerPermission,url'。要点是「取账号但不暴露 token」，并把 HOST 当作目标的一部分，企业实例不会被 github.com 默认值吞掉；向远端首次 push 前还要再读一次远端实时可见性。
第 3 步要求读 GitHub 托管态（而非过期的本地 ref 或记忆），并在有后果的写之前显式写出一份六行影响预览：Target / Current / Requested / Blast radius / Recovery / Readback。
github-ops/SKILL.md
Blast radius: people, repositories, forks, runs, or public surfaces affected
注：这六行是 code block 模板的收尾行，模板首行是 'Target: fully qualified repository, organization, PR, issue, run, or account'。同段同时禁止仪式性二次确认：'If the user already authorized this exact consequence, execute it. Do not add a'（续行 'ceremonial second confirmation.'）——授权到位就执行，授权含糊（target/scope/公开面/删除/收件人/恢复）才暂停。
第 4 步要求选「输入契约真的支持该变更」的接口，优先级固定为 gh 专用子命令 → 文档化 REST → GraphQL（仅 GraphQL 专用或需合并关联数据）→ 只有 UI 才有的设置；核心陷阱是「响应字段不等于可写字段」。
github-ops/SKILL.md
Response fields are not automatically writable fields. Before using `PATCH`, compare
注：比对对象是「该操作当前的请求体参数」而不是 GET 返回的形状（原文起句 'the desired key against the operation's current **request body parameters**, not the'），并点破静默 no-op 的成因：'shape returned by `GET`. GitHub may ignore an unsupported key while still returning a successful'。organization_access_and_settings.md 与 api_reference.md 的 UI-only 段落是它的落地案例。
第 5 步是幂等纪律：能 pin 的都 pin（仓库/编号/分支/run ID/用户名/预期 SHA），非幂等写在超时或 5xx 后先读回再决定是否重发。
github-ops/SKILL.md
- Do not blindly retry non-idempotent writes such as comments, invitations, workflow
注：续行：'dispatches, releases, or PR/issue creation. After a timeout or 5xx, read back first to'。批量场景同段规定：冻结并展示有限目标清单 → 一次一个 → 逐条结果，禁止把未审阅的实时查询直接塞进破坏性 xargs；并禁止绕过 hooks、required checks、分支保护、签名与可见性后果承认。
第 6 步用「不信任变更响应、也不信任缓存 ref」的新读取做验收，并给出按变更类型分行的验收证据表（PR 合并/分支删除/issue-评论-审查/仓库创建编辑可见性/协作者与团队权限/组织设置/2FA/workflow/secret）。
github-ops/SKILL.md
Run a fresh read that does not trust the mutation response or a cached local ref:
注：表里最尖锐的两行是本 skill 的差异化价值：'| Branch deletion | Hosted branch/ref is absent; local remote-tracking cleanup is a separate check |' 与 '| 2FA requirement | Preflight affected accounts, UI confirmation, API readback, then membership/outside-collaborator audit |'（后者在 organization_access_and_settings.md 展开为通知/补救/审计日志流程）。异步态要求有界轮询、未观测到终态就报 pending，且绝不从写入回执说 done。
第 7 步收口为四种诚实状态之一：changed and verified / already satisfied / pending / failed-no-op or partial，并要求失败态附恢复与未决风险。
github-ops/SKILL.md
- **changed and verified** — requested state is independently observed;
注：失败态原文：'- **failed/no-op or partial** — requested and observed states differ, with recovery and'；同段末句 'Never say “done” from the write' 接 'receipt alone.'。这把「模型爱报成功」的失败模式用输出格式硬堵住。
高危边界被单列成节：仓库创建必须显式 OWNER/REPO 与可见性、可见性变更需后果承认旗标、删除/转移/组织级权限/2FA/密钥轮换各走专属 reference。
github-ops/SKILL.md
Repository visibility changes can expose code, Actions logs, artifacts, forks, and
注：同节还有 '- Repository creation requires an explicit `OWNER/REPO` and visibility. Never default'，以及可见性变更命令 'gh repo edit --visibility ... --accept-visibility-change-consequences'（要求在被授权后使用并读回）。repository_operations.md 把这套操作写成逐条 checklist。
与相邻 skill 划清边界：本地 Git 修复（脏工作区、bundle、丢失提交）归 git-safety-net，本 skill 只拥有 GitHub 托管状态。
github-ops/SKILL.md
This skill owns GitHub-hosted state.
注：前一句为 'For local Git recovery, dirty worktrees, bundles, or lost commits, use `git-safety-net`.'。实际 PR 收敛流程里两 skill 协作：本地备份/WIP 闸门属 git-safety-net，远端删除与读回属本 skill（见 pr_operations.md 的远端分支退役小节）。
高危操作按 reference 拆成专用流程：仓库转移的 REST 是异步操作，202 只是 pending，必须轮询新全限定名并重审协作者/团队/保护/Pages/secrets；删除保留交互式精确名称确认且明令不加 --yes。
github-ops/references/repository_operations.md
A `202 Accepted` is pending, not complete. Poll the new fully qualified name with a bounded deadline,
注：删除侧的配套纪律：'# Keep the interactive exact-name confirmation. Do not add --yes by default.'，删除后必须用列表查询证明该账号下已无匹配仓库（单独 404 语义歧义）；最终以一个 'A repository operation is complete only when:' 清单收口，并要求本地 push/clone 状态与托管状态分开核验。
组织级变更同样是专用流程：先区分 effective permission 的来源（仓库/团队/base permission/组织所有权/企业策略），再判 UI-only 字段，最后才谈写；2FA 强制被当作组织级访问变更而非勾选框。
github-ops/references/organization_access_and_settings.md
Effective repository permission is the highest grant from repository, team,
注：对 UI-only 字段的硬要求：'Do not send these response-only names in a PATCH and interpret `200 OK` as success.'（仓库可见性变更权限、删除/转移权限、组织 2FA 均属此类）。2FA 一节明确后果不对称：成员保留 membership 但失去资源访问，外部协作者会被移除（'non-compliant outside collaborators are removed'）。
issue 的创建/评论/转仓/关闭被显式定义为「外部动作」，执行前必须绑定确切仓库与内容；批量 issue 治理走冻结清单 + 逐条读回。
github-ops/references/issue_operations.md
Freeze and preview the exact issue set before any bulk write.
注：文件开头即定调：'Creating, commenting on, transferring, or closing an issue is an'（续行 'external action; bind the exact repository and content before executing it.'）。冻结-展示-授权-逐条改-逐条读回的五步模式在 issue/PR/workflow 三个 reference 里重复出现，是本 skill 的一致批量纪律。
2核心能力
01请求三分与授权边界（读-only / 具名写 / 破坏性写）：分类先于任何 GitHub 触碰，只读诊断不得自动变成变更
02身份·主机·目标绑定：多实例/企业主机显式 HOST，写前验证活跃账号且不暴露 token
03影响预览 delta 模板：写前必须写出 Target/Current/Requested/Blast radius/Recovery/Readback 六段并声明恢复路径（含「not recoverable」）
04接口选择阶梯与输入契约校验：gh 子命令→REST→GraphQL→UI；PATCH 前比对请求体参数而非 GET 响应字段，识别静默 no-op
05变更一次成型：pin 不可变标识、非幂等写不盲目重试、超时/5xx 后先读回判定是否已落地
06批量写安全模式：冻结有限目标清单→展示→逐条执行→逐条读回，禁止实时查询直喂破坏性 xargs
07按变更类型的独立读回验收表 + 四态结论：覆盖异步有界轮询、pending 如实上报、失败态附恢复与未决风险
08高危操作专用门禁与反作弊读回：分支保护要读 effective rules（列出自存规则不算数），2FA 要前后两次 2fa_disabled 查询与审计日志
3外部依赖
| 类型 | 依赖 |
|---|---|
| cli | gh (GitHub CLI) |
| cli | git |
| cli | jq |
| cli | curl（匿名只读回读） |
| cli | unzip（校验下载的运行日志归档） |
| api | GitHub REST API（经 gh api 调用） |
| api | GitHub GraphQL API（gh api graphql；gh pr/issue 列表子命令底层亦为 GraphQL） |
| network | GitHub Enterprise / 多实例主机（占位域名示例，实际由环境提供） |
| network | Webhook 投递目标（示例占位 URL；创建 hook 后仓库事件会持续外发到该地址） |
| network | 官方文档链接（被动引用，非程序化调用） |
4风险提醒 风险提醒：黄色 · 留意使用
风险提醒：黄色 · 留意使用
- 高危写面真实存在且部分不可逆 — 仓库删除/转移/可见性变更、协作者撤销、组织 2FA 强制、rulesets 覆盖、secret 轮换与删除、运行历史与 deployment 记录删除都可能造成不可逆后果。缓解全部是文档级纪律（分类 → 预览 → 恢复路径 → 读回），执行权在宿主 agent 与用户授权，skill 无代码级闸门；可见性变更的后果承认旗标与删除的交互确认是仅有的两道硬门。
- 无 prompt injection 防御条款 — issue/PR 正文与评论、workflow 日志、artifact 名等 GitHub 侧文本会原样进入模型上下文，而 skill 全目录没有「把外部内容当数据而非指令」的规则（grep inject/untrusted 零命中）。被处理对象若来自第三方，其指令性文本是否被执行完全取决于宿主模型。
- 批量与重试纪律是软约束，误用会放大后果 — 文档要求「冻结清单 + 逐条读回」「非幂等写不盲目重试」，但 agent 在超时/5xx 场景仍可能重复评论、邀请或重复建 PR；bulk 场景若跳过冻结步骤，在共享机器人账号下可一次影响大量对象。
- 本地与远端双向写面容易被忽略 — 除 GitHub 远端外，流程还会改本机状态：gh config set git_protocol ssh、gh repo set-default、克隆新目录、把日志/artifact 落到本地、git push。SKILL.md 只在个别小节提示（clone 要求目标不存在、涉及替换旧 checkout 时转 git-safety-net），本地副作用不在七步契约的读回范围内。
- 凭证经 gh 登录态与可能存在的 GH_TOKEN 环境变量生效 — skill 不读凭证，但驱动的是宿主 gh 的登录态；当环境以 GH_TOKEN/GITHUB_TOKEN 注入时，token 就在 agent 可触达的进程环境里——文档只能规范「不打印、不内联、不入日志」，无法在代码层限制 agent 行为边界。多主机兜底路径（改走另一台已授权执行主机）同样会把权限面扩展到该主机。
- 企业/代理网络与策略层依赖 — 匿名 curl 回读与 gh 通信需可达 api.github.com（或企业 HOST）；企业策略可覆盖组织/仓库设置，文档要求这种情形下查策略层而非换 payload 拼法——意味着某些操作在当前环境根本不可能达成，需要人工判断而不是反复试写。
风险提醒：黄色，留意使用。接触面：整目录仅 9 个 markdown 文件、零脚本零第三方包，全部动作由宿主执行官方 gh CLI（辅以 git/jq/curl/unzip），外发对象可预期（api.github.com 或显式企业 HOST），且 skill 自带强 token 纪律（禁止 --show-token、禁止内联/回显/入日志、禁止借用他人凭证）——因此不落绿/蓝（确实经网络改变远端状态），也不落橙（没有任何凭证读取代码，也不依赖第三方远端包或镜像，不满足橙档两条触发条件）。黄色的真实理由是「可预期网络调用 + 高危不可逆写面」：仓库可见性变更/转移/删除、组织级 base permission 与 2FA 强制、协作者撤销、rulesets、密钥轮换、公共运行历史清除都在能力范围内；skill 用分类授权、六行影响预览、显式恢复路径、独立读回、不盲目重试、禁止默认 --yes 等文档级纪律对冲，但这些是「模型须遵守的软约束」，最终仍取决于人工授权与备份，故建议与 git-safety-net 配合、在有备份与可回滚渠道的账号上使用。
5第二遍独立确认
- [ok] external_deps 逐条反查调用点是否真实存在 — 10 条依赖全部在文件内定位到调用点：gh（SKILL.md 步骤 2 命令块与全篇）、git（pr_operations.md 的 'git rev-parse '<candidate>^{tree}'' 与远端分支退役小节的 '--force-with-lease="refs/heads/{branch/path}:$expected_sha"'）、jq（best_practices.md 的 'gh api rate_limit --jq ...' 与多处 '| jq'）、curl（workflow_operations.md 匿名回读两行）、unzip（'unzip -tq RUN_ID.zip'）、REST（api_reference.md 全篇 gh api repos/...）、GraphQL（'gh api graphql -f query='）、企业主机（best_practices.md 的 'gh api --hostname github.example.com user --jq '.login''）、webhook 目标（api_reference.md 的 config[url]=https://example.com/webhook）、文档链接（api_reference.md 末尾三条 https 链接）。无虚构条目；也未漏登记第三方包——全目录不存在 package.json / requirements.txt / go.mod / Gemfile 等依赖清单。
- [ok] 文件清单 glob + git ls-files 全量核对 — github-ops/ 下恰好 9 个文件：SKILL.md + references/{api_reference,best_practices,branch_protection,issue_operations,organization_access_and_settings,pr_operations,repository_operations,workflow_operations}.md；无 scripts/、无模板/数据文件、无隐藏文件、无 symlink；find 与 git ls-files 结果一致；目录内无 LICENSE（LICENSE 在仓库根，MIT，Copyright (c) 2025 daymade，与固定取值相符）。工作副本 HEAD = d5c4678cb5d4fd6acc9c922690df035dbd33d247，与 pin 一致。
- [ok] 指令中记载的 gh 子命令与 flag 真实性核验（本机 gh 2.100.0） — 对 41 组子命令/flag 跑 gh <cmd> --help 校验，缺失 0：含 --accept-visibility-change-consequences、--match-head-commit、--auto/--squash/--rebase、--paginate/--slurp/--input/-X/-f/-F/-i、--hostname、--show-token、repo create --source/--remote/--internal、secret/variable/run/workflow 全族、issue pin/unpin/transfer、pr ready --undo、pr edit --add-project、run rerun --failed/--debug、run download --name/--dir、config set、repo set-default。--json 字段名另用负控验证（'--json bogusfieldxyz' 报 'Unknown JSON field'），说明 gh 会先做客户端校验，本 skill 用到的 issue/pr/run/repo/workflow --json 字段集全部通过校验。
- [discrepancy] 安全结论反例①：是否有未登记的网络外发 — 发现两条第一遍未单独点名的外发路径，本稿已补登记：(a) curl 直连 api.github.com 的匿名回读（不是走 gh 的通道，用于运行历史清除验收）；(b) 创建 webhook 后仓库事件会持续外发到 config[url] 指定地址（示例为 example.com 占位，替换为真实 URL 后即形成长期数据出口）。其余外发（gh/git/文档链接）与第一遍一致。混淆载荷反查：base64/eval/xxd/加密串在目录内零命中。
- [ok] 安全结论反例②：凭证读取/泄露面 — grep 'token|TOKEN|secret|SECRET|show-token|GH_TOKEN|env|api_key' 的全部命中均为纪律条款或 API 字段名，无一处读取、打印、写盘或作为参数内联：'Never use `gh auth status --show-token`'、'never inline or echo the value'、'keep secrets out of command arguments.'、'token literal in a command, document, process argument, log, or committed environment file.'、'Never copy another environment's credential as a fallback.'、'Use only that host's existing authorized login; do not copy tokens,'。gh secret set 走隐藏交互提示或 stdin 重定向，并明确 'GitHub intentionally does not return the secret value.'。
- [discrepancy] 安全结论反例③：是否有未声明的破坏性/绕过行为 — 两处需在展示层点名的能力（非漏洞）：(a) workflow_operations.md 的 '## Purging Public Run History' 提供真实 DELETE（gh api -X DELETE 'repos/OWNER/REPO/actions/runs/RUN_ID' 与 deployment 删除），runs 不可恢复，文档要求先全量备份并匿名回读验收；(b) 同文件含 'gh secret delete SECRET_NAME'、gh variable delete、gh workflow disable 等可令生产流程停摆的操作。SKILL.md 的高危边界清单只列 '- Merges, branch deletions, repository creation/deletion/transfer/visibility changes,' 一行覆盖范围，未把「运行历史清除」纳入该清单（仅路由表以 purge 覆盖），属边界清单与 reference 能力的轻微不同步——用户需知晓删除历史同样不可逆。
- [ok] 实现原理是否夸大：description 声明 vs 实际文档能力 — description 列出的各域逐一有承载：PR（pr_operations.md）、issues（issue_operations.md）、Actions（workflow_operations.md）、repositories（repository_operations.md）、collaborators/teams/base permissions/2FA（organization_access_and_settings.md）、branch protection（branch_protection.md）、API automation 与 public/enterprise GitHub（api_reference.md + best_practices.md）、parallel or superseded PR convergence（pr_operations.md 收敛五步）、「write 返回成功但状态没变」（SKILL.md 第 4/6 步 + 组织设置的静默 no-op 节）、「某设置只能 CLI/REST/GraphQL/UI 哪种能改」（SKILL.md 第 4 步 + UI-only 小节）。七步契约标题在正文以 '### 1.'…'### 7.' 实际存在。反面检查：全文没有自动完成/保证成功式措辞，反而反复要求报 pending/failed/no-op，未夸大。
- [discrepancy] 内部一致性：小标题与内容、示例与边界清单是否自洽 — 一处小标题窄于内容：workflow_operations.md 的小节标题为 '### Managing Secrets (via API)'，其下同时给出 gh api repos/{owner}/{repo}/actions/secrets（API）与 gh secret set/list/delete（gh CLI 子命令）——命令本身可执行，仅标题措辞与命令族不完全对应。另一处见上一条（路由表 purge vs 高危边界清单）。其余抽检一致：可见性变更在 SKILL.md 与 repository_operations.md 用同一旗标与读回要求；2FA 在 SKILL.md 验收表与 organization_access_and_settings.md 的流程互相对应。
6结论
适合：适合把 GitHub 当日常操作面的工程/运维/发布场景：PR 与 issue 批量治理、Actions 触发与排障、仓库生命周期与可见性调整、组织权限与 base permission 审计、组织 2FA 强制、分支保护 ruleset 落地，以及「命令说成功但状态没变」的排障；尤其适合有多个 GitHub 实例（github.com + 企业 HOST）或存在并行/被取代 PR 需要收敛的团队。宿主具备已登录的 gh CLI、用户能按需授权并保留备份时价值最大，它与 git-safety-net 组合使用可覆盖「本地备份 → 远端变更 → 独立读回」的完整闭环。
不适合：不适合未安装/未登录 gh 的环境（本 skill 无一键安装能力），也不适合期望「一句话自动改完」的用户——其产出前提是显式授权、后果预览与读回验收，含糊授权会被有意拦停。纯本地 Git 修复（脏工作区、bundle、丢失提交）应改用 git-safety-net；仓库删除后的本地内容恢复、Pages/DNS、packages、release assets 等托管面导出不在能力内（文档明示需各自的备份/迁移决策）；对完全不想让 agent 触碰生产或组织级设置的团队，应把该 skill 限制为只读用法（只走 SKILL.md 的 '## Safe read-only quick reference' 段）。
安装 agent 直装可复制
① 本站镜像 更新 2026-09-15
方式 A · 人下载镜像包下载 github-ops.tar.gz
sha256:
方式 B · JSON 格式安装指南，复制给 agent95a92ed3207a5258…agent 读 JSON 指南后会自动从本站下载安装，无需更多说明。
② 上游 GitHub · 原始来源
来源信息 GitHub 原始
作者 / 仓库daymade / daymade/claude-code-skills
原始 GitHubdaymade/claude-code-skills ↗
Stars1385
最近推送2026-09-09
本 skill commit
d5c4678cb5许可MIT（仓库根 LICENSE 文件；GitHub API spdx MIT；Copyright (c) 2025 daymade）
本站信息
收录日期2026-09-06
分类基础工具与工作流
侦查报告AI 侦查 · 2 遍 · 2026-09-06
本站镜像与 GitHub 原始是不同来源：本站锁定 commit 快照经 /r2 分发；GitHub 为实时上游，内容可能已更新。