Workflow & Core Tools · daymade/claude-code-skills
github-ops
Operates GitHub through gh CLI and the REST/GraphQL APIs with explicit target, authorization, impact preview, and independent readback. Use for pull requests, issues, Actions, repositories, collaborators, teams, organization member privileges, base permissions, 2FA enforcement, repository settings, API automation, parallel or superseded PR convergence, and public or enterprise GitHub. Also use when a GitHub write returned success but the requested state did not change, or when deciding whether a setting is writable through CLI, REST, GraphQL, or only the GitHub UI.
L4 High-Privilege · Graded auth & full auditV1 Commit-PinnedData ExfiltrationNetwork AccessWrite FileDual-pass Audit
Control levels describe skill capabilities and suggested control measures; they do not represent quality or safety certifications, nor do they dictate usability. Usage decisions rest entirely with users and administrators. Different agent hosts apply varying constraints; do not assume hosts provide automatic protection. Third-party skill copyrights belong to their original authors. Use at your own risk.
1How It Works & Mechanism
Core Principle across the entire skill: Deliver the requested GitHub state, not just a command that looks successful—a 2xx response only proves GitHub accepted the request, not that the field actually changed, the invitation was accepted, the asynchronous job finished, or the business outcome was achieved.
github-ops/SKILL.md
Deliver the requested GitHub state, not a successful-looking command.
The original text elaborates: '`202`, or `204` response is evidence that GitHub accepted a request; it is not proof' (continuing 'that every requested field changed, an invitation was accepted, an asynchronous job'). The subsequent seven-step contract, four-state conclusions, and Terminal evidence at the end of each reference are derived from this principle.
The main SKILL.md is strictly a 'hard contract + routing table': it dispatches tasks across 8 references by operational domain and requires loading only the single reference needed for the current task, avoiding an all-at-once load of the ~95KB knowledge base.
github-ops/SKILL.md
Read only the reference required for the task:
The 8-row routing table maps PRs / issues / repositories / org permissions / branch protections / Actions / raw REST-GraphQL / automation scripts to references/*.md. This follows a 'thin main file + fragmented knowledge base' architecture: the main file is ~10KB and houses non-negotiable contracts and boundaries.
Step 1 classifies the request first (read-only / named state change / destructive, public, credential-bearing, production-triggering, or external communication); classification determines authorization scope and whether execution must pause before writing.
github-ops/SKILL.md
- **Answer, inspect, diagnose, or review:** read-only. Do not create a PR, issue,
Original continuation: 'comment, invitation, workflow run, or setting change.'. The same section enforces hard constraints: 'Do not turn a read-only investigation into a mutation because the fix looks obvious.'—prohibiting automatic escalation from read-only diagnosis to mutations, and barring comments/reviews/issues/invitations whose recipients or contents are unauthorized for this task.
Step 2 binds identity, host, and target before the first write: verify the active account first (--hostname HOST), then resolve the fully qualified target, enforcing an explicit HOST for multi-GitHub setups.
github-ops/SKILL.md
gh auth status --hostname HOST
The section continues with 'gh api --hostname HOST user --jq '.login''; target resolution uses 'gh repo view HOST/OWNER/REPO' with '--json nameWithOwner,visibility,isPrivate,viewerPermission,url'. The key points are 'inspect the account without exposing tokens' and treating HOST as part of the target so enterprise instances are not swallowed by github.com defaults; remote real-time visibility must also be read back once more before the first push.
Step 3 requires reading the GitHub hosted state (rather than stale local refs or memory) and explicitly producing a six-line impact preview before consequential writes: Target / Current / Requested / Blast radius / Recovery / Readback.
github-ops/SKILL.md
Blast radius: people, repositories, forks, runs, or public surfaces affected
These six lines conclude the code block template, which opens with 'Target: fully qualified repository, organization, PR, issue, run, or account'. The same paragraph prohibits ceremonial confirmations: 'If the user already authorized this exact consequence, execute it. Do not add a' (continuing 'ceremonial second confirmation.')—execute if authorized; pause only if authorization is ambiguous (target/scope/public visibility/deletion/recipients/recovery).
Step 4 requires selecting an interface whose input contract genuinely supports the change, following a fixed precedence: dedicated gh subcommand → documented REST → GraphQL (GraphQL-exclusive or joined relational data only) → UI-only settings; the core trap is that 'response fields do not equal writable fields'.
github-ops/SKILL.md
Response fields are not automatically writable fields. Before using `PATCH`, compare
Validation must compare against 'the operation's current request body parameters' rather than the GET response shape (opening with 'the desired key against the operation's current **request body parameters**, not the'), exposing silent no-ops: 'shape returned by `GET`. GitHub may ignore an unsupported key while still returning a successful'. UI-only sections in organization_access_and_settings.md and api_reference.md serve as concrete examples.
Step 5 enforces idempotency discipline: pin everything that can be pinned (repository/number/branch/run ID/username/expected SHA), and for non-idempotent writes, read back after a timeout or 5xx before deciding whether to resend.
github-ops/SKILL.md
- Do not blindly retry non-idempotent writes such as comments, invitations, workflow
Continuation: 'dispatches, releases, or PR/issue creation. After a timeout or 5xx, read back first to'. For batch scenarios, the same section dictates: freeze and present a bounded target list → one at a time → per-item results, strictly banning piping unreviewed live queries directly into destructive xargs; bypassing hooks, required checks, branch protections, commit signatures, or visibility consequence acknowledgments is prohibited.
Step 6 uses fresh readbacks that 'distrust mutation receipts and cached refs' for verification, providing a typed verification evidence table (PR merge / branch deletion / issue-comment-review / repo create-edit-visibility / collaborator & team permissions / org settings / 2FA / workflow / secret).
github-ops/SKILL.md
Run a fresh read that does not trust the mutation response or a cached local ref:
The table's two sharpest rows highlight the skill's differentiated value: '| Branch deletion | Hosted branch/ref is absent; local remote-tracking cleanup is a separate check |' and '| 2FA requirement | Preflight affected accounts, UI confirmation, API readback, then membership/outside-collaborator audit |' (expanded in organization_access_and_settings.md into notification/remediation/audit-log workflows). Asynchronous states require bounded polling, reporting pending if a terminal state is not observed, and never claiming done from a write receipt alone.
Step 7 closes out with one of four honest states: changed and verified / already satisfied / pending / failed-no-op or partial, requiring failure states to detail recovery paths and pending risks.
github-ops/SKILL.md
- **changed and verified** — requested state is independently observed;
Original failure state: '- **failed/no-op or partial** — requested and observed states differ, with recovery and'; the paragraph ends with 'Never say “done” from the write' followed by 'receipt alone.'. This structurally closes the model failure mode of prematurely declaring success via strict output formatting.
High-risk boundaries are isolated into dedicated sections: repo creation requires explicit OWNER/REPO and visibility, visibility changes require consequence acknowledgement flags, and deletions/transfers/org-level permissions/2FA/secret rotations each follow a dedicated reference.
github-ops/SKILL.md
Repository visibility changes can expose code, Actions logs, artifacts, forks, and
The same section specifies '- Repository creation requires an explicit `OWNER/REPO` and visibility. Never default', along with the visibility command 'gh repo edit --visibility ... --accept-visibility-change-consequences' (requiring authorization before use and subsequent readback). repository_operations.md formats these procedures as actionable checklists.
Clear boundary with adjacent skills: local Git recovery (dirty worktrees, bundles, lost commits) belongs to git-safety-net; this skill exclusively owns GitHub hosted state.
github-ops/SKILL.md
This skill owns GitHub-hosted state.
Preceded by 'For local Git recovery, dirty worktrees, bundles, or lost commits, use `git-safety-net`.'. In practice, the two skills collaborate during PR convergence: local backups/WIP gates belong to git-safety-net, while remote deletion and readback belong to this skill (see the remote branch retirement subsection in pr_operations.md).
High-risk operations are decoupled into dedicated reference workflows: repository transfer via REST is asynchronous (202 is only pending) and requires polling the new fully qualified name and re-auditing collaborators/teams/protection/Pages/secrets; deletions keep interactive exact-name confirmations and explicitly forbid --yes.
github-ops/references/repository_operations.md
A `202 Accepted` is pending, not complete. Poll the new fully qualified name with a bounded deadline,
Deletion safety rules state: '# Keep the interactive exact-name confirmation. Do not add --yes by default.'; post-deletion requires list queries to prove no matching repository remains under the account (a bare 404 is semantically ambiguous). It concludes with 'A repository operation is complete only when:' checklists, requiring local push/clone status and hosted state to be verified independently.
Organization-level changes also follow dedicated workflows: determine the source of effective permissions first (repository/team/base permission/org ownership/enterprise policy), evaluate UI-only fields, and only then proceed to writes; 2FA enforcement is treated as an org-wide access change rather than a simple checkbox.
github-ops/references/organization_access_and_settings.md
Effective repository permission is the highest grant from repository, team,
Hard constraint on UI-only fields: 'Do not send these response-only names in a PATCH and interpret `200 OK` as success.' (repository visibility changes, deletion/transfer privileges, and org 2FA fall into this category). The 2FA section highlights asymmetric consequences: members retain membership but lose resource access, while outside collaborators are removed ('non-compliant outside collaborators are removed').
Creating, commenting on, transferring, or closing issues is explicitly defined as an 'external action', requiring exact repository and content binding before execution; batch issue governance follows a freeze-list + per-item readback workflow.
github-ops/references/issue_operations.md
Freeze and preview the exact issue set before any bulk write.
The file establishes this upfront: 'Creating, commenting on, transferring, or closing an issue is an' (continuing 'external action; bind the exact repository and content before executing it.'). The five-step pattern (freeze, present, authorize, mutate individually, read back individually) recurs across issue, PR, and workflow references, establishing consistent batch discipline throughout the skill.
2Core Capabilities
01Three-way request classification and authorization boundaries (read-only / named write / destructive write): classification precedes any GitHub interaction; read-only diagnosis must never automatically turn into mutations
02Identity, host, and target binding: explicit HOST for multi-instance/enterprise setups, validating active accounts prior to writes without exposing tokens
03Impact preview delta template: consequential writes mandate outputting a six-part preview (Target/Current/Requested/Blast radius/Recovery/Readback) and declaring recovery paths (including 'not recoverable')
04Interface selection hierarchy and input contract validation: gh subcommand → REST → GraphQL → UI; compare request body parameters rather than GET response fields before PATCHing to catch silent no-ops
05Get mutations right the first time: pin immutable identifiers, avoid blind retries on non-idempotent writes, and read back after timeouts/5xx errors to confirm whether changes landed
06Batch write safety mode: freeze a bounded target list → present → execute one by one → read back one by one; strictly forbids piping live queries directly into destructive xargs
07Per-mutation-type independent readback verification table + four-state conclusions: covers bounded async polling, reporting pending truthfully, and attaching recovery and residual risks to failure states
08Dedicated gates and anti-cheating readbacks for high-risk operations: branch protections must inspect effective rules (listing stored rules alone does not count); 2FA requires pre/post 2fa_disabled queries and audit logs
3External Dependencies
| Kind | Dependency / Endpoint |
|---|---|
| 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 | 官方文档链接（被动引用，非程序化调用） |
4Recommended Governance & Evidence
Suggested Controls for Safe Operation
For Agent Runtime
Graded/per-use authorization, sandbox recommended
For Administrators
Approval workflow, rollback support, full audit
Evidence & Triggers (File Paths & Excerpts)
- 外部端点: Exfiltrating local content or conversation sessions to third-party cloud storage
- 环境变量 / API Key: Reading vendor service credentials: zero scripts or credential-reading code within the skill directory; authentication relies entirely on the gh CLI's existing login state (original text: 'All API calls via `gh api` au')
- 本地工作目录: File I/O and artifact generation: GitHub hosted side (via gh/API): PR/issue create/edit/merge/close, comments and reviews, repository create/rename/archive/transfer/visibility/delete, collaborator and team permissions, etc.
Audit Notes: Attack surface: The entire directory contains only 9 Markdown files with zero scripts and zero third-party packages; all actions are executed by the host via the official gh CLI (assisted by git/jq/curl/unzip) against predictable outbound endpoints (api.github.com or explicit enterprise HOST), and the skill enforces strict token discipline (prohibiting --show-token, inline echoing, logging, or borrowing credentials). Thus, it does not fall under Green/Blue (it actively mutates remote state over the network), nor does it trigger Orange (no credential-harvesting code and no dependencies on third-party remote packages or container images). The rationale for Yellow is 'predictable network calls + high-risk irreversible write surface': repo visibility changes/transfers/deletions, org-level base permissions and 2FA enforcement, collaborator revocations, rulesets, secret rotations, and clearing public run histories are all within scope. The skill offsets these risks with documentation-level disciplines like categorized authorization, six-line impact previews, explicit recovery paths, independent readbacks, no blind retries, and banning default --yes; however, these remain soft constraints on model behavior that ultimately depend on human authorization and backups. Therefore, pairing with git-safety-net and operating on accounts with established backups and rollback channels is strongly recommended.
5Second-Pass Verification
- [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 的流程互相对应。
6Verdict & Scenarios
Best for: Ideal for engineering, DevOps, and release workflows that use GitHub as their daily operational surface: batch PR and issue governance, Actions triggering and debugging, repository lifecycle and visibility adjustments, org permissions and base permission audits, org 2FA enforcement, branch protection ruleset rollouts, and troubleshooting 'command succeeded but state did not change' scenarios. Especially suited for teams managing multiple GitHub instances (github.com + enterprise HOST) or needing to converge parallel/superseded PRs. Delivers peak value when the host has an authenticated gh CLI session, users provide scoped authorizations and maintain backups, and pairs with git-safety-net for a complete 'local backup → remote mutation → independent readback' loop.
Not for: Not suitable for environments lacking an installed or authenticated gh CLI (this skill does not provide auto-installation), nor for users expecting 'one-sentence automated changes'—its workflow requires explicit authorization, impact previews, and readback verification, deliberately pausing on ambiguous authorization. Purely local Git recovery (dirty worktrees, bundles, lost commits) should use git-safety-net instead. Local data recovery following repo deletion, or exporting hosted components like Pages/DNS, packages, and release assets, is out of scope (the docs explicitly call for separate backup/migration plans). Teams that do not want agents touching production or org-level settings should restrict this skill to read-only mode (using only the '## Safe read-only quick reference' section of SKILL.md).
Install Agent-Ready
① Verified Mirror 2026-09-15
Option A · Direct DownloadDownload github-ops.tar.gz
sha256:
Option B · Copy Guide for Agent95a92ed3207a5258…Agents automatically download and verify mirrors from this JSON guide.
② Upstream GitHub
GitHub Repo ↗
Pinned to commit d5c4678cb5.