技能介绍

浏览器切换正在吃掉你的协作节奏

不少团队的 Git 协作仍然在浏览器里完成：看一眼 issue 列表要切到 GitHub，提交 PR 要点开页面填模板，确认 CI 结果又要回到另一个标签页。对于需要频繁交互的工程师来说，这种上下文切换会让「一个小改动」被拆成多次中断的操作，连贯的思路很难保持。

更麻烦的是批量场景：一次要处理十几个 issue 标签，或者手动触发一条 workflow 验证配置，浏览器操作既重复又容易漏步骤。问题不在于功能做不到，而在于协作流没有被整理成可复用的命令，每次都要从零开始。

把协作流变成 `gh` 的固定动作

本技能基于 GitHub CLI（gh）的能力，把日常协作拆成四个可编排的步骤，每一步都对应明确的命令组合，方便你直接照搬或根据仓库规范微调。

任务起手：用 gh issue create 建单时直接关联里程碑，再用 gh issue list 盯进度，标签和负责人在终端里一次写清，不用回头补。
提交与 PR：gh pr create 会自动读取模板并关联 issue；只有需要富文本描述时，再追加 --web 参数打开页面，避免无意义的默认跳转。
审查闭环：gh pr checkout 把他人的分支拉到本地验证，验证完用 gh pr review 提交意见，审查过程不用离开终端。
发布与触发：gh release create 打标签时附带变更说明，gh workflow run 手动触发指定流水线，发布动作和验证动作都能在命令行里完成。

进阶用法上，你还可以用 gh alias 把长命令缩成短别名，或者用 gh api 调用 REST/GraphQL 做批量操作，脚本里则通过 gh auth 的 token 走自动化。配置 GH_PAGER 和默认编辑器，可以让不同工具的输出风格保持一致。

适用边界与注意点

这套命令流依赖 gh 的权限配置和仓库本身的设置。企业仓库如果 scope 不足，gh api 会直接返回 403；执行 gh repo create 时要确认可见性，避免内部仓库被误设为公开；如果仓库没有配置 PR 模板，gh pr create 的提交描述会是空白，审查者很难快速理解改动目的。

脚本里不要硬编码 token，优先走环境变量或系统的凭据存储，减少泄露风险。所有涉及仓库可见性、权限变更和分支操作的行为，都需要以团队规范为准，避免误改生产分支。