mcpField
I
issue-fixer

issue-fixer

github.com/react-native-nitro-google-sign-in開発57117 回インストール今日更新
リポジトリ

issue-fixer について

issue-fixerは、react-native-nitro-google-signinのGitHub issueを扱うリポジトリ向けスキルです。issueの分析から修正、ドキュメント更新、検証、プルリクエスト作成までをエージェントに案内します。

主な機能

  1. 01GitHub issueの取得と分析
  2. 02リポジトリの規約とコードの確認
  3. 03新しいブランチでの修正
  4. 04必要に応じたドキュメント更新
  5. 05チェック実行とプルリクエスト作成

活用シーン

  1. 01リポジトリで報告された不具合の調査
  2. 02GitHub issueに対する範囲を絞った修正
  3. 03ユーザー向けドキュメントと変更の同期

インストール

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

$npx skills add https://github.com/react-native-nitro-google-sign-in/google-signin --skill issue-fixer

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

詳細

このリポジトリ（react-native-nitro-google-signin）の課題解決スペシャリストです。GitHub の Issue URL を受け取り、新しいブランチで最小限かつ正確な修正を実装し、ドキュメントを同期して、プルリクエストを作成します。

入力

ユーザーはGitHub Issue URLを指定します（必須）。URL からオーナー、リポジトリ、Issue 番号を解析します。

ワークフロー

以下の手順を順番に実行します。ブロックされた場合を除き、手順を省略しないでください。ブロッカーがある場合は、明確に報告してください。

1. Issue の取得と把握

gh を使って Issue を読み込みます。

gh issue view <number> --json title,body,labels,comments,state,url

変更を加える前に、コードベース内の関連情報も確認します。

  • AGENTS.md — リポジトリの構成とコマンド
  • skills/react-native-nitro-google-signin/SKILL.md — パブリック API とセットアップのルール
  • Issue の内容に応じた src/、android/、ios/、plugin/ 内の関連ソース

コーディングの前に、問題、期待される動作、予定している対応方針を要約します。

2. ブランチの作成

作業ツリーがクリーンであることを確認します（無関係な変更がある場合は、ユーザーの承認を得て退避します）。

git fetch origin
git checkout main   # or master — use the repo's default branch
git pull origin main
git checkout -b fix/issue-<number>-<short-slug>

ブランチ名：Issue のタイトルから生成した fix/issue-<number>-<kebab-case-slug>（slug は約50文字以内）。

3. 修正の実装
  • スコープを最小限にする — Issue が求める内容のみを修正し、既存のコードスタイルと規約に合わせます。
  • プラットフォーム — 必要に応じて Android（android/）、iOS（ios/）、TypeScript（src/）、および／または Expo プラグイン（plugin/）を変更します。
  • 可能な範囲でビルドと検証を実施します。
bun install
bun run build
bun run typecheck

Nitro の仕様（*.nitro.ts）を変更した場合は、bun run codegen を実行し、出力に変更があれば nitrogen/generated/ をコミットします。

シークレット、OAuth 設定ファイル、API キーはコミットしないでください。

4. ドキュメントの確認と更新

コードの修正後、ドキュメントの更新が必要か判断します。以下のいずれかに該当する変更があれば、ドキュメントを更新します。

変更の種類更新先
パブリック API、型、または動作docs/content/guide/api-reference.md、docs/content/guide/usage.md
セットアップ／プラットフォーム設定docs/content/setup/（android、ios、expo、google-cloud）
トラブルシューティング／既知の問題docs/content/guide/troubleshooting.md
エージェント向け API またはセットアップskills/react-native-nitro-google-signin/（SKILL.md、reference.md、examples.md）

ドキュメントを変更した場合：

cd docs && bun run build

修正が完全に内部的なもので、ユーザーに見える影響が一切ない場合に限り、ドキュメントの更新を省略できます。その判断を PR に記載してください。

5. コミット

git log -5 を確認し、リポジトリのコミットメッセージのスタイルに従います。変更内容に集中したコミットを1つ作成するのが望ましいです。論理的に分ける必要がある場合のみ、複数のコミットを作成します。

git add <relevant files>
git commit -m "$(cat <<'EOF'
fix: <concise description>

Fixes #<number>

EOF
)"

--no-verify は絶対に使用せず、明示的に依頼された場合を除き amend せず、main への force-push もしないでください。

6. プッシュとプルリクエストの作成
git push -u origin HEAD

gh を使って PR を作成します。

gh pr create --title "fix: <concise title>" --body "$(cat <<'EOF'
## Summary

- <what changed and why>

Fixes #<number>

## Test plan

- [ ] <how you verified the fix — platform, bare vs Expo, steps>

## Docs

- [ ] Updated docs (or N/A — internal-only change)

EOF
)"

完了したら、ユーザーにPR URLを返します。

出力形式

完了時に、以下を報告します。

  1. Issue — タイトル、番号、リンク
  2. ブランチ — 名前
  3. 変更内容 — 変更したファイルの簡潔な概要
  4. ドキュメント — 更新内容、または更新を省略した理由
  5. PR — リンク
  6. テスト計画 — 実行したテストと、ユーザーが手動で確認すべき内容

制約

  • GitHub の操作（Issue、PR）にはすべて gh を使用します。
  • 修正が完了し、ビルドに成功するまではプッシュや PR の作成を行わないでください（検証できなかった場合は、その旨を明確に記載します）。
  • 回避策ではなく、根本原因の修正を優先します。
  • Issue の内容が不明確、曖昧、またはプロダクト上の判断が必要な場合は、分析の段階で停止し、実装前にユーザーへ確認します。
  • Issue がすでに修正済み、または重複している場合は、その旨を報告し、PR を作成しないでください。

コメント

Markdown 対応