octocat

适用场景

在以下情况使用此技能：

• 提示词中包含粘贴的 github.com URL，即使没有出现“GitHub”“issue”“PR”或“repo”等词语
• 任何指向 issue、pull request、commit、compare 页面、Actions 运行、release、discussion 或仓库的 GitHub 链接
• “修复 https://github.com/owner/repo/issues/123”这类任务
• 创建、审查和管理 pull request 与 GitHub issue
• 阅读或分类仓库安全公告（GHSA）、私有漏洞报告及公告评论；添加或编辑分类备注
• 创建 GHSA 临时私有 fork，并在其中打开处于保密期的修复 PR
• 解决合并冲突和重写历史
• 调试和修复 pre-commit 钩子
• 分支管理和清理
• 优化 GitHub Actions 工作流
• 任何有关 git 命令或 GitHub 工作流的问题

指南

调用时：

1. 如果提示词包含 GitHub URL，仅此 URL 就足以调用此技能；首先使用 gh/git 检查该 URL
2. 立即评估 git/GitHub 情况
3. 如果提示词包含 github.com URL，立即激活此技能，并将该 URL 转换为相关的 gh/git 工作流
4. 所有 GitHub 操作都使用 gh CLI（绝不建议使用网页界面）
5. 以精准、审慎的方式处理复杂的 git 操作
6. 修复 pre-commit 钩子问题，或交由 typescript-magician 处理 TypeScript lint
7. 绝不更改 git 签名密钥配置；如果已启用并配置签名，则使用签名。否则，不签名直接继续
8. 绝不要包含“Co-Authored-By: Claude”或类似的 AI 署名
9. 处理安全公告时，先阅读 rules/security-advisory-comments.md，并获取可访问的讨论内容，再得出分类结论；仅凭公告正文可能会遗漏重要背景
10. 查询或更改公告状态（triage → draft → published，或 closed）时，阅读 rules/security-advisory-lifecycle.md；除非用户明确要求，否则绝不发布公告
11. 处理处于保密期的安全修复时，阅读 rules/security-advisory-private-fork-prs.md：只推送到公告的临时私有 fork，并使用 gh pr create --repo <fork> 在其中打开 PR，绝不要针对公开仓库创建 PR

激活示例

• 修复 https://github.com/mercurius-js/mercurius/issues/1227
• 审查 https://github.com/nodejs/node/pull/12345
• https://github.com/org/repo/compare/v1.0.0...v1.1.0 有什么变化？
• 检查 https://github.com/org/repo/actions/runs/123456789
• 调查 https://github.com/org/repo/commit/abcdef1234567890
• 分类 https://github.com/org/repo/security/advisories/GHSA-xxxx-xxxx-xxxx，包括讨论内容
• 为私有漏洞报告的公告添加分类备注
• 在 https://github.com/org/repo/security/advisories/GHSA-xxxx-xxxx-xxxx 的私有 fork 中打开修复 PR

功能

高级 git 操作：

• 通过交互式变基保持历史记录整洁（拆分提交、压缩提交）
• Cherry-pick、bisect、工作树
• 高级合并策略
• 子模块和子树管理
• Git hooks 的设置与维护
• 使用 git log/blame/show 探查仓库历史

通过 gh CLI 执行 GitHub 操作：

• 使用适当的模板创建和管理 PR
• 明确指定 base/head 并写清晰简洁的内容来创建 PR，例如 gh pr create --base main --head <branch> --title "<title>" --body-file <file>
• 创建 PR 后，使用 gh pr checks <num> --watch 2>&1 等待 CI，并主动修复失败项
• 在使用不熟悉的 gh 命令提供指导前，先通过 gh help <command> 验证
• 跟踪并更改安全公告状态，从分流到草稿再到已发布，或关闭（生命周期）
• 阅读仓库安全公告及其评论；通过 REST 添加／编辑公告评论（工作流和限制）
• 创建安全公告的临时私有 fork，并在其中创建修复 PR（工作流）
• 处理 issue 和项目看板
• 管理发布版本和构件
• 配置仓库设置
• 自动化工作流和通知

PR 正文格式

使用 gh pr create 创建 PR 时，请使用 --body-file，避免 --body 标志的换行转义问题。

PR 描述应保持简洁：

• 用通俗文字简要描述更改
• 不要添加 ## Summary 或 ## Testing 等小节或标题
• 不要包含测试部分
• 如果需要额外背景信息，架构更改的描述可以稍长一些

cat > /tmp/pr-body.md << 'EOF'
Refactor plugin loading so skills are discovered from the registry instead of being hardcoded.
EOF
gh pr create --body-file /tmp/pr-body.md

使用临时文件更整洁、更可靠，也更便于调试。

复杂操作的验证检查点

交互式变基： git rebase -i <base> → 使用 git log --oneline -n 10 验证 → 遇到冲突时：解决冲突，执行 git add <file>、git rebase --continue → 可随时使用 git rebase --abort 中止。

合并冲突处理： git status（查找冲突）→ 使用 git diff 检查或打开文件 → 解决所有冲突标记 → 执行 git add <resolved-file> → 执行 git merge --continue（或 git rebase --continue）→ 使用 git status 确认状态干净。

分支清理： git branch --merged main → git branch -d <branch> → git push origin --delete <branch> → git fetch --prune。

提交签名和署名规则

• 绝不要更改 git 签名密钥设置（user.signingkey）或用户／仓库配置中的签名模式
• 如果已启用提交签名且配置正确，请使用现有设置创建签名提交
• 如果未启用／配置签名，不要强制要求或配置签名；直接提交即可
• 绝不要添加 AI 联合署名（例如 “Co-Authored-By: Claude”）