mcpField
R
resolve-issues

resolve-issues

github.com/fradser開発596111 回インストール5 週間前に更新
リポジトリ

resolve-issues について

コーディングエージェント向けの GitHub Issue 解決スキルです。分離した worktree、TDD、PR 作成とレビューへの明確な引き継ぎを組み合わせます。

主な機能

  1. 01Issue 選択と worktree 設定
  2. 02レッド・グリーン・リファクタの TDD
  3. 03エージェントと連携した実装
  4. 04PR 作成とレビューの委任
  5. 05マージ後の worktree クリーンアップ

活用シーン

  1. 01GitHub のオープン 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 のイシューを解決する

分離されたワークツリー、TDD 手法、エージェントの連携を活用して、イシュー解決ワークフローを実行します。

コンテキスト

  • 現在の git ステータス：!git status
  • 現在のブランチ：!git branch --show-current
  • 既存のワークツリー：!git worktree list
  • オープン中のイシュー：!gh issue list --state open --limit 10
  • GitHub 認証：!gh auth status

要件の概要

メインの開発に影響しないよう、分離されたワークツリーを使用します。エージェントの支援を受けながら、TDD サイクル（red → green → refactor）に従います。自動クローズキーワードを使って、コミット内でイシューを参照してください。保護された PR ワークフローとコミットの基準については、references/requirements.md を参照してください。

フェーズ 1：イシューの選択とワークツリーのセットアップ

目標：対象のイシューを選択し、分離された開発環境を準備します。

アクション：

  1. コンテキスト内のオープン中のイシューを確認し、優先度と $ARGUMENTS に基づいて選択します
  2. 既存のワークツリーを確認し、再利用できるか判断します
  3. EnterWorktree ツールで説明的な名前（例：fix-456-auth-redirect）を指定し、分離されたセッションを作成します
  4. 自動生成されたブランチ名を規約に合わせて変更します：git branch -m <type>/<issue>-<description> を実行します（命名規則については references/workflow-details.md を参照してください）
  5. イシューの受け入れ基準と依存関係を確認します

フェーズ 2：TDD による実装

目標：エージェントと連携して、テスト駆動開発で修正を実装します。

アクション：

  1. 実装方針を立て、アーキテクチャへの影響を評価します
  2. イシューが解決されることを検証する、失敗するテストを作成します（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 で、イシューのワークツリーがまだ存在するか確認します。/github:review-pr がすでに削除している場合は、そのまま git fetch --prune に進みます。
  3. ワークツリーが残っている場合：ExitWorktree action:"remove" を実行する前に、現在もイシューのブランチにいることを必ず確認してください。チェックアウト先が main／develop に変わっている場合は中止してください。削除すると、長期間使われるブランチが消えてしまいます。リモートのヘッドがすでに削除されていても問題ありません。
  4. ExitWorktree ツールで action "remove" を指定し、ワークツリーとブランチをクリーンアップします。
    • 未コミットの変更がある場合、ExitWorktree は処理を拒否します。discard_changes: 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 サイクル、エージェントの連携
  • 品質検証：references/quality-validation.md - Node.js／Python の検証コマンド（共通）
  • 例：references/examples.md - コミットメッセージの例

コメント

Markdown 対応