quick-fix-suggestion について
quick-fix-suggestionは、Gitee Issueを分析し、リポジトリのコントリビューター向けにコード変更案をまとめるスキルです。Issue情報とローカル優先のコード検索を組み合わせ、候補ファイルや変更案、実装手順を提示します。
主な機能
- 01Gitee Issueの詳細とコメントを取得
- 02ローカルリポジトリを優先して検索
- 03変更候補のファイルとコード位置を特定
- 04実装スニペットと手順案を作成
- 05確信度と複雑さを提示
活用シーン
- 01ローカルクローンで不具合報告を調査
- 02機能要望に関連するコードを探す
- 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を使って呼び出してください。mcporterCLI は、より便利なインターフェースと優れたエラー処理を提供します。
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_references | 100% |
| 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}
実装計画
- {step 1} - ファイル:
{file}、約 {time} - {step 2} - ファイル:
{file}、約 {time}
テストに関する提案
- {test suggestion}
確認事項
- {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
コメント
Markdown 対応