mcpField
Q
quick-fix-suggestion

quick-fix-suggestion

github.com/oschina開発587 回インストール28 週間前に更新
リポジトリ

quick-fix-suggestion について

quick-fix-suggestionは、Gitee Issueを分析し、リポジトリのコントリビューター向けにコード変更案をまとめるスキルです。Issue情報とローカル優先のコード検索を組み合わせ、候補ファイルや変更案、実装手順を提示します。

主な機能

  1. 01Gitee Issueの詳細とコメントを取得
  2. 02ローカルリポジトリを優先して検索
  3. 03変更候補のファイルとコード位置を特定
  4. 04実装スニペットと手順案を作成
  5. 05確信度と複雑さを提示

活用シーン

  1. 01ローカルクローンで不具合報告を調査
  2. 02機能要望に関連するコードを探す
  3. 03レビュー用の変更案を準備

MCP 対応

設定済みのGitee MCPサーバーからIssueの詳細とコメントを取得し、ローカル検索後の代替手段としてコード検索ツールを利用できます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/oschina/gitee-agent-skills --skill quick-fix-suggestion

インストール後、Claude Code で/quick-fix-suggestionを入力して読み込まれたか確認します。

同梱ファイルreferences/TOOL_REFERENCE.md

詳細

注:ローカルに mcporter がインストールされている場合は、MCP ツールを直接呼び出すのではなく、mcporter を使って呼び出してください。mcporter CLI は、より便利なインターフェースと優れたエラー処理を提供します。

Gitee MCP による修正案の迅速な提案

Gitee の Issue を分析し、以下を含む適切な修正案を生成します。

  • 変更が必要なファイルの特定
  • コードの場所のヒント(行番号、関数名)
  • 実装コードの草案
  • 段階的な実装計画

前提条件

  • Gitee MCP サーバーが設定済みであること(ツール:get_repo_issue_detail、list_comments(resource_type: issue)、search_files_by_content、get_file_content)
  • リポジトリのローカルクローン内で実行すること
  • ユーザーがリポジトリのオーナー、リポジトリ名、Issue 番号を指定すること

ローカル優先の検索戦略

ローカル優先にする理由

このスキルでは、コード検索において Gitee API よりもローカルでのファイル操作を優先します。

  • 速度:ローカル検索はミリ秒単位で完了しますが、API 呼び出しには数秒かかります
  • レート制限なし:1 分あたり 100 リクエストの制限がありません
  • リアルタイム:未コミットのローカル変更も検索対象に含まれます
  • コスト:API 利用料金はかかりません
ツール選択の優先順位
優先順位ツール利用可能性
1 番目glob、grep(組み込み)100%
2 番目ast_grep_search、lsp_find_references100%
3 番目Git コマンド(bash 経由)~90%
最後Gitee API(search_files_by_content)フォールバックのみ

手順

ステップ 1:Issue の詳細を取得する

get_repo_issue_detail を使って、Issue の全情報を取得します。

  • タイトルと説明
  • ラベル(bug/feature/enhancement)
  • 既存のコメント
ステップ 2:Issue の内容を分析する

Issue の種類を特定する:

  • bug:error、crash、broken、not working、エラー、失敗
  • feature:add、support、implement、new、新規追加、追加
  • enhancement:improve、optimize、改善、最適化

コードエンティティを抽出する:

  • 関数名(バッククォート内またはパターンに一致するもの)
  • クラス名
  • ファイル名
  • エラーメッセージ/スタックトレース
ステップ 3:コードを検索する(ローカル優先)

以下の優先順位で組み込みツールを使います。

// 1. File name search (fastest)
glob(`**/*${keyword}*.{js,ts,py,go}`, { cwd: localRepoPath })

// 2. Content search
grep({
  pattern: `function\\s+${funcName}`,
  path: localRepoPath,
  output_mode: "content"
})

// 3. AST search (semantic)
ast_grep_search({
  pattern: "function $NAME($$$) { $$$ }",
  lang: "javascript",
  paths: [localRepoPath]
})

// 4. Fallback: Remote search (max 3 calls)
if (localResults.length < 3) {
  search_files_by_content({ owner, repo, query: keyword, limit: 10 })
}
ステップ 4:主要ファイルを読み、分析する

候補となる各ファイルを読み、以下を行います。

  • 関連する関数/クラスを特定する
  • コード構造を把握する
  • Issue とこのファイルとの関連性を評価する
ステップ 5:修正案を生成する

以下の形式で結果を提示します。

## Issue #{number}: {title}

**Type**: {bug/feature} | **Confidence**: {score}% | **Complexity**: {low/medium/high}

### Primary Files (Must Modify)

**1. `{file_path}`** [Confidence: XX%]
- **Change**: {modify/add/delete}
- **Location**: Around line {X}

<details>
<summary>Code Draft</summary>

```{language}
// Current:
{existing_code}

// Suggested:
{suggested_code}
追加ファイル(変更が必要な場合があります)
  • {file_path}:{reason}
実装計画
  1. {step 1} - ファイル:{file}、約 {time}
  2. {step 2} - ファイル:{file}、約 {time}
テストに関する提案
  • {test suggestion}
確認事項
  1. {uncertainty_question}

### Step 6: Handle User Response

- **Approve**: Summarize and transition to `implement-issue` skill
- **Adjust**: Re-analyze with new information
- **Search More**: Expand search scope
- **Cancel**: Offer other help

## Notes

- Always indicate confidence level - ask for clarification when uncertain
- Follow existing code patterns when suggesting changes
- Warn immediately if Issue mentions credentials/secrets
- If unable to locate relevant code, ask for more context rather than guessing

## References

- [Tool Reference Guide](references/TOOL_REFERENCE.md) - Detailed search patterns and tool usage

コメント