mcpField
G
git

git

github.com/agoodway开发166 次安装5 天前更新
代码仓库

关于 git

面向 Claude Code、OpenCode 和 Codex 的通用 Git 工作流技能，指导编码 Agent 处理原子提交、拉取请求和评审意见，并避免添加 AI 署名页脚。

主要功能

  1. 01规划原子提交
  2. 02使用约定式提交信息
  3. 03创建草稿拉取请求
  4. 04更新拉取请求说明
  5. 05处理评审意见

适用场景

  1. 01将无关改动拆分为多个提交
  2. 02为当前分支创建草稿拉取请求
  3. 03更新现有拉取请求说明
  4. 04处理拉取请求评审反馈

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/agoodway/goodskills --skill git

安装后在 Claude Code 中输入/git确认已加载。

附带文件README.md

详细介绍

Git 工作流技能

此技能与运行时无关，可在 Claude Code、OpenCode 和 Codex 中使用。使用当前运行时的 shell、读取、编辑/写入、搜索和提问工具。任何运行时都不要添加 AI 署名页脚。

运行时说明

  • Claude Code：如果可用，使用 AskUserQuestion 让用户选择。
  • OpenCode：如果可用，使用提问工具让用户选择。
  • Codex：需要交互式输入时，直接询问用户。
  • 如果需要运行交互式 git 命令，请避免使用，并改用非交互式替代方案。除非运行时能够安全地处理交互，否则不要使用 git add -p；应改为暂存明确指定的文件，或询问用户要包含哪些文件。

原子化提交

提交前，检查所有更改并按逻辑单元整理：

  • 将相关更改分组——同一功能、错误修复或重构应放在一起
  • 分离无关更改——不同的修复或功能应分别提交
  • 单一职责——每次提交都应能独立还原
  • 不要混合不同关注点——将格式更改与逻辑更改分开

如果更改涉及多个关注点，请暂存特定文件以创建单独的提交。只有在运行时能够安全支持时才使用部分暂存；否则询问用户如何拆分更改。

命令

/git（无子命令）

不带子命令调用时，默认执行以下提交工作流。

/git help

显示所有可用子命令的列表。按以下内容原样输出：

/git subcommands:

  commit [message]   — Commit staged/unstaged changes with conventional format
  commit-all         — Commit all changes as logical atomic commits, skipping junk files
  pr [context]       — Create a draft pull request for the current branch
  pr-update          — Push and update an existing PR description
  pr-pull-review     — Fetch PR review comments and address them
  help               — Show this help message
/git commit [message]

提交更改，不添加 AI 署名。

  1. 运行 git status，查看需要提交的内容（包括未跟踪文件）
  2. 运行 git diff，检查更改
  3. 分析更改的逻辑分组——如果更改彼此无关，则创建多个提交
  4. 将相关更改一起暂存：
    • 对于指定文件：git add <file1> <file2>
    • 对于部分暂存：使用运行时支持的非交互式补丁工作流，或询问用户如何拆分更改
    • 包含 git status 中显示的所有新文件/未跟踪文件
  5. 使用约定格式创建提交：type: description
  6. 不要添加 AI 署名页脚
  7. 如果用户在 $ARGUMENTS 中提供了消息，将其用作提交的上下文
  8. 提交后，使用运行时的提问机制询问用户是否要推送
  9. 如果用户选择推送，且当前不在 main 分支上，则询问他们是否要创建 PR
  10. 如果选择创建 PR，使用 gh pr create --draft，并提供恰当的标题和描述
/git commit-all

将所有工作区更改作为逻辑清晰、原子性的提交提交，但跳过看起来不需要的文件。

  1. 运行 git status，查看所有已暂存、未暂存和未跟踪的更改
  2. 过滤掉无用文件 — 不要暂存或提交以下任何文件：
    • 操作系统生成的文件：.DS_Store、Thumbs.db、Desktop.ini、._*
    • 编辑器/IDE 文件：.idea/、.vscode/settings.json、*.swp、*.swo、*~
    • 构建产物：_build/、deps/、node_modules/、dist/、*.beam
    • 临时/调试文件：*.log、*.tmp、*.bak、*.orig、dump.rdb
    • 密钥：.env、.env.*（.env.sample、.env.example 除外）、credentials.*
    • 任何已被 .gitignore 规则涵盖的文件
    • 如果不确定某个文件是否需要，请使用运行时的问题机制询问用户
  3. 运行 git diff 和 git diff --cached，检查所有更改
  4. 将更改分组成逻辑清晰的提交，遵循原子提交规则：
    • 分析每个更改过的文件，确定其所属事项
    • 按功能、修复、重构或领域分组 — 每组对应一个提交
    • 将格式/样式更改与逻辑更改分开
    • 迁移、架构更改及其对应代码应放在一起
    • 测试文件应与其测试的代码放在一起
  5. 按依赖顺序处理每个逻辑分组（例如，先提交迁移，再提交使用迁移的代码）：
    • 仅暂存该组的文件：git add <file1> <file2> ...
    • 使用约定格式提交：type: description
    • 不要添加 AI 署名页脚
  6. 所有提交完成后，展示提交摘要（提交数量、文件、简短日志）
  7. 使用运行时的问题机制询问用户是否要推送
  8. 如果用户要推送且当前分支不是 main，请询问他们是否要创建 PR
