fusion-issue-solving

Issue 解決ワークフロー

使用する場合

ユーザーが GitHub issue を最初から最後まで解決または継続したい場合に使用します。solve #123 のような現在のリポジトリ内での短いプロンプト、GitHub issue の直接 URL、「lets work on https://github.com/owner/repo/issues/123」のような依頼が該当します。

一般的なきっかけ：

• 「lets solve #123」
• 「solve #123」
• 「work on #123」
• 「lets work on https://github.com/owner/repo/issues/123」
• 「https://github.com/owner/repo/issues/123」
• 「continue work on issue #123」
• 「implement issue #123 end-to-end」
• 「work on this ticket: [issue URL]」
• 「research, implement, and prepare a PR for this issue」

solve、fix、implement、continue、finish、work on などの動詞では、GitHub issue の URL を #123 形式の参照と同等に扱います。競合する意図が示されていない場合、GitHub issue の直接 URL を主な依頼内容として扱えます。

使用しない場合

• issue の起草・作成だけを依頼されている
• 実装の変更が想定されていない
• リポジトリへの書き込み操作が許可されていない

必要な入力

実行前に以下を確認します。

• issue URL または owner/repo#number
• リポジトリとブランチ／worktree の選択
• 受け入れ条件と対象外の制約
• 対象リポジトリで必要な検証コマンド

任意：

• 関連する issue／PR
• 優先して確認すべきリスク領域
• 希望するコミット／PR の粒度

指示

1. 専用の git worktree を使用するか尋ねる

   • ほかのワークフローに関する質問をする前に尋ねます。
   • 使用する場合は、worktree を使用または作成し、そこで作業を続けます。

2. issue の背景と成功条件を確認する

   • issue の本文、ラベル、リンクされたディスカッションを一度読み、再取得せずにその情報を再利用します。
   • 実装可能な範囲を言い換えて確認し、対象外の項目を明示的に列挙します。

3. issue のクローズ作業に関する担当者の意向を確認する

   • 現在のユーザーが主な issue の担当者に割り当てられているか確認します。
   • 現在のユーザーが割り当てられていない場合は、続行前に自分を割り当てるか尋ねます。
   • このワークフローで解決またはクローズする各サブ issue について、担当者の状態を一度確認し、その結果をクローズの判断に再利用します。
   • 現在のユーザーがサブ issue の担当者に割り当てられていない場合は、解決またはクローズする前に、自分を割り当てるか尋ねます。

4. GitHub での低トークン戦略を適用する

   • 同等のツールがある場合は、場当たり的な gh api や GraphQL 呼び出しより MCP 対応ツールを優先します。
   • ラベル、issue タイプ、重複の確認を重複して行わないようにします。
   • 実行中のコンテキスト（issue のメタデータ、重複候補、issue タイプのサポート状況、ラベル一覧、担当者候補）をキャッシュして再利用し、このセッションですでに取得したデータを再取得しないでください。
   • fusion-issue-authoring またはその下位スキルに作業を委任する場合、オーケストレーターのセッションキャッシュルールが適用されます。ラベルと担当者候補はリポジトリごとに一度、issue タイプは組織ごとに一度取得します。
   • MCP で対応できない場合に限り、GraphQL をフォールバックとして使用し、再試行を繰り返さないでください。
   • GraphQL のミューテーションは、クエリの 1 ポイントに対して、それぞれ 5 ポイントのセカンダリレート制限コストがかかります。フィールドは 1 回の呼び出しにまとめ、ミューテーションの呼び出し間は少なくとも 1 秒待ちます。
   • 予算に注意してください。一般的な実装セッション（issue の読み取り＋重複確認＋1～2 回のミューテーション＋サブ issue のリンク）は、MCP 読み取り呼び出し約 20 回、ミューテーション 5 回未満に抑えます。合計呼び出し数が 30 回以上に近づいた場合は、任意の追加調査を中断し、ローカル作業に進みます。
   • retry-after および x-ratelimit-reset ヘッダーを尊重し、指定された待機時間より前に再試行しないでください。
   • レート制限に達した場合は、必須ではない操作を停止し、可能であればローカル実装／PR の準備を続けます。

5. 具体的な計画を立て、進捗を管理する

   • 依存関係に沿った実行可能な ToDo を作成します。
   • 常に進行中のステップを 1 つだけにし、作業の完了に合わせてステータスを更新します。

6. 編集前に調査する

   • 関連ファイル、テスト、周辺の使用例を確認します。
   • 表面的な修正より根本原因の修正を優先します。

7. 小さく範囲を絞って変更を実装する

   • 各変更を、Issue の受け入れ基準に沿ったものにします。
   • 無関係なリファクタリングや、生成されたリリース成果物は避けます。

8. 段階的に検証する

   • まず対象を絞ったチェックを実行し、その後にプロジェクトで必須のチェックを実行します。
   • チェックに失敗した場合は、関連する問題を修正し、次に進む前に再実行します。

9. PR の準備を整える

   • 変更内容とその理由を要約します。
   • 検証結果と、今後対応が必要な事項を記載します。
   • Issue やコンテキストに応じた名前の .tmp/ ファイル（例：.tmp/pr-body-issue-123-scope-summary.md）に PR 本文の下書きを作成し、共通の .tmp/pr-body.md は使用しません。
   • .github/pull_request_template.md をもとに下書きを作成し、実装の進行に合わせて更新します。
   • 対象とするベースブランチを確認し、有力なデフォルト候補（通常は main、または現在のブランチの派生元ブランチ）を提案します。
   • PR をドラフトとして開くか、レビュー可能な状態で開くかを確認します。
   • PR にユーザーを割り当てるか、関連する Issue をリンクするかを確認します。

10. GitHub の変更操作（任意）

• GitHub に変更を加える操作（作成／編集／コメント／クローズ）の前に、必ずユーザーの明示的な確認を求めます。
• 依頼された場合は、Issue のステータスやコメントを、客観的な進捗内容で更新します。
• 同等の操作が可能な場合は、臨時の API 呼び出しより MCP ツールによる変更を優先します。
• GitHub API のレート制限により変更操作ができない場合は、失敗内容を明確に報告し、再試行を繰り返さず、安全な再試行手順を提案します。
• 依頼された場合は、確認済みのベースブランチ、ドラフト／レビュー可能の状態、担当者の選択、関連する Issue のリンクを使い、リポジトリの PR テンプレートと .tmp/ の PR 本文下書きファイルを用いて PR を作成または更新します。

期待される出力

次の内容を含む簡潔な作業報告を返します。

• 元の Issue の基準に対して実装した範囲
• 変更したファイル
• 検証コマンドとその結果
• 主 Issue と影響を受けるサブ Issue の割り当てに関する決定
• 使用した API の利用方針（MCP 優先／キャッシュの再利用／フォールバック）
• 未解決のリスク／ブロッカー
• PR 本文の概要（または作成した場合は .tmp/ の下書きファイルパス）

アセット

• assets/issue-solving-checklist.md

安全性と制約

• このスキルは変更操作を実行できます。リポジトリ内のワークフロー指示がここに記載されたガイダンスと矛盾する場合は、リポジトリ内の指示を優先します。
• シークレットや認証情報を要求したり、公開したりしないでください。
• 明示的な確認なしに、破壊的なコマンドを実行しないでください。
• 変更は最小限にし、Issue の範囲に限定します。
• 実行していないチェックに合格したと主張しないでください。
• リポジトリの指示とコントリビューションルールに従ってください。