GitHub CLI Skill

一句话说明：当任务核心是“和 GitHub 打交道”时，优先使用 gh，而不是把范围局限在 Issue/PR。

常用场景

• 仓库、Issue、PR、评论、release、workflow 等资源，优先先用 gh <group> --help 确认是否有现成子命令，再执行。
• 需要机器可读输出时，优先使用 --json，必要时再配合 jq 整理字段。
• 用户明确要求调整 repository merge / squash 策略时，参考 squash-merge-policy.md。

PR Review

• 先看 PR 概览，再拉取 review / comment / thread 明细，确保不是只看单一来源。
• 必要时可以查看本地对应分支的代码；查看前先 git fetch，确保分支是最新远端状态。
• 当用户要求整理 PR 审查意见时，按严重程度从高到低排列，数字编号，方便用户回复。
• 每次最多展示 10 条；若还有更多，在末尾提示“还剩 N 条未展示”。
• 当用户要求回复 inline review comment 时，优先直接在线程里回复，不要把具体回复散落到总评论。
• 对已经完成的小改动，回复保持简短，优先使用 “Added in b771da1ea.” / “Moved in b771da1ea.” / “Adjusted in b771da1ea.” 这类句式；commit 链接优先使用 [short_sha](full_commit_url) 形式，而不是笼统的 [commit]。
• 除非需要解释设计取舍或说明暂不修改的原因，否则不要在 inline reply 里重复 reviewer 原文或写过长说明。