/git pr [context]

为当前分支创建拉取请求。

  1. 检查 git status，查看是否有未提交的更改
  2. 如果存在未提交的更改：
    • 运行 git diff 进行检查
    • 遵循原子提交规则 — 如有需要，创建多个提交
    • 按约定格式暂存并提交
    • 不要添加 AI 署名
  3. 使用 git log 确认当前分支和最近的提交
  4. 将所有尚未推送的提交推送到远程仓库
  5. 确定基础分支（检查 git remote show origin 获取默认分支；若失败则使用 'main'）
  6. 使用 gh pr create --draft 创建 PR，并包含：
    • 符合约定式提交格式的清晰标题
    • 详细正文，包含：
      • 带项目符号的摘要部分
      • 按领域组织的详细更改
      • 带检查项的测试计划
      • 适用时的破坏性更改或迁移说明
    • 不要添加 AI 署名或生成来源页脚
  7. 如果用户在 $ARGUMENTS 中提供了上下文，请将其用于 PR 标题/说明
  8. 向用户返回 PR URL
/git pr-update

推送当前分支并更新 PR 说明。

  1. 确认当前位于 git 仓库中，并获取当前分支名称
  2. 检查是否有未提交的更改 — 如果有，提醒用户
  3. 将当前分支推送到 origin（如果远程不存在该分支，则使用 -u 标志）
  4. 使用 gh pr view 检查 PR 是否存在
  5. 如果 PR 存在：
    • 获取当前 PR 编号和详情
    • 使用 git log 分析自创建 PR 以来的提交
    • 生成更新后的说明，包含：
      • 所有更改的摘要
      • 所含提交列表
      • 相关的测试计划更新
    • 使用 gh pr edit 更新 PR
  6. 如果不存在 PR：
    • 询问用户是否要创建一个
    • 如果是，分析自与 main/master 分叉以来的所有提交
    • 使用 gh pr create --draft 创建内容完整的 PR
  7. 显示 PR URL 和更新内容摘要
/git pr-pull-review

拉取 PR 审查评论并处理。

  1. 获取当前分支名称并查找关联的 PR：
    • 运行 gh pr view --json number,url,title 获取 PR 详情
    • 如果不存在 PR，告知用户并停止
  2. 获取所有审查评论：
    • 运行 gh pr view --json reviews,comments 获取 PR 顶层评论
    • 运行 gh api repos/{owner}/{repo}/pulls/{number}/comments 获取行内审查评论（这些评论针对特定文件）
    • 仅筛选未解决且可执行的评论 — 跳过：
      • 已解决的评论串
      • 纯批准或「LGTM」评论
      • 机器人评论（CI、代码检查工具等）
  3. 向用户列出每条审查评论的编号摘要：
    • 对于行内评论：显示文件、行号和评论正文
    • 对于普通评论：显示评论正文
    • 使用运行时的提问机制，询问用户要处理哪些评论（全部、指定编号或跳过）
  4. 对于用户希望处理的每条评论：
    • 阅读相关文件以了解上下文
    • 实施所要求的更改
    • 如果评论含糊不清，或你不同意该建议，在更改前使用运行时的提问机制询问用户
  5. 完成所有更改后：
    • 遵循原子提交规则 — 将相关的审查修复归为一组
    • 按以下格式提交：fix: address PR review — <brief summary>
    • 不要包含 AI 署名页脚
  6. 在 PR 上回复每条已处理的评论：
    • 运行 gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies -f body="Addressed in <commit-sha>"
    • 对于顶层评论，使用 gh pr comment --body "Addressed: <summary of what was fixed>"
  7. 推送更改并展示已处理内容的摘要

提交消息格式

type: concise description

Optional body for context

类型： feat、fix、chore、docs、refactor、test、style

错误处理

如果发生任何错误：

  • 清楚说明出了什么问题
  • 提出修复方案或替代方案
  • 询问用户是否希望重试或手动处理

$ARGUMENTS

评论

支持 Markdown