mcpField
R
resolve-issues

resolve-issues

github.com/fradser开发596111 次安装5 周前更新
代码仓库

关于 resolve-issues

面向编码 Agent 的 GitHub Issue 处理技能，结合隔离 worktree、TDD 和明确的 PR 创建与审查交接流程。

主要功能

  1. 01选择 Issue 并设置 worktree
  2. 02红绿重构 TDD 流程
  3. 03Agent 协作实现
  4. 04委托创建和审查 PR
  5. 05合并后清理 worktree

适用场景

  1. 01隔离处理 GitHub 上的开放 Issue
  2. 02先编写测试再开发修复
  3. 03准备修复以进入 PR 审查和合并

安装

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

$npx skills add https://github.com/fradser/dotclaude --skill resolve-issues

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

附带文件references/requirements.mdreferences/workflow-details.md

详细介绍

解决 GitHub Issues

使用隔离的工作树、TDD 方法和 Agent 协作执行问题解决工作流。

上下文

  • 当前 git 状态：!git status
  • 当前分支：!git branch --show-current
  • 现有工作树：!git worktree list
  • 未关闭的 issues：!gh issue list --state open --limit 10
  • GitHub 身份验证：!gh auth status

需求摘要

使用隔离的工作树，避免影响主要开发工作。借助 Agent 支持，遵循 TDD 循环（红 → 绿 → 重构）。在提交中使用自动关闭关键词引用 issues。受保护的 PR 工作流和提交规范请参阅 references/requirements.md。

阶段 1：选择 Issue 并设置工作树

目标：选择目标 issue 并准备隔离的开发环境。

操作：

  1. 查看上下文中的未关闭 issues，并根据优先级和 $ARGUMENTS 进行选择
  2. 检查现有工作树，确定是否可以复用
  3. 使用 EnterWorktree 工具并指定描述性名称（例如 fix-456-auth-redirect），创建隔离会话
  4. 将自动生成的分支重命名为符合规范的名称：运行 git branch -m <type>/<issue>-<description>（命名规范请参阅 references/workflow-details.md）
  5. 确认 issue 的验收标准和依赖项

阶段 2：TDD 实现

目标：通过测试驱动开发和 Agent 协作实现修复。

操作：

  1. 规划实现方案并评估架构影响
  2. 编写失败的测试，以验证 issue 已解决（RED 阶段）
  3. 编写最少量的代码，使测试通过（GREEN 阶段）
  4. 在保持测试通过的同时进行重构（REFACTOR 阶段）
  5. 运行质量验证命令，确保 TDD 循环切实有效（项目专用检查请参阅 references/workflow-details.md）。/github:create-pr 会在阶段 3 重新运行完整检查流程，并作为创建 PR 前的权威检查。

阶段 3：创建 PR 并清理

目标：将 PR 创建交由 /github:create-pr 处理，使质量检查流程和审查循环得以运行。只有在合并后才进行清理，合并可能要经过很多轮对话。

操作：

  1. 使用 git push -u origin <branch-name> 将分支推送到远程仓库
  2. 关键：不要在此处调用 gh pr create。 调用 Skill("github:create-pr", "<issue reference>")——例如 Skill("github:create-pr", "Closes #456")。这是插件唯一的 PR 创建途径，负责质量与安全检查、自动关闭关键词关联、非默认分支警告，以及必须移交给 /github:review-pr。完整约定请参阅 references/pr-creation-handoff.md。直接创建 PR 会跳过所有这些流程。
    • 如果修复还需要进一步反馈再进行审查，则在参数中附加 --draft
    • 仅当用户明确选择退出审查循环时，才在参数中附加 --no-monitor
  3. 此技能不会在此处恢复执行。 /github:create-pr 会报告 PR URL，随后由 /github:review-pr 在 PR 的整个生命周期中负责处理：跨轮次持续运行 Monitor、执行分类／修复／推送轮次，以及征求用户作出的合并决定。不要在当前流程中等待，不要再次报告 URL，也不要臆测性地运行阶段 4。

第 4 阶段：合并后的清理（稍后执行，作为回退方案）

触发条件：第 3 阶段创建的 PR 已实际合并——通常在之后的轮次中，且 /github:review-pr 已完成合并决策。合并后的清理现在由 /github:review-pr 的收尾流程负责（通过 ExitWorktree action:"remove" 移除工作树、切换到 main、与 origin 同步），因此仅在清理被跳过时才运行本阶段，作为回退方案：用户选择了“不合并”、中断导致工作树遗留，或者这是一个无法对早先会话创建的工作树调用 ExitWorktree 的新会话。绝不要假设工作树已不存在——先验证。

操作：

  1. 通过运行 gh pr view <PR#> --json state -q .state 并确认返回 MERGED 来验证合并状态；绝不要想当然。
  2. 检查 git worktree list，确认 issue 工作树是否仍然存在。如果 /github:review-pr 已将其移除，则直接跳到 git fetch --prune。
  3. 如果工作树仍然存在：重要：在执行 ExitWorktree action:"remove" 之前，确认当前仍处于 issue 分支。如果检出状态已切换到 main/develop，请停止——移除操作会删除长期存在的分支。远程分支可能已经不存在；这没问题。
  4. 使用 ExitWorktree 工具并将操作设为 "remove"，以清理工作树和分支。
    • 如果存在未提交的更改，ExitWorktree 会拒绝；在将 discard_changes: true 设为 true 之前，请先向用户确认。
  5. 运行 git fetch --prune，同步远程跟踪分支。
  6. 记录解决情况和任何后续任务

参考资料

  • 需求：references/requirements.md - 工作树设置、TDD 和提交规范
  • PR 创建交接：references/pr-creation-handoff.md - PR 为何委托给 /github:create-pr
  • 工作流详情：references/workflow-details.md - 问题选择、TDD 循环、Agent 协作
  • 质量验证：references/quality-validation.md - Node.js/Python 验证命令（共享）
  • 示例：references/examples.md - 提交消息示例

评论

支持 Markdown