用途：这是对常规 git 用法的细化补充，大部分操作仍按你已知的方式执行，本技能只规定若干偏好。
提交信息：保持简洁易读，面向未来浏览 git log 的同事而非逐行审阅 diff 的评审者。用平实语言先说改了什么，省略实现细节、理由链和琐事；更深的背景应写进 diary 技能而非提交信息。代码标识符一律用反引号包裹，例如 "Add html.UserPage component"。Go 标识符需带包名，如 html.UserPage；结构体字段和方法可写作 model.User.Name。注意反引号在 shell 中是命令替换，双引号 git commit -m "..." 里的反引号会被执行并从信息中静默丢弃，需用单引号 here-doc（-F - 读取 <<'EOF' 块）、单引号 -m '...' 或转义 ` 来保护，多行信息推荐 here-doc。提交前先询问需要引用哪些 GitHub issue 并等待回复，在信息末尾以 "See #123, #234" 引用；若修复 issue 则用 "Fixes #123, fixes #234"（重复 fixes 才能让 GitHub 关闭 issue）。不要提及更新了测试，这被视为默认。
创建 PR：默认指派 Markus 为评审者，命令为 gh pr create --reviewer markuswustenberg，已有 PR 用 gh pr edit <n> --add-reviewer markuswustenberg。PR 描述不要包含与 CI 重复的部分（Test Plan、Quality Gates、构建/lint/测试通过状态等），也跳过 "## Summary" 标题，直接写要点。合并前刷新标题和描述以匹配实际交付内容。
截图：有用户可见改动的 PR 需附截图，但不要上传到 GitHub，而是在会话中发布为私有 Artifact，每个 PR 一个。构建单个 HTML 页面，以 PR 命名，每张图配简短说明，图片以 data URI 内嵌（Artifact 沙箱禁止外部图片 URL），页面总大小控制在 16 MB 以内，过大截图需缩小或转 JPEG。用 Artifact 工具发布，默认私有，未经要求不要扩大共享。在 PR 描述中加 ## Screenshots 段落链接到 Artifact URL，而非内嵌图片。评审中截图变化时重新部署到同一文件路径以保持链接有效。
合并：仅在明确、单独且点名 PR 的指令下合并（如 "merge #123"）。对捆绑了合并的问题回答 "yes"、条件式（"CI 绿了就合并"）、或此前对另一 PR 的授权都不算，需重新单独点名 PR 询问并等待。每个 PR 都先经人工评审。优先使用合并提交 gh pr merge --merge；各仓库设置不同，有的完全禁止 squash，有的仍在使用，不要默认加 --squash，若合并方式被拒可查看仓库近期历史确认实际用法。合并后清理本地状态：在项目目录拉取主分支、移除工作用的 worktree（git worktree remove <path>）、删除已合并的本地分支，避免遗留陈旧分支和 worktree。
限制：本技能只规定偏好，不改变 git 基本用法；具体仓库的合并设置需自行确认